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 11 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 11 months ago
- Start date changed from 2024-01-17 to 2024-01-18
- Follows Feature #2157: Dates: improved autocomplete added
Updated by Alexander Watzinger 11 months ago
- Status changed from New to Acknowledged
- Target version set to 8.7.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.
Updated by Alexander Watzinger 4 months ago
Because of missing feedback regarding the last comment, we will discuss it in the next developer meeting.
Updated by Bernhard Koschiček-Krombholz 4 months ago
Results from the developer meeting:
Through the discussion the solution, that begin_from and end_from shouldn't be mandatory anymore for date entry. A user could enter end_to without entering end_from. This will have followings effects:
- UI
- a change of the UI is not necessary if the begin_from and end_from fields aren't mandatory anymore
- but if the feature is implemented, the date fields need specific tags/names with a mouse over description
- Implementation
- since data from before was entered with the current premises, a change of "old" date entries in the database is NOT necessary
- API can move the end_from date to end_to date if only one end date was entered. But we need to check, how this will affect current frontends
- Conception
- how to deal with automatic creation of timespans. If only a year is entered in end_to, will a timespan be created, or just the last day of this year?
Please feel free to adapt/change this list.
Updated by Bernhard Koschiček-Krombholz 4 months ago
- Assignee set to Bernhard Koschiček-Krombholz
Updated by Alexander Watzinger 4 months ago
- Status changed from Acknowledged to Assigned
Updated by Alexander Watzinger 4 months ago
- Status changed from Assigned to Acknowledged
- Assignee deleted (
Bernhard Koschiček-Krombholz) - Target version changed from 8.7.0 to Wishlist
Because we again didn't come to a conclusion in the last Developer Meeting and even new ideas were introduced spontaneously (which I would prefer to be discussed in separate issues) I'm moving this issue to the wishlist.
Once it is clear enough what and how to implement it, it can be moved back to the actual roadmap again.