Option to repeat order cycle X times

[lauriewayne]

What is the need / problem?

Enterprise managers can copy order cycles, but only one at a time. If an enterprise wants a weekly (for example) order cycle for 16 weeks, they have to copy it 16 times. If they could create one order cycle and check on "repeat [xx} times" they could set up a whole season more quickly.

Which type of users does this problem affect (and how many, if known)?

All/any:
X- Hub Managers (MCFEs)_ (any who have regular, repeating order cycles)
X- Producers_(any who have regular, repeating order cycles)

Potential solutions that will solve the problem ?[[brainstorming to list feature candidates]

Rando ideas:

1. Checkbox to "repeat this order cycle __ times" - same logic as "copy" but repeated
2. Maybe "create a repeating order cycle" that lets you choose the timespan and number of times to repeat with all products selected. Result would be a "chain" of order cycles where one opens when the other closes - good for super simple setups and product list that don't change. I thing the first idea would be totally sufficient.

Connected wishlist and discovery discussions* [list precedent discussions]

https://community.openfoodnetwork.org/t/create-order-cycles-in-bulk/1634

https://community.openfoodnetwork.org/t/enterprise-can-create-a-series-of-recurring-order-cycles/120

Additional context

This is an option in Local line that has been requested by new users. It really doesn't seem that different from clicking the clone button a bunch of times but it might feel different.

Is Papercut or feature candidate?

Add papercut or feature label to answer the question. If you are not sure, don't worry product team will cover :-)

[BethanOFN]

This feature has also been requested by UK users thanks for creating @lauriewayne , I agree idea 1 seems like the simplest implementation. Once we have developed this the next logical additional feature would be allowing producers to check a box to add products to all repeats of an order cycle (e.g. producer always provides items X, Y & Z to hub's weekly recurring cycle).

[RachL]

nice one @lauriewayne !

Dropping some notes before I forget them: deleting OC in bulk will be need as well (imagine a user repeating 100 OC by mistake 😁 ). And better performance. See this s3 bug: openfoodfoundation/openfoodnetwork#4544

[lin-d-hop]

I'm wondering if 'repeat x times' might create more problems than it solves and in fact we want to explore a more fully functioning 'repeat' system like in google calendar. Perhaps 'repeat weekly' might be a better first action that we then build off of.
Maybe there will be a cron job that runs on a certain regularity to create OCs for a time period in the future eg we only have OCs 3 months in advance at a time.

One for some heads to thing about :)

[RachL]

Not a papercut :(

[audez]

Thanks, we have this request a lot! Probably the most requested feature. Our users ask that the same cycle (with its products) repeat every week so they don't have to manually duplicate and edit dates. The ones I talked to didn't ask to have several OC in the future, they just want the same to automatically repeat.

So maybe there could be this solution which is easier:

• displaying a "repeat the OC" / "repeat weekly" checkbox
• if checked, create a scheduled task that will run at the OC end date
• when it's time, the scheduled task will trigger the OC duplication and replace the dates with dates corresponding to same date span.

So for one specific OC with repeat option, there would always be an ongoing one, and the history of previous ones.
Could this solution be a papercut ? 🤞

[BethanOFN]

One of our UK users wants to run a regular distribution route that allows customers to order only from the producers that precede them along the route. Their key requirements are repeating order cycles (as currently the only solution for 'producers before them on the route' is an order cycle per drop off location - unless anyone has a better idea!) and allowing enterprises to save products to a repeating order cycle (as more order cycles=more admin=more mistakes). They have asked:

Are there any developments in the pipeline you think could potentially help with this, or are there any possible system solutions which it may be feasible for us to fund the development of?

[lin-d-hop]

Hey folks,
I've put some thinking into what a solution to this can look like.
I worked through a few options. This feature is complicated by a few things:

1. Order cycles change week on week. So setting OC May3 to recur 10 times should not just copy May3 10 times. It should ensure that changes made on May10 are reflected in the May17 order cycle
2. Most order cycles are weekly. Some are monthly. Some are fortnightly. Some are sporadic eg Mon, Wed, Thurs each week.
3. Order cycle reoccurrences must work with subscriptions.
4. Some users want future order cycles to be on display to shoppers, while others dont. Some users want future order cycles to be editable by producers, while others dont.

The most long-term solution to this problem would refactor our order cycle model to separate the Sales Session information (Dates, shipping methods, payment methods etc) from the Offer information (a set of products for sale). Implementing this full solution would move us closer to a place in which stock and price could be controlled per order cycles, and producers could set up products on order cycles into the future AND OC could auto recur AND we could streamline subscriptions. This also brings us into closer alignment with the DFC standard. This solution is bigger than something we can tackle while we are tackling Network Revamp.

A more compact solution simply automates the task of duplicating hte order cycle. The technical implementation would be something like:

• Triggered on OC close (use webhook event?)
• If auto duplication enabled
• Update open date and close date by increasing by the specified amount eg 2 weeks
  This method allows all OC updates to flow through to each new duplication. It does not allow advance planning on order cycles. It does keep all the current flexibility on how many OCs to have open at a time eg if a user has 4 open OCs then each OC could autoduplicated to update the open and close date to 4 weeks in the future.

@BethanOFN @audez Would this solution meet the needs of your users sufficiently that they would be willing to contribute to the funded feature?

@openfoodfoundation/train-drivers-product-owners Do you see any issues with this solution?

@openfoodfoundation/developers Do you see any issues with this solution? Would anyone be willing to offer a t-shirt size estimate?

[RachL]

Nice @lin-d-hop !! This is exciting. It looks good to me.

If we work on estimates, I would be curious to learn what would be the estimate to start first with a manual repeat/duplicate option with no automated update/creation? And from there we could allow automation options additionally. It could be a way to ship something quickly before getting into automation.

I picture the manual version the same way a calendar is suggesting an event to be repeated.

The OC is copied with the new dates, but no other changes occur: all settings remain the same. It's the user who must edit manually. When they edit we could offer the option to apply the changes on all future OC that were duplicate from the same one or just edit the current one (but maybe this is even not something to propose in the v1 as it would require to keep a link between OC that were created out of the same original one).

So in this first release, no schedule task, no automated edits. We don't need the webhook to be released before to work on this.

One last thing: apart from the dates, we need a unique name as well. Do we keep the "Copy of" prefix?

[lin-d-hop]

Nice idea to estimate that and break up the development into smaller pieces. Would be good to know the difference in size. I imagine the funded feature would implement through to automation since that is the core need.

Just to note, the webhook doesn't need to be finished to do this. I suggested it as an implementation suggestion as it moves us closer to some of Davids ideas here.

[RachL]

I imagine the funded feature would implement through to automation

Me too! If it's an easy step, I see it as a way to handle all extra / edgy / wedidnotseeitcoming use case that can come up when people start using.

Just to note, the webhook doesn't need to be finished to do this

Alright! I also widely prefer webhooks to any scheduled task. On the long run scheduled task can always be a pain. I don't remember how many times in my life I've heard "oh yeah we've deployed and forgot to restart the cron task" :D

[tschumilas]

I am wondering what happens to product selections on the 'incoming' screen when the OC is duplicated.
If 'all products' has been selected on the original OC, I presume 'all products' remains selected on the repeated OC. Will NEWLY ADDED products be automatically selected? (At present, a newly added product is not automatically added to the OC.)
If product by product selection is used in 'incoming', I presume these same selections will be repeated.

[tschumilas]

Also about: "The most long-term solution to this problem would refactor our order cycle model to separate the Sales Session information (Dates, shipping methods, payment methods etc) from the Offer information (a set of products for sale)."
I understand this is a larger and longer term issue. I think there is potential to fund this. Is there a way to get a ballpark cost without investing much time?

[mkllnk]

I like Lynne's idea to duplicate an order cycle when it closes and adjust the dates. Duplicating the last one and not creating any in advance has the advantage that we don't have to update any future order cycles when making changes.

We have the OC clone already and would need to add a new field for the cycle period, e.g. 1 month. What's a good name or it?

• cycle_duration
• period
• repetition_duration
• repetition_time
• cycle_time
• repetition_rule

If we just add that field to the OC and modify the clone action to do this adjustment when its set then this could be done in a day. Triggering the rule automatically when the order cycle closes would take another day or two. Do we need to have a separate checkbox for that? I mean, is it useful to have manual renewals as well as automatic renewals?

Thinking of the bigger picture, I was wondering if we want a new automations table. Instead of attaching this data to the order cycle, we could define OrderCycleRepetition as our first defined Automation. Automations would have an event like order_cycle.closed, a name and metadata like "1 month" to work with. Our code could then look for automations whenever events happen and execute them. But maybe that's something to implement outside of OFN once the API and webhooks progressed? This whole automation could be in another tool.

[dacook]

Aoutmations: you just blew my mind! But yes, I agree with your conclusion. With more webhooks and API abilities, we could set up more automations specific to individual needs. Most likely building up our ecosystem in n8n I guess.

I like Lynne's idea too.
I think that if someone wanted to have some order cycles planned in advance they could do this also. For example, they set up four order cycles, for each of the next four weeks. Each of those is set up to repeat every four weeks. This might add a bit of extra admin (eg if you want to add a new product, you have to add it four times) but could be worth it in some cases.

[RachL]

I mean, is it useful to have manual renewals as well as automatic renewals?

I feel like yes. For 2 reasons: manual renewals can handle cases we haven't foreseen when setting up rules for automatic renewals. also automation can always fail, it's good to have a workaround on such feature.

But I guess we probably need to set up a limit in the X number of time we want to duplicate? I just realized that if the user create and then wants to delete, we don't have any bulk delete in place.

[lin-d-hop]

But I guess we probably need to set up a limit in the X number of time we want to duplicate? I just realized that if the user create and then wants to delete, we don't have any bulk delete in place.

I specifically designed this enhancement such that it does not create any future OCs in advance - the OCs are only created one at a time. This eliminates the need for bulk deletes or 'repeat x times' as it is one at a time - turn off when no more repeats needed. It also means that every edit to an OC will flow through to the next OC which is very important.

[RachL]

@lin-d-hop I was speaking about the manual option

[lin-d-hop]

Ah sorry. Do we not already have a manual option? The duplicate button.

The logic I used was to keep the automation as minimal as possible by basing it on the manual process.... which is to click this button ;)

[lin-d-hop]

I think that if someone wanted to have some order cycles planned in advance they could do this also. For example, they set up four order cycles, for each of the next four weeks. Each of those is set up to repeat every four weeks. This might add a bit of extra admin (eg if you want to add a new product, you have to add it four times) but could be worth it in some cases.

This is what people do now. Hence the proposed solution is an improvement. We just add the small enhancement to what people are already doing which saves time :)

[RachL]

Do we not already have a manual option? The duplicate button.

I don't see it as a solution to this need. I was speaking about a manual repeat option like you may have in a calendar. Work which is estimated at 1 day if I understand Maikel's post.

[lin-d-hop]

Okay I guess I'm not understanding something. The basic need here is to reduce the mundane step of going in every week/fortnight/day to click the duplicate button. You would manually say what the duplication cycle is (see image in the proposal). To manually duplicate outside of the duplication cycle you just do what you are doing now. I'm really confused now.

[RachL]

@lin-d-hop let's perhaps have a chat about it? When I've proposed to first estimate the manual option you seemed onboard, but it looks like we might have misunderstood each other.

The "manual" option as I see it is the same solution as you are proposing apart that it has no automated tasks: OC are created in advance, it just removes the need to click multiple times on the duplicate button. It creates all OC in advance. No automated update.

[lin-d-hop]

I think we need to avoid having the OCs created in advance. This creates problems as producers and hub manages edit an OC and then need this information to flow through to future OCs. Personally I think that while OFN logic puts sales session and offer info into the same model we need to be careful to avoid creating OCs in advance.

[lin-d-hop]

Yes I see now that I misinterpreted your original message. I am actively advocating against creating any OC in advance. Lol, in case that's not clear 🤣

[lin-d-hop]

@tschumilas

I think there is potential to fund this. Is there a way to get a ballpark cost without investing much time?

Tshirt size - very large. I would say 10-30 dev days -> 10000-30000 euros. But we can't work on this until after network feature so we wouldn't be able to deliver this year. How confident are you on the funding?

[tschumilas]

We are writing a proposal with flower hubs now so no money in hand yet. Our plan is to ask for development funding - $20,000 in year one (current year) and an additional $20,000 in year two. We are limited by what we can propose because we need matching funding, and this is the best we can do. BUT - we are going to ask the grant officer if its possible to consider foreign partners - and if so, can we consider global pot money as 'matching'. That opens up possibilities if we can do that.

Regardless - there are a range of issues that flower hubs want- and most of them are the same as other issues in our pipe anyway - so we won't propose things too specific. And we can see what the immediate need is when/if the funding materializes. But estimate is good - helps me ballpark. Thanks.

[RachL]

I am actively advocating against creating any OC in advance

Ok, your call 👍 . I guess my main concern is that as the OC is created only when the previous one closes, if the creation fails the user only know it last minute. But let's try it, maybe I'm just too pessimist on automation :D

[mkllnk]

I propose the following steps then:

Step 1: Add the optional field repetition_period to the order cycles. If it's set then the clone will adjust the start and close times accordingly (start_time += repetition_period).
Step 2: Add the option to "repeat automatically". When selected (requires repetition period), the order cycle closed event clones the order cycle.

Each of these can be a papercut.

[lin-d-hop]

@mkllnk Above you said 2-3 days total. Now you say 1 day total. Not sure about that 🤔

@RachL Perhaps we need to include an email to the hub manager(s) when the OC opens "Your next ordercycle has opened". That way the user will know when they receive the email that it worked. That might help with automation nervousness (which I share)

[BethanOFN]

I'm going to take this back to the interested UK user thanks all, @audez & @lauriewayne do you also have users who could potentially fund?

[kirstenalarsen]

Wow this is cool, very cool. I can't help wondering if there's some little gem out there that manages repeat cycles with all the options like in a google calendar, surely someone has done that. Like https://stackoverflow.com/questions/5301283/ruby-gem-to-handle-recurring-calendar-events? Very elegant way to get around all the problems, nice one

[audez]

Hi! Does it have to be funded if it's a papercut? If yes, do we have an idea of the total amount (so we can tell the users if we're talking about a participation of 10€ or 100€)? Thanks in advance :)

[mkllnk]

@lin-d-hop

Above you said 2-3 days total. Now you say 1 day total. Not sure about that

Uncertainty adds time in the estimate. Now that I have a specific solution on my mind, the implementation seems straight forward. But I didn't account for unknown complications in the papercut estimate. And it depends a little bit on the state of the webhooks work. It's quicker if the order-cycle closed webhook work is done when we start this work. Part we can also do some of that event triggering work here, which could add a day.

The first part, adding a repetition_period and using that during clone is simple and is not depending on anything else. We can do a quick version in a papercut or we can put a bit more effort into it, discussing wording more, spending time on the UX and then this part can become one or two days. It's all flexible.

[mkllnk]

@kirstenalarsen

I can't help wondering if there's some little gem out there that manages repeat cycles with all the options like in a google calendar, surely someone has done that. Like https://stackoverflow.com/questions/5301283/ruby-gem-to-handle-recurring-calendar-events?

Nice find. The mentiond ice-cube gem does too much for our simple case but could become handy if we created more event rules like it. But it lead me to the iCalendar spec which has a nice format and terminology. We need only the rule part of it but that's a good guide. So for a fortnightly order cycle, we can store:

RRULE:FREQ=WEEKLY;INTERVAL=2

We can extend that over time, most work in adding the UI and then use the ice-cube gem to calculate the next dates. Supported examples are:

• Monthly on the 1st Friday for ten occurrences: RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
• Every other week on Tuesday and Thursday, for 8 occurrences: RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH