Submitter role upgraded to let them mark submissions

[ACharbonneau]

It turns out we have two different Approver personas:

• Approvers like Avi who want to go though submissions and personally verify them
• Approvers like Phil, who want to have their Submitter do all the leg work and just do a perfunctory sign off

Right now, we only support Avi like approvers. I'd like to make some minor changes to support Phil like approvers as well.

Currently, Phils group has ~30 submissions and no easy way for their Submitter to tell their Approver which one is the 'good' one.

How I imagine this might work is:

1. Submitter submits several datapackages
2. Submitter looks at datapackages and believes 1 or 2 are the ones their Approver should focus on
3. They click on 'edit' for the correct package(s)
4. For 'DCC Approval Status' they can set it to either "rejected" or "proposed"
5. Then when their Approver logs in, they can use the existing "DCC Approval" facet to filter to only "proposed" datapackages

We would not constrain the Approver to only be able to approve "proposed" datapackages, so Avi like personas could continue to do their own validation workflow. But for Phil like personas, the Submitter would be able to direct the Approver to a small number of choices.

nih-cfde/published-documentation#196

[karlcz]

We can do parts of this easily but the UX might be imperfect for a strict mode. It would be easier if we could assume trust between these parties (not unreasonable, in my view) rather than trying to do super strict enforcement:

1. Add that submitter to the Approvers group if they've been read in on the new protocol to follow
2. Add this "proposed" or "nominated" term to the approval status vocabulary.

Both Phil and his submitter would be technically capable of selecting "approved" or "nominated" but would in practice follow the convention you outlined to signal between them. This could be adapted by other groups who want to do a buddy system for approval too, e.g. first reviewer nominates and second reviewer approves to confirm.

[karlcz]

The other approach which would have some UX flaws right now would be to add the new term and a more complex policy to allow submitters to set this nominated state (and maybe rejected state?) but not approved state. However, the current Chaise UI would offer all the choices, leading to that annoying try-and-see UX where it gives a forbidden error only after the submitter tries to submit with the approved state...

[karlcz]

Further offline discussion leaves us thinking this new "planned" state can be available for all submitters but we should include the strict enforcement to require approver role to set other states.
The drawback is that the UI will not indicate this restriction until we get a general fix for this policy-awareness in DERIVA. The submitter won't know it is fruitless until they click "submit" and get rejected. We'd have to just mitigate with documentation and training...

[ACharbonneau]

I think for right now this should be a backlog issue, and we can revisit it later. I can talk to the DCCs about whether they would be able to do the easier approach and mitigate any internal disagreements themselves, but I would want to make sure that sort of lite policy will be practical before we put any work into it either way