Progress review agenda 7 June 2022
Hi @lathrops1 @Kireev @latternm @ErinS @deniskar
(cc @John.kopanas @danjela @DioneMentis @sidorelauku @bela @vignesh03 @Shanthi_B @pokhi @shubtiwari)
Here is the agenda for the progress review meeting today. NCBI team please free to comment here if you want to discuss anything else today.
Update on current development focus
Our current development focus is on book versions, changes to permissions, changes to supported file extensions, priority fixes for collections, and priority fixes to the metadata modal.
Since our lead developer's input was required for the scoping sessions and resulting development estimates, book versions development is delayed by a proportionate amount to that time taken.
Permissions work continues in line with the current specifications on the BCMS role permissions sheet. If changes are required from that (for images or supplementary files) please let us know as soon as possible. Until then we will continue development assuming these permission specifications are final for the deployment 1 phase.
I have received notifications queries from NCBI and will respond to them this week so we can finalise notifications text.
Monograph chapter-processed workflow proposal
We would like to focus today's call on finalising queries in #1152 (closed).
We want to validate the metadata diagram in this comment and get as much information for the queries in that comment as possible, to move towards clear specifications which will inform our estimates.
Proposal for simplifying date validation text
We don't need an answer to the following in today's meeting, I want to explain the proposal briefly as requested by Stacy.
In #1245 (closed) I have proposed a change to date validation help text. Date validation text for date ranges was conceptualised and developed when the signed off specifications were to support year ranges only (YYYY-YYYY) (#423 (closed)), since then we added months to date ranges at NCBI's request (to support MM/YYYY-MM/YYYY) (in #947 (closed)). Recently, in #1216 (closed) (relevant note here) it was requested that we add days to these ranges now. With the currently developed cases to support MM/YYYY-MM/YYYY, we have 16 different variations for the help text that appears when a user provides incorrect or incomplete dates in date ranges. Once days are added to date ranges, we have to validate an additional 38 unique combinations. We can add this validation (to prevent the user from saving the metadata with incorrect or incomplete dates) but the help text itself, which tells the user exactly what is wrong with their date, need not be unique for each possible variation of incorrect or incomplete date, and development effort for unique validation/help text might be better spent elsewhere. I propose that for all cases where the date format provided in date ranges is not correct and can't be saved, show the following validation help text:
Valid date of publication range is required. Supported date formats are: Year–; Month/Year–; Month/Day/Year–; Year–Year; Month/Year–Month/Year; Month/Day/Year-Month/Day/Year.