-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
Description
π I have found these related issues/pull requests
This issue follows a discussion here: #7042 (comment)
π Feature description
Right now, upon new maintenance creation, start datetime and end datetime are not linked whatsoever: it's even possible to set a end time which predates the start time without raising any error.
All of this could be slightly smarter.
βοΈ Solution
I see this issue in three parts:
-
The end datetime could be modified dynamically upon modification of start datetime:
-
When start date is changed manually, use the currently selected duration to re-compute the end date accordingly. For instance:
- Initial situation:
- Start date set to 24/02/2026 01:00
- Duration set to 1 hour
- Implies end date set to 24/02/2026 02:00
- Change: Start date changed to 24/02/2026 03:00
- Provokes setting end date to 24/02/2026 04:00
- Initial situation:
-
The only exception to that should be when the user has already modified the end date manually. In that case, just select the matching duration, if applicable.
-
-
Changing end date or duration should keep the same behavior as the current one:
-
When end date is changed manually, select the matching duration if applicable (start date does not change)
-
When duration is changed manually, re-compute the end date accordingly (start date does not change)
-
-
Regarding coherence between start and end: if end date predates start date, I would say:
- Either raise a UI notification
- Or raise an error upon trial of saving
- But do not reject input right away (upon end date modification)
Because, maybe the user want to first change the end date, and intended to change the start date just right after that (in that case, rejecting the input would feel unpleasant).
β Alternatives
N/A
π Additional Context
N/A