Feature #2156
open
Dates: change end data functionality
Description
As discussed in the last Dev meeting, here are the ideas for the overhaul of the date entries:
How to map the dates (both for begin and end)if only a year YYYY is entered: set begin_from to 1.Jan.YYYY and begin_to to 31.Dec.YYYY (respectively for end_from, end_to) Same for month and day (already covered in #2157)
For end dates, now the end_from is the mandatory field. This should be changed to end_to - this way we have the limits defined by the earliest begin and the latest end.
If in begin or end one of the two dates is entered narrower than the other this could be solved like this: for _from values, choose the earliest possible date: eg. 800 would be 1.1.800, for _to values the latest possible: e.g. 31.12.
Validate if the date is smaller resp. bigger than the other.
One question is how to implement this in UI: maybe only with one line/field that can be expanded?
Updated by Alexander Watzinger 3 months ago
- Subject changed from Date Overhaul to Dates: change end data functionality
- Description updated (diff)
- Category set to UI
Thank you for reporting and additional information. There already was one issue about date auto complete which I deleted to avoid duplicates but than recreated to not mix different topics. See #2157: Dates: improved autocomplete
Updated by Alexander Watzinger 3 months ago
- Start date changed from 2024-01-17 to 2024-01-18
- Follows Feature #2157: Dates: improved autocomplete added
Updated by Alexander Watzinger 3 months ago
- Status changed from New to Acknowledged
- Target version set to 8.5.0
I agree on spending some time on an overhaul of the data form fields for easier data entry but about the suggestion:
For end dates, now the end_from is the mandatory field. This should be changed to end_to - this way we have the limits defined by the earliest begin and the latest end.
As far as I remember you suggested this because it seemed more consistent for you but as discovered in the last developer meeting there are mixed views about that.
From a practical perspective: we would have to rewrite the backend, the API and the frontends. Also it would be a breaking change and we have to keep in mind that other may be already using this in their adaptions of accessing information in OpenAtlas (e.g. having developed their own presentation site). And of course we also would have to adapt our own legacy presentation sites.
So a lot of work and chances to break things and the question is what would be gained by this change and if it justifies the effort.