Is it possible to selectively 'notify producers' in an OC?

I have 2 hubs using the same supplier. In one case the hub wants to place the order to the this supplier because they also have a store that they stock. In the other hub they want the supplier notified directly. Is it possible to select certain suppliers to be notified rather than the default - which is to notify all at present? For example, at the OC setup, could there be a notify - Y/N - selection beside each producer/supplier with product ‘incoming’ into the OC?
@sstead - who could tell me if this is a ‘big development issue’ (ie: needs estimate…) or if this is a more simple issue. I think this will become a critical issue in Canada very soon - many of our hubs share suppliers/producers, and in many cases the hub is the ‘manager’.

It is also a problem that there can only be one email address for notifications. In a scenerio where hubs share a supplier, and are co-managing the product list (the supplier doesn’t want to do it) - there is no way to specify which hub manager gets notified in the OC? Am I missing something ?

@tschumilas sorry but I couldn’t tell you how tricky this kind of development would be. I’ll ask the devs when I’m in the office on Friday. Just to note, a ‘work around’ would be to download the appropriate Order Cycle Supplier Total report and email it to whoever needs it. But of course this takes more time.

Hey @tschumilas

  • Regarding being able to notify individual producers, rather than all of them, Rob suggested that this would be relatively straightforward, perhaps half a day.
  • Regarding being able to select which email the notification goes too, Rob said this would be fiddlier and take more time. He mentioned that the notify producers modal is quite small, so it may be hard to store all the functionality in a small space, especially for large OCs with many producers.

Broader changes to the notifications field came up. Currently you can only have one notification email set per enterprise. It would be good to change this field, so it could include multiple emails. I’ve created a github issue for this, to capture this wishlist item G#1665. Perhaps once this is done, it would be easier to have a ‘select which email to notify’ interface in the OC producer notify area.

Another related issue, is that currently the notifications field has a ‘hidden power’ - if you type in a new email in here, that email will be sent a confirmation, and once confirmed that email becomes a manager. We need to migrate this functionality to the manager field (a more logical place). Once this has been done, it will be easier to overhaul the notifications field, and allow for multiple notification emails. Here’s the github issue for this- G#1593

Always a web of interconnected issues :stuck_out_tongue:

This sounds so FANTASTIC - you are the best @sstead. I was really worried that these issues (not being able to select producers to notify, and only having one email for enterprise notification) would put a major damper on the Canadian plans!!! So I’m delighted - and thanks for creating the gihub issues. I’m still in the process of hunting for feature development funding - so these issues might get done. A process question - what happens after a github issue is created - so it is in a ‘would like done’ kind of list (like the list I leave for my husband on the fridge). But - how and who decides whether to tackle it? (I know with my husband’s list, it seems some items never make it to the top - not sure why not.:grinning:)

hi @tschumilas - just wanted to quickly respond to your question about how items rise to the top :slight_smile:

The most simple answer is - when the person with the money says they do OR a developer starts submitting pull requests. Generally when someone gets funding they prioritise what they want done with it and then a dev team starts working it (once there is capacity - often everyone’s priorities are being managed alongside each other, sometimes behind an Aus review bottleneck - but we’re working on that!!)

The other way things get done is that a developer starts working on something and starts submitting pull requests. If that developer (or the project they are working with) is unfunded, then the review and merge is covered from the OFN CC buckets, to encourage their continued contributions and get the code and features in.

So for you right now, I’d recommend:

  • making sure you tag all of your wishlist items as Canada (or we can create a sub-category so it’s easier to manage and see them all at once? Let me know if you want me to do this)
  • continue the discussion about the student projects? any luck ascertaining their skills and level of uni support?
  • when I create my follow on post to spending OFN CC funds you can nominate some of these items if you think they may attract support from the broader community, but I think we’re still a long way from having enough funds to build features from this, rather than dealing with urgent issues

Hope that helps. Also just pinging other project managers to make sure I’m not misrepresenting anything @danielle @lin_d_hop @MyriamBoure @CynthiaReynolds

sorry, the other obvious thing - if you get enough clarity around what you want done, you can spec it and set-up a cobudget project to raise money for it. See @lin_d_hop’s discussion on how to go about this at ‘From Inception to Release’

1 Like

You mean in GitHub @Kirsten? I don’t think @tschumilas has been introduced to GitHub yet, and I’m not sure there’s a canada label yet.

no I mean in discourse as that’s where she’s putting them. discourse posts can be tagged without needing a label created

This is something that we would probably need too. cc/ @sseerrggii @sauloperez @saritamoreira @maxco

@danielle @Kirsten @sstead - so there is discourse thread for the Canada backlog that Sally helped me start - OFN Canada Backlog - and I was going to update this. (Frankly things are evolving so fast I can hardly keep up - bet that is a common feeling right now). BUT - I’d also of course like to use the power of discourse to make posts that have a bit more description about some of these issues because I suspect others have solid contributions to make, and/or see the feature as useful for them. So - just clarify for me - should I stick with doing this on discourse - or should I get oriented to gitHub and do it there? Sally has taught me how to put an issue there - I forget, but can figure it out again I’m sure. I know I’m a non-techie - but am getting better at our various channels and processes, so if I should immerse myself in github I will. I’m just picking my priorities really. And of course I’ll do co-budget buckets and contributions to buckets too - was just waiting until funding is more clear here.

Glad to hear this @enricostn. I actually think that the real power of OFN is in the creation of food systems - so I mean linking different networks (what we usually call hubs) into networks of networks (or what I call systems). In OFN, right now, does this this through suppliers/producers - who permit the selling of their products to multiple hubs/distributors/buying clubs… But right now, I think that most OFN instances have enterprises with discrete networks - meaning, hub A draws products from suppliers 1, 2, 3…; hub B draws products from supplers, a, b, c,… But we will very soon (in Canada already are) encounter more situations where hub A draws products from supplirs 1, 2, c; hub B draws products from suppliers 1,4, a,c, e … Entanglement. OFN can handle this now - the ability for hub mangagers/ OC coordinators to notify producers selectively, and issues @sstead points out above will need to be resolved to make this easier.

1 Like

Just noticed the @Kirsten posted a similar use case - much more clearly presented than my ramble - with regard to situations when hubs/users ‘share’ a supplier who doesn’t manage their own product lists - and how to address ‘first enterprise advantage’ . Her question is whether the problem can be solved by allowing for users to copy lists from such suppliers to address complicated permissions. My notifications to producers is another challenge to the same ‘shared suppliers’ situation - Private vs open products

this / these issues are part of the complex of things that we describe as ‘inventory’ or ‘p&v’ 2.0 . . which is basically a significant development of the inventory functionality to support / overcome the difficulties we have hit with multiple hubs wanting to use the same supplier (where supplier not managing the product list) - often a significant wholesaler that multiple people use. I really want us to be able to talk through this, and explain where @oeoeaio @sstead and I have got to on how we think it could be dealt with, and really want/need to understand what @enricostn and @sauloperez are planning as it underpins how we were thinking of dealing with buying groups, but I have no idea what you are thinking at this stage :slight_smile: Can we arrange a time, when Rob is back from upcoming holiday to have a hangout especially to talk through this?

have moved this topic to the sub-wishlist category of Inventory 2.0

Sure @kirsten! @enricostn s back the 1st of August so, unless he has any problem, we can arrange it whenever works for you guys.

1 Like

Just referencing a GH issue that can be related to that as well, for memory:

Migrated to Wishlist board: Enable selectively ‘notifying producers’ in an OC · Issue #100 · openfoodfoundation/wishlist · GitHub