Disable shops #3132
Disable shops #3132
Conversation
…mmerce/reaction into joykare-disable-shops
|
@zenweasel review on this |
|
I think we should probably make this the inverse. That is, look for the "active" status and filter all those that are not active? Or maybe an array of visible states (to be named later, but just "active" for now). I know we are going to add more workflow states to shops really soon. |
| @@ -166,9 +166,16 @@ function composer(props, onData) { | |||
| window.prerenderReady = true; | |||
| } | |||
|
|
|||
| const shops = Shops.find({ | |||
There was a problem hiding this comment.
Maybe we could name this something like activeShops to make it clearer what we are filtering for below.
There was a problem hiding this comment.
If we filter for just the _id field we could also avoid using the map below.
There was a problem hiding this comment.
We'd still have to use map coz after:
const activeShopIdsArray = Shops.find({
"workflow.status": {
$in: ["active", "new"]
}
}, { fields: { _id: 1 } }).fetch();
It returns an array of objects that looks like this:
[ { _id: "J8Bhq3uTtdgwZx3rz" }, { _id: "Xw8zPBgTmSF7ZdFZS" } ]
So eventually I'd need to get just the values
There was a problem hiding this comment.
True. I forgot that it doesn't just return an array of ids.
|
another review @zenweasel |
|
Hold your horses. I'm testing as fast as I can. |
|
Is "new" a status we want to show products for? That's the default status when they are created so I think not? @mikemurray ? |
|
Its also the constant status of the default/primary shop. It doesn't change to "active". So to show products in the primary shop we need it. |
|
Hmmm, maybe we should change that state then? That seems like it's going to trip us up elsewhere. Is that just set in the |
|
Except for that question (do we want to display the |
|
Alternately we could change that query to be "shops that are active or equal to the primaryShopId". I don't think we need the option to deactivate the primary shop. Looks like the "new" state is defined by the |
|
@spencern Your input would be appreciated |
|
@zenweasel If we had onboarding then Status should have no effect on the primary shop. |
|
NB. Changed it to use the |
|
More scope on this, just for clarity: @mikemurray and @spencern |
|
That sounds correct to me. I think the first solution is to only display products from "Active" shops, in the near term we'll be building out a more complex, extensible workflow for shops, but since a shop shouldn't display products until their payment, address, etc are setup, then I think for now a new shop should not be displayed. I agree that the exception for the primary shop should exist. |
|
It just occurred to me that we are doing this all on the client-side and we didn't add any filtering to the publications? We need to do that as well. We shouldn't be leaking unpublished Shops/Products out of the product/shop publications in the first place rather than filtering them on the client. |
|
@zenweasel
|
| @@ -95,6 +95,15 @@ Meteor.publish("Products", function (productScrollLimit = 24, productFilters, so | |||
| return this.ready(); | |||
| } | |||
|
|
|||
| // Get disabled shop id's to use for filtering | |||
| const disabledShopIds = Shops.find({ | |||
There was a problem hiding this comment.
Shouldn't we do this the same way we did above? e.g. activeShops rather than disabledShops?
|
Data from the Product/Shop publications should be updating when the data changes, that's a pretty core Meteor thing. If the components aren't updating when the data changes that's a different thing (and surely beyond the scope of this PR, but we should open an issue) |
|
Yeah the backend is reactive its the components that don't update before a refresh. Its ready now |
|
Findings, so far:
|
Resolves #3131
How to test