Openfoodnetwork: Tag rules are not working for show/hide inventory variants

[sstead]

This came up in Spree testing. I checked on Staging2 and it's occuring there as well, so probably in production too..

Problem described below:

The above scenario shows the 'by default' tag rules. Note that tag rules applied to product variants are also not working. E.g if by default salmon was visible, but I made a tag rule that hid it from certain customers, it would not hide.

Other tag rule (relating to shipping methods, payment methods and OCs) are working.

[daniellemoorhead]

Hey @oeoeaio might be worth having a quick look at this. @sstead how much of a problem is this? Does it break things so that users can't find a workaround, or is it not too big a problem at the moment?

[sstead]

I don't know of anyone using this feature in Aus, Sarah from the UK was the one initially using tagging to distinguish between retail and wholesale customers, I wonder if she needs it or has noticed that it's broken? There's not much of a workaround for this, other than creating duplicate shopfronts and putting different products in each.

[lin-d-hop]

@matt-yorkley can you take a high priority look?
Needed by a bigbarn user. Ideally well fix for next release.

[Matt-Yorkley]

@oeoeaio maybe you can take a look, I can't figure this one out.

[OliverUK]

Stroudco uses this feature to offer cheaper variants to full members.

[daniellemoorhead]

@oeoeaio is unfortunately away and not back till August 30th. @mkllnk would you be able to shed any light on this?

[mkllnk]

This is the first time for me to look into the tag rule feature. I can't see a feature spec covering this behaviour. That would be very helpful to reproduce this.

Products do get filtered in app/controllers/shop_controller.rb. There is an unused method filtered_json which should either be used or removed.

The filter method passes the product data to the tag filter rules. I think the problem is that the product data doesn't contain the tag. The product data is created by app/serializers/api/product_serializer.rb. I can't see any code that is including the tag data here. @Matt-Yorkley Is that enough to start you off?

[sigmundpetersen]

I think we have a report of the same issue in Scandinavia. I'll add our label.

Is it a problem that this is in the UK milestone, is it probable that it will be "hidden away" and lesser chance of getting it on the next dot point release? @daniellemoorhead maybe we should have a bigger discussion on this on discourse, regarding milestones, projects and priorities?

[daniellemoorhead]

@sigmundpetersen it's all rather ad-hoc at the moment, and pretty much solely based on issues being picked up by instances who have funds for development (and devs), and then the AU team does higher level support, code review and merge. AU doesn't have funds to be able to pick up and run with this stuff ourselves. There's a core co-budget bucket which is pretty small and is managed by @kirstenalarsen in terms of what gets spent via this discourse page.

So it won't get lost in UK Current, because only the UK devs are picking up and running with bugs and fixes at the moment, no other team are doing it.

If you'd like to kick off a discussion on discourse about these things then happy for you to do so, I'm not sure what you'd specifically like to cover so best to be initiated by you. As well this could be a topic of conversation at the next global hangout, depending on what specifically you'd like to discuss. 🙂

[daniellemoorhead]

@Matt-Yorkley are the notes that @mkllnk added above enough for you to be able to get into this bug or do we have to wait for @oeoeaio to return?

[sigmundpetersen]

@daniellemoorhead Yeah I'm just thinking that everything that is going to be released in August should be in the August dot point release? AFAIK an issue can be in only one milestone. But I guess fixed bugs get merged to master either way :)

So it's just to get a clearer view of what to expect for the next release and that it gets into release notes.

[daniellemoorhead]

No worries @sigmundpetersen :)

For some initial clarity:

@sstead is the release notes queen, she looks at what is closed within that month's dot point release milestone and writes them up to coincide with it going live. They all live here.

We have no idea each month what will get developed and pushed through to done. Basically, the dot point releases are for the random smaller PRs that get merged, which is why they're scheduled for the end of every month. Which is what we laid out here as a way of trying to set expectations for the community. The twice weekly releases mentioned in the topic hasn't happened, and I don't think this has been so much of a problem up to now. I think it's worth adding here that we also understand that sometimes a release is required outside of this timing to get a high severity bug fix live or when an instance really really needs a particular feature live (we did this for France and their invoicing feature).

Finally, things like Stripe, Spree Upgrade, Multilingual, and possibly email confirm, they are larger releases and don't have to coincide with the end of the month, they'll go whenever they're ready.

Feel free to take this info and start a discourse topic if you think this isn't clear to the rest of the community. Cheers!

[sineadfenton]

Hey,

Is anyone able to provide an update or insight into what's going on with this issue (discussion seemed to veer off).

We have customers here in the UK using the feature and a new enterprise who see it as a big barrier to going live. It would be good to look at the scope for getting this fixed; it's a unique features of using the OFN...

Cheers,

Sinead

[sineadfenton]

Restricting Customer Product Views

[daniellemoorhead]

Heya @sineadfenton this hasn't been prioritised by any other instance at the moment, and @oeoeaio doesn't have it on his very long list of things.

We're not quite sure what the priority of fixing this is over getting subscriptions live. Perhaps you could have a chat with @lin-d-hop and @NickWeir63 and understand the order of priority for this vs all those other things?

For AU we really need subscriptions live, so we wouldn't necessarily make this fix a priority over getting that work done. And with Maikel now away Rob is also managing the review/merge of email confirmation and general PRs.

If you can let us know the priority order then Rob can factor that in with all the other work...or hopefully @Matt-Yorkley gets back from the mountains of spain and can use the info Maikel added above to fix it :-)

[NickWeir63]

Thanks @daniellemoorhead yes I will talk to @lin-d-hop and @sineadfenton and we will get back to you. I feel very mixed about this - it would be great o have it fixed but I don't want to distract the devs from subscriptions. On balance, I think it might be best for me to help Sebastian find work arounds and then either make this a priority after subscriptions is out or as Matt to have a go at it when he is back.

[OliverUK]

Though considering it was working and then broke, there must be something that caused it to break and having no clue what it was and how it broke it and what else it may be affecting isn't great either, right?

[NickWeir63]

I have now talked to Lynne about this and agreed that we will wait until Matt is back and then ask him to have a look at Maikel's suggestions

[oeoeaio]

Fixed by #1931. Apologies. This regression was at least partially my fault. I've added specs to make the same oversight much more difficult to make in future.