peer_reviewed_article: Show review checklist #352
No reviewers
Labels
No labels
Component: User interface
Component: Wymeditor
Help wanted
Level: Difficult
Level: Easy
Level: Moderate
Pagetype: Festival
Pagetype: Mailinglist
Pagetype: Peer reviewed article
Pagetype: Text
Privacy GDPR AVG
status: has conflicts
Status: Needs changes
Status: Needs discussion
Status: Needs review
Status: Ready to merge
Status: Waiting for response
Type: Bug
Type: Enhancement
Type: Question
Usecase: De Stadsbron
Usecase: Koppelting
Usecase: MeetjeStad
Value: Coders
Value: Security
Value: Users
Value: Visitors
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
harmen/hypha!352
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "article-checklist"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In the DRAFT, REVIEW and APPROVED stages, this shows a checklist of things to do before progressing to the next stage, which helps to quickly see if anything is forgotten.
Some of these things are marked as required, meaning they prevent progress (i.e. starting review or publishing). Others are marked as recommended, meaning they are shown but not enforced. Whether something is required or recommended is hardcoded for now, but the code is writting to allow making this configurable later.
This additionally does some more or less related factorings and small cleanups.
The new functions have very verbose type definitions (intended to be consumed by Psalm), we will have to see if this is workable or simpler types should be used (which allow less checking).
Originally, I had intended for
updateToNewStatusto also check the checklist and prevent state changes when the checklist was not completed, which would allow removingcanBeSetAsApprovedentirely (just try to set the status toAPPROVEDand if it fails, e.g. because the checklist says more approvals are needed, just ignore that failure). However, it turns out this could create a corner case where removing e.g. all tags after review start would prevent the status from progressing toAPPROVED, so I ended up only checking the checklist instatusChangeAction. This results in code that is a bit more messy, but should be correct. @laurensmartina, any suggestions on this?This fixes #304.
Here's an overview of all the possible text that can be shown. Note that this includes situations that cannot occur with the current code or even do not make real sense (i.e. article content will probably always be required), but I've added them all to allow future expansion.
Here's how an empty draft article would look in practice:
Here's how a complete draft article would look
And here's the various ways an article under review can look
Here's the various ways a draft article could look with different settings
Perfect! Next step: make it configurable. :-)
The comment block is not correctly formatted
Here there should be an empty check.
The status gotten from
getStatus()does not change while being in this method, so it would be better to assign in to a variable outside the foreach loop.Typo at
returneStrict comparison is recommended.
didn't know a better place to put this comment.. There is a typo in the commit message
Fixed.
Fixed.
Good call, fixed.
Fixed.
Still not fully in my system ;-)
Fixed.
Found it, fixed :-)
Yup :-)
Fixed all comments, I think this should be ready to merge now (after squashing the fixup commits).
I changed the checks slightly, so an article body with tags, but with an element like
imgoriframeis also acceptable. For the other fields (excerpt, sources and method), text is still required.I squashed the fixups and rebased on master, merging next.