Feature Request: Durations for tasks/chores/meal_plan items

[DellanX]

Previous issues

This would be re-opening issue #1689. I'd like to propose this gets built into Grocy, instead of just being a userfield.

Rationale

For tools such as calendars consuming things such as Meal Plans, Chores, Tasks, it'd be nice if the duration of such tasks could be consumed. This could then populate a duration field on the ical feed, which can block off time for things to be completed.

I am working on adding calendar support for home assistant's grocy custom component, which will require both start/stop times. Which for now, I will just assume a 1-hour duration for all items. (This isn't ideal)

While this could be resolved by a userfield, I fear consistency issues with multiple users.

Implementation Requirements

This could just be an optional field in Grocy on things that take time to complete (meal_plan, chores, tasks).
If not specified, then return null. (Leave it to the consumer to guess)

For rendering, the duration should probably just be a field in the HH:mm:ss format, which will be converted into a timerange, which would be stored in the DB as an amount of seconds.

Further notes

I am willing to help implement this feature, but need some help on the desired direction. Otherwise, I'd probably go with:

• Add a duration field to the database, being a nullable unsigned integer
• Add an optional HH:mm:ss field to the pages for creating/editing meal_plans, chores and tasks
  (This is where I'll probably struggle)

[berrnd]

Basically I already decided in #1689 to not add that beyond what's possible with Userfields but of course ignoring that and creating the same request again and again is an option - so I'll leave this just open.

[DellanX]

To restate, I am willing to develop the feature. I realize it's probably not something everyone would use. My target is more on the calendar support side than the original issue I am citing.

Do you have any preference on how I go about implementation? Or should I just go for it and PR?

[berrnd]

Do you have any preference on how I go about implementation? Or should I just go for it and PR?

I have not, since I'm not thinking about every single request in-depth before actually implementing it. This also means I cannot guarantee that anything regarding that will be merged.

I realize it's probably not something everyone would use.

Then make sure it's optional, people even complain about visible fields they don't need and want "hide this"-functionality for each and every single detail.

[DellanX]

Okay, I'll get started on it then. If the idea is to hide the fields too, then I'll try the following:

1. Make a feature flag for durations
2. See if I can conditionally add a column migration for durations, keying off the flag
   If I cannot reliably do so, then I'll see if I can just make a seeder for a userfield, to force naming consistency.
3. I'll make the UI field, also keying off feature flag
4. I'll start to add the logic to the ical feed and API endpoints to populate duration as an output, also keying off of feature flag

[berrnd]

Make a feature flag for durations

Currently feature flags are separated between "major features sets" (= stock, chores, recipes, etc.). So one would not fit that.

See if I can conditionally add a column migration for durations, keying off the flag

Really bad idea, the database schema is of course the same regardless of what feature flags are enabled or not. Feature flags are (mostly) about hiding UI stuff only.

 
If you start working on that and intent to have this merged at some point in time, please do extensive tests beforehand, including edge cases and stuff. It happened too often so far that contributions touching multiple areas of Grocy introduced more after-work on my side than simply doing it completely.