Inventory Reset

ok, good news @lin_d_hop - @oeoeaio and I reckon we have a pretty manageable way forward with this. yay. Have a look and see what you think, and whether you want to do this or alternatively we could get @maikel started on it . .

The key to it making sense to do it this way, is that we have a general plan to move more functionality into the VO page as an ‘inventory management’ page, where Users can easily manage which products and variants they actually want to work with (which is often NOT everything the producer has available). Will write this up properly

but in the meantime, perhaps all we need is

  • a new field in variant overrides page for ‘reset level’
  • a button / function that resets ‘on hand’ to the amount in the ‘reset’ field
  • the VO ‘on hand’ levels already override the underlying product ones so these will be the levels then reflected in the shopfront for the hub
  • function called manually for now, but then once is working we can work out where else / when to activate it from (e.g. when opening a new order cycle)

[Note to self . . Q: is there any reason we would want to have the inventory levels set at the order cycle rather than the Hub? Only if we want each outgoing Hub to draw from same inventory, but then we can just set that in OC ‘draw from Coord inventory’]

Thanks @Kirsten
Am I correct in thinking that at present the variant overrides page only actually handles variants. If a product has no variant, ie just the master available, then you can’t actually do anything from the variant overrides page and would instead need to use the products page?

So is the plan to allow VO page to handle reset values for all products?

yep precisely, this page will allow management of all variants. Will be in V1.0, and has some other implications for variant management. See Rob’s note also in v1.0 notes - What’s New - v1.0 (150616)

consider also git issue

omment from @NickWeir on github, should be taken into account in implementation

Stroudco producers (and the hub admin on their behalf) need to be able to set stock levels in one of 2 ways: 1) that the stock level available from this product for a new order cycle reduces by the amount sold in the previous order cycle OR 2) that the stock level of this product available for a new order cycle reverts to the original total set at the beginning of previous order cycle.
In this way the producers who hold a stock in the Stroudco shed can have their stock levels automatically reduced using option 1) above and producers who always produce a maximum of 5 loaves of bread every week can use option 2)

Hi, new UK dev Steve here having a go at this. I’ve implemented the new default stock field in the variant overrides model and the reset function as suggested in the May 22 post. I’m going to move onto hooking this up to the front end variant overrides page once I’ve learned some Angular…

A couple of thoughts I had while doing this:

  • As I’m writing it, having a default stock level of nil means that the levels should not be reset, while a value of zero would reset the on hand level to zero when the function was called. Assuming this behaviour is ok, there needs to be a way for the user to clear the default level for a variant. The level can be changed or set to zero in the normal way (by entering a new value and calling the bulk_update function on the variant overrides page) but I think there would need to be a separate [x] button or similar for each override [that has a default level] that will set it back to nil (i.e. disable reset behaviour for that override).

  • I’m writing an analogous method to bulk_update in the controller that will go through all the overrides and set the on hand level to the value in the default level field. Another way could be to have a script that fills in all the on_hand fields in the front end with the default value, then just use the current bulk_update button. This could be a nice way to do it if ad hoc changes to the default values for an individual cycle might be necessary, as won’t have to go through two database update steps? Don’t know if there’s a preferred style here?

Please bear with me if I’ve got the wrong end of the stick with any of this!

Have confirmed with user operating two hubs with same products that maintaining stock at order cycle level is preferred, so no problem doing it this way for now (i.e. some future user may want to set stock levels that apply to multiple hubs). This could be implemented through @oeoeaio’s idea of eventually allowing ‘inventory lists’ ie. multiple sets of settings for different hubs, and enabling selection of which one you want to use at the order cycle. next step :smile:

@RohanM just flagging you to this one. Could you have a look at @stveep’s comments above and see if is ok in line with our discussion?

Also, @stveep and @lin_d_hop - I’ve copied a comment in above from @NickWeir. Does my understanding of this match yours? Just wanting to make sure Nick’s request is covered by the proposed implementation

  • Case 1: is what happens automatically. If you control the producer, you set the base stock level and each consecutive OC just draws down from that. If you set VO’s for your hub, and don’t ‘reset’ them, then the next OC will just draw down
  • Case 2: the levels set in ‘reset’ can be restored by clicking the new button. So as long as you set them right last time, and you remember to hit this button, you will be able to start again with the same levels

Hi @stveep,

Sorry I didn’t pick this one up straight away. In future could you make sure you tag anyone you’d like to respond eg @lin_d_hop as that way we’ll get a notification :smile:

RE Nicks comments, sounds the same as the original spec to me. The Reset level field can be enabled, giving the case 2 functionality, or disabled leaving at what happens now (case 1). Variant overrides are already available per hub for hubs and producers so this feature should just tie in nicely.

On @stveeps first thought, perhaps a checkbox ‘Enable’ in the column that then expands to a field to input a number? This will help reduce any user confusion.

On your second thought, I think the idea of setting on on_hand values to the reset_level is a good one. This field on the variant_overrides table is specific to a product and hub so tying in with the existing on_hand functionality seems like the simplest and cleanest route to me. When reset_level is disabled the on_hand value will just remain as is unless updated.
The function to do this update will reside in a button in the order_cycle screen. I suspect it will go beside the ‘Send Producer Emails’ button that @pmackay has been working on in https://github.com/openfoodfoundation/openfoodnetwork/issues/275.

Hope that is useful :slight_smile:

Hi @stveep,

How’s this going since the hackathon? Do you still have unanswered questions from your post a few weeks ago, or are you good to go for the moment?

Hi @RohanM,

This is coming on ok - sorry for the late response, I’ve been away. I have one question that has come up when writing the tests. I was having some authentication problems when running my tests for updating the variant overrides, except when I used an :admin_user from the factory. I’m worried that this creates a super (instance-level) admin and is therefore not what we want? I guess the desired behaviour is that the admin of the associated hub can update but no one else? Would I simulate this in the tests by making a regular user who is the owner of the enterprise? I got an “unauthorised” redirect for the POST request when I tried it this way. I was finding it hard to figure out which user types/roles are available and what they correspond to just from the code, is there some kind of reference for it anywhere?

Anyway this authentication uncertainty aside it seems to be working fine, I implemented a method to refresh the data after updating as we discussed so thanks for the help with that. I’m now working on a toggle to enable/disable automatic resetting of the stock levels - @lin_d_hop and I thought about adding a checkbox for each override on the VO page to do this. This means it can easily be switched on or off temporarily for an order cycle (say) without having to re-enter all the default stock levels afterwards. @NickWeir @Kirsten does this sound sensible? We’ll also need to think about whether/how to trigger this from the “New Order Cycle” page I guess.

Steve

Sounds great @stveep - I’m not sure if @RohanM is yet in the desert with the bugs at burning man, so have just pinged a couple of others in case they can help with your question of testing different users (which @lin_d_hop or @pmackay may also be able to help with), or @maikel @oeoeaio

Thanks Steve - this sounds great. Yes it sounds like a "nice to have"to be able to switch on or off for an order cycle but if this is a lot more work it would be fine for each individual producer (enterprise) to be able to choose either automatic resetting of stock levels or a stock level that reduces by the total orders from the previous order cycle. Thanks Nick.

Hiya @stveep,

Hows this coming along? Maybe you’ve progressed since you wrote this but if not…

In answer to your questions about users, you are right that we want to test the functionality with more than just admin level users.
To get a flavour of the user and enterprise types have a look at: Users and Enterprise Types

I’m not sure if this will be useful in your case, in other testing I have done I have created a user and an enterprise then assigned the user to have an enterprise_role.
enterprise = create(:distributor_enterprise)
enterprise.enterprise_roles.create!(user: user)

I suspect that the issue is more likely to do with setting up the test than the implementation, but you could always confirm that to yourself by logging in as an enterprise manager and testing that your functionality still works.

If you have a pull request I could do a code review on it if that would be helpful? Obviously Rohan will have more to offer than me but if nothing else it’ll help my learning :wink:

1 Like

Thanks @lin_d_hop!

I put in a PR as we discussed on the Skype. I’m about to go on holiday for a couple of weeks so haven’t had a chance to look into the auth problems further…but I ran into it again when writing the feature tests, even though all the user stuff was set up already in this case and works for e.g. the bulk_update method, so I still don’t really understand. It’s probably something simple and just down to my inexperience so if you or @oeoeaio have time to check it out that would be great - if not, no worries and I can pick it up when I get back. Hopefully something in there is useful anyway…

Correct but not for long - fix for this is almost in . .

Hi Rohan,

Yes I got the data refresh working basically as you suggested. Think I’m OK
for the moment, now going to work on a way to disable the reset to default
behaviour for an override, and add some tests for the front end stuff.
Thanks for your help.

Won’t be able to do anything until late next week due to impending wedding
though!!

Cheers,
Steve

OK this is ready to deploy to staging and test @NickWeir @pmackay (uk/default-inventory branch). Here are some details on the implementation. On the Products -> Overrides page in the Admin interface there are new columns to enable the inventory reset and set the desired default level:

Enable/disable and set stock levels as required then click Save. If you try to reset before saving it prompts you to save first:

All Variant Overrides for which the reset behaviour is enabled will have their on hand levels changed to the given value:

Once the button is pressed, the database update is invoked by POSTing the relevant VOs to /admin/variant_overrides/bulk_reset, then refreshing the data on the page. Let me know if there is a more useful place to trigger this method from.

I haven’t done any testing to make sure that these values carry over to the order cycle etc, but this should use the VO values I think.

Minor issues

  • I’m not sure if this is desired behaviour or not, but as you see in the last image, any field that has been changed appears in blue - I think this is because the values from the variant have been overridden? Anything in the new columns will also appear in blue which makes sense if this is the case, but “dirty” (unsaved) entries on the page also appear in blue so this could be confusing. I haven’t consciously changed anything to do with this.

  • I started this before most of the translation work began in earnest and wasn’t thinking about it, so need to update strings to t calls for the new columns/button/messages.

  • Unrelated issue on this page - the hub selection dropdown can’t be reused after a hub is selected without reloading the page.

Thanks @stveep - this is looking great and does what we need it to do. The only very minor problem is that staging now sticks on this screen when i click ‘reset stock to defaults’ - see screenshot

it does something similar when I try to save an order cycle after adding a new producer - I click the ‘update’ button and nothing happens. i click the ‘update and close’ button and nothing happens.

But in both cases (resetting stock levels and updating the order cycle) the changes are saved and when I go back to those screens the corrections have been made.

And the second time I tried to reset the stock level the change was made and the screen did not stick with the saving message…

@stveep and @pmackay - this seems like a minor issue but do you think we need to do some more checking to see if something more sinister is happening before we deploy this update onto production?

Thanks again Steve - this is looking great

Stroudco is having some problems with this - see https://github.com/openfoodfoundation/openfoodnetwork/issues/989