Progress review agenda 5 July 2022
Hi @lathrops1 @Kireev @latternm @ErinS @deniskar @douglassue @jordandc @jeffbeckncbi
(cc @John.kopanas @danjela @DioneMentis @sidorelauku @bela @vignesh03 @Shanthi_B @pokhi @shubtiwari)
In this week's review call I want to focus on reviews of ready issues to make sure they are complete before handing off to a development milestone. NCBI team feel free to add to the agenda by commenting here.
Book versions
Dashboard view
Since we are not doing #1211 (closed) now, we will need to show all versions of a book on the dashboard in separate rows (that is a change to what we discussed in the original scoping but since #1211 (closed) is not marked for MVP, doesn't make sense to do now). You will only be able to access the versions for which you are part of the version team.
We want to display a warning message when visiting all non-latest versions to alert the user when they're not in the latest version, the warning can be dismissed and reappears when you next visit the page.
In the future, when we do the back end permissions issue (#1211 (closed)) to only show books you have access to (not all books in your organisations) on the dashboard, this can be further developed to only show versions you have access to, or only the latest version as discussed in scoping.
Restrict subsequent versions with lower version numbers
Stacy provided wireframes in #1264 (closed) indicating that lower version numbers should not be allowed in the next version. In other words, if you create version 2 first, you then can't create version 1.
From the technical perspective we can create a validation from the front and back ends to introduce that restriction. It's a bit more work but can be done. I just wanted to double check that in no use cases will you need to go down a number, and that the restriction is required at this stage.
Override OA agreement status
As in #1275 (closed), there is currently a toggle in book settings for 'Open access status' that can be updated by Sys admins. But from #933 (closed) we know that the NCBI also expects this toggle to be updated by agreement check 2 when the book is published. We need a way to allow Sys admins to override the OA status that is fetched from the agreement, so that an OA status can be manually added and not overwritten when the agreement check is run, for example in cases where the agreement is not compatible with updating the OA status correctly.
We need another override, to function is the same way, for the UKPMC setting. Since there may be cases where you want to take the UKPMC setting from the agreement, but set the OA setting manually, there will need to be two separate override toggles, which allow each of these to be set manually and not updated by agreement check 2.
I just want to clarify the following to finalise the scope:
A requirement for this issue is that we will be able to migrate independently JUST the main OA settings from our Domain Tool values for these settings, and not have to curate them further. If changes are needed post migration and deployment, then we would add this override setting.
Which override setting is being referred to here?
Is there anything else about the migration I need to understand to make sure this is developed correctly?
We are adding manual override toggles for OA status and UKPMC settings, so is that sufficient for the scope of this development or is there anything else? Of course in the future we want to introduce a check to keep the OA status in metadata (read from the converted XML) and settings (updated based on agreement check 2 or by Sys admin) in sync, but that is not part of the scope now.
Confirming scope of grants and funding toggles
As Stacy provided in the review call last week:
ONLY System Admin have permission at deployment to:
- Add a Grant
- Turn off/on toggle
This is current functionality.
I discussed this with my team today, AND we decided the following would be best for deployment, with the following assumptions:
Toggle All should be available for on / off for chapter-processed books Toggle All should be turned automatically off for all collections; we can decide if it should not show in UI in future
This is current functionality, but some toggles may have been turned on by testing users on your testing sites. So do you need a migration done for this, so that all collections on your testing site have this toggle off by default now (and the books which inherited those grants to have their inherited grants removed too)?