manifold
manifold copied to clipboard
ManifoldScholar
Allow partial publication dates (year only, month and year) on projects and texts
The publication date fields require all three elements to be present (m/d/y); otherwise all three fields revert to an empty set. Oftentimes publishers will not have a day at the ready to describe a project's publication. It would be better if it was possible to enter y, m/y, or m/d/y equally.
I think this warrants a little discussion about how this change will effect references to the date in the app, unless there is a simple implementation I'm overlooking.
- How do we want to treat dates that are missing a day or month?
- Should the publication date column become a string? Should it be 3 separate columns that we assemble and parse later?
- Should missing attributes default to the 1st, i.e., 1999 => 1999/01/01 in the db?
I think we should do the following:
- Allow publishers to set y, m/y, or m/d/y as the publication date.
- Create a field called "publication_date_sortable" or something. Have that field auto-generate on save based on the value in publication date. For sorting purposes, let's default to the beginning of the month or year. So, 1/2018 == 1/1/2018. 2018 === 1/1/2018.
@tsmyre what do you think?
So the sortable field is really only for the system and not as a display element, correct? I think that makes good sense.
Yes, that’s what I’m thinking.
On Fri, Jul 13, 2018 at 1:58 PM Terence [email protected] wrote:
So the sortable field is really only for the system and not as a display element, correct? I think that makes good sense.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ManifoldScholar/manifold/issues/906#issuecomment-404923408, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPnpYI5stfK2BHqFmWPfdOzKUjbe_--ks5uGO3VgaJpZM4TBNif .
Thank you for taking the time to open this feature request. The Manifold team reviewed this issue during our bi-weekly meeting and the consensus is that this feature makes sense and is in keeping with our overall vision for the platform. Moreover, we see this request as a viable candidate for development under our current available funding. We’re adding an “accepted” label to this request to indicate that it’s within scope and possibly within budget.
The next step is for us to estimate the work involved with this and add it to our feature backlog. Our acceptance of the issue is not a promise that it will be implemented. We will balance this request against the other accepted requests and do our best to implement it within our current available funding.
This was an automated message, but please don't hesitate to reply. Our team watches these issues closely and will respond as soon as we're able to!