5
11
Fork
You've already forked tomato
1

Splitting events with defined counts honors the remaining count #10

Merged
edwardloveall merged 1 commit from el-fix-repeat-x-times into main 2025年08月11日 15:50:08 +02:00

Fixes https://gitlab.com/food-rescue-alliance/tomato/-/issues/238

  1. Create a recurring shift with a defined count (say 4)
  2. Update a shift part way through the count (say 3rd) and chose "this and following events"

You'd get 4 new shifts plus the 2 shifts before the edited one. Not great!

The problem was that editing "this and following" duplicated the event properties, including the rrule which includes the UNTIL attribute unchanged. It knew to modify the old event to stop at a particular date, but not the new one.

The fix came in three parts:

  • The old event's COUNT is removed (along with the UNTIL still being set)
  • The new event's remaining COUNT is calculated
  • If the user also updated the recurring options in the UI, we ignore the new COUNT and just use what they passed in.
Fixes https://gitlab.com/food-rescue-alliance/tomato/-/issues/238 1. Create a recurring shift with a defined count (say 4) 2. Update a shift part way through the count (say 3rd) and chose "this and following events" You'd get 4 _new_ shifts plus the 2 shifts before the edited one. Not great! The problem was that editing "this and following" duplicated the event properties, including the rrule which includes the `UNTIL` attribute unchanged. It knew to modify the old event to stop at a particular date, but not the new one. The fix came in three parts: * The old event's `COUNT` is removed (along with the `UNTIL` still being set) * The new event's remaining `COUNT` is calculated * If the user _also_ updated the recurring options in the UI, we ignore the new `COUNT` and just use what they passed in.
Splitting events with defined counts honors the remaining count
All checks were successful
Setup Successful
Jest Successful
RSpec Successful
Static Analysis Successful
b0abd852e2
1. Create a recurring shift with a defined count (say 4)
2. Update a shift part way through the count (say 3rd) and chose "this
and following events"
You'd get 4 _new_ shifts plus the 2 shifts before the edited one. Not
great!
The problem was that editing "this and following" duplicated the event
properties, including the rrule which includes the `UNTIL` attribute
unchanged. It knew to modify the old event to stop at a particular
date, but not the new one.
The fix came in three parts:
* The old event's `COUNT` is removed (along with the `UNTIL` still
being set)
* The new event's remaining `COUNT` is calculated
* If the user _also_ updated the recurring options in the UI, we ignore
the new `COUNT` and just use what they passed in.
@ -13,3 +13,3 @@
volunteer = User.create!(
email: "volunteer@foodrescuealliance.org",
full_name: "Volunteer",
full_name: "Ray Fillet",
Author
Owner
Copy link

Unrelated but I found this helpful. In hindsight calling a Volunteer "Volunteer" wasn't the best way to make form fields with the label Volunteer particularly clear.

Unrelated but I found this helpful. In hindsight calling a Volunteer "Volunteer" wasn't the best way to make form fields with the label `Volunteer` particularly clear.
@ -6,2 +6,2 @@
eventable { create(:shift_event) }
ownable { create(:organization) }
eventable { build(:shift_event) }
ownable { build(:organization) }
Author
Owner
Copy link

Been trying to remove create in factories when I see them. They prevent me from ever creating factories that don't create items in the database.

Been trying to remove `create` in factories when I see them. They prevent me from ever creating factories that don't create items in the database.
thetizzo left a comment
Copy link

I think the logic changes here match your description of what is being fixed so that checks out but to be honest I am a bit confused by what an RRule is.

It seems like the RRule is a string representation of how the event should recur but then there are also event.recurrence_options that seem similar? Is one just a parsed version of the other?

I think the logic changes here match your description of what is being fixed so that checks out but to be honest I am a bit confused by what an RRule is. It seems like the `RRule` is a string representation of how the event should recur but then there are also `event.recurrence_options` that seem similar? Is one just a parsed version of the other?
Author
Owner
Copy link

Yeah, you got it. RRule's are neat. Like you said they represent how an event can repeat and stop and exclude certain dates, etc. I found a good visualizer for them at https://jkbrzt.github.io/rrule/

And yes, recurrence_options is that string parsed into a hash.

Yeah, you got it. [RRule](https://datatracker.ietf.org/doc/html/rfc5545#autoid-100)'s are neat. Like you said they represent how an event can repeat and stop and exclude certain dates, etc. I found a good visualizer for them at https://jkbrzt.github.io/rrule/ And yes, `recurrence_options` is that [string parsed into a hash](https://codeberg.org/rootable/tomato/src/commit/0bb8c8a/app/models/event.rb#L39-L47).
edwardloveall deleted branch el-fix-repeat-x-times 2025年08月11日 15:50:20 +02:00
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
rootable/tomato!10
Reference in a new issue
rootable/tomato
No description provided.
Delete branch "el-fix-repeat-x-times"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?