LIGO Default Valid From/Through for cm_co_person_roles

We want to try and capture the default valid from and valid through for as many LIGO enrollment workflows as possible.

The emphasis here is on the enrollment workflow for COs and COUs, not every possible role to be played in LIGO and managed separately in a group.

Remember the distinction between a CO/COU and a group is the amount of "business process" necessary to manage onboarding and offboarding. If the drivers for entering or leaving are simple it is probably a group--if they are complicated then it is probably a CO/COU. 

This is not the place to try and capture the detailed and complicated nested COU relationships.

We are working with these CO definitions:

• LIGO Laboratory
• LIGO Collaborators (as a better label than LSC)
• Virgo

Open Questions

cross these off as they are answered

• Is there more than one class or type of undergrad student role?
  • Warren: Probably. At the very least, there are undergrads that are authors and those that are not.
• Are the valid from and valid to always shown during enrollment?
  • Warren: It doesn't matter to me whether they are shown or not, but they must always be set, whether automatically through some algorithm or by hand. There should always be an option to override the automatically generated values manually.
  • Stuart: Yes.
• Can we optionally not have a default to force data entry?
  •  Warren: Could be annoying. We should field test this.
  • Stuart: Yes, e.g., when adding a contractor I think there will be a wide range of values and the sponsor should be forced to enter something.
• Should "no expiration" be capped at something like 3 or 5 years?
  • Warren: I think so. 
  • Stuart: Yes.
• Are we moving towards a model in LIGO where each enrollment across all COs and COUs needs to include a sponsor?
  • Warren: If it would make it easier, we can move toward such a model where some enrollments are allowed to be self-sponsored. But in general, I think the current model of allowing people to initiate the process themselves is a good one.
  • Stuart: I think so, even if it is automatically populated in Warren's example.
• Currently we have no affiliation for Virgo other than member. Should we break that down into at least Member and Student?
  • Warren: I really don't want us to be responsible for any information about Virgo members we don't need. Unless there is some reason for us to care about their particular roles within Virgo, I would prefer not to keep it. But, it is quite possible that we will find a  need for more information at some point.
  • Stuart: No. I agree with Warren the less information we manage for Virgo identities the better.
• Is the public information officer a valid affiliation? Is that really a role that requires an enrollment? Can it be a person external to the collaboration (consider federated identities)?
  • Warren: PIOs need to be authenticated and to have certain authorizations as a group. Right now, the way we handle getting them a  credential and creating authorization groups for them is via enrollment. If there is a different mechanism for handling that on the table, we should examine it.
  • Stuart: Yes, and I think administrative assistants may be as well.