Need to support adding collaborators.

[tpolecat]

Ok @andrewwstephens this is the simplest collaborator workflow I can think of:

1. The pi asks Explore to issue a collaborator token. This token structurally looks like an API key (it has its ID as a prefix, followed by the token itself). We remember the token id, the program id, and a hash of the token. The PI can then given the token to the potential collaborator.
2. The collaborator logs into Explore and asks to redeem a collaborator token. If the token is valid the user is added to the associated program as a co-i and the token is deleted from the system.3.
3. If the pi changes their mind they can delete the outstanding token.

A slightly better workflow would email the token directly to the collaborator. We will need to figure out how to send emails, so this seems like a reasonable step 2, for XT.

Requiring collaborators to log in at least once seems like an ok constraint for XT. Non-user collaborators is a complication I'd like to avoid, or at least put off if we can.

What do you think?

[andrewwstephens]

If a PI enters a list of collaborators and provides the ORCiD of each, would that be sufficient to identify those users and allow them to access the program?

[tpolecat]

I think the only difference in that case is that we could look up the collaborator's info and add that to the pending table. But they still need to affirmatively accept the invitation, don't you think? Seems like you wouldn't want to be added to someone's proposal without knowing it.

So what I'm saying is, if you have to log in to click "accept" then you could just as easily log in and paste a code someone gave you, and it doesn't require you to have an ORCiD id beforehand.

[andrewwstephens]

We currently don't require CoIs to confirm their participation. I remember a discussion about this with the NGOs long ago, so I'll have to try to dig up if there was a decision.

Could we perhaps show the full list of CoIs and indicate which have confirmed and which have not?

Could the confirmation be achieved by clicking a link in an email, like we see in 2FA emails?

That's a good point that some CoIs might not have an ORCiD, so it would be advantageous if they could confirm participation without having to register.

[andrewwstephens]

I chatted with Bryan about this and here are the highlights:

• don't want to force CoIs to have an ORCiD
• don't want to force CoIs to confirm participation, as this could delay submission.
• suggest sending an email when a CoI is added: "You have been added to the proposal "Title" by "PI" click here to access the proposal."

This notification email would give CoIs the opportunity to read the proposal, and if they decide that they don't want to participate they can email the PI to be removed. Or if they have edit privileges, they could even remove themselves?

[tpolecat]

What do you mean by "read the proposal"?

[andrewwstephens]

If PI Jill adds CoI Jack, then Explore sends an email to Jack with a link to the program.
If Jack wants to view the proposal he needs to authenticate using his ORCiD.
If Jill included Jack's ORCiD in the program then Jack should now have access.
If Jill only knew Jack's email then we need to get Jack's ORCiD and add it to the program as a CoI. Is this where the collaborator token comes in?

[tpolecat]

Yes, that's what I was getting at. We can try to hook it up via email (this is part of the user record if it's public in the ORCID record) but if the email address isn't in the ORCID profile or the CoI used a different email address to authenticate then we need to provide some kind of token for them to enter. If we send them a token but never ask for it (in the case where emails match) it seems like that would be kind of confusing.

So I return to my original idea of just doing this with a token, which removes a lot of complexity and weird cases.

[andrewwstephens]

Got it. That sounds reasonable.
Is it possible to handle the token in the URL we send, potentially simplifying the process for users?