Talk:UC AWOB PM 02 Invite Collaborators

MPDL,GAVO

Overview
Invite collaborators to a project includes the following steps: whether they want to collaborate with a particular role on the project.
 * select one or more individuals to whom an invitation is sent with the request
 * invitees can choose to accept/reject the invitation.
 * those who accept are added to the project with a specified role.

Complication arises since different kinds of individuals can be invited. We want to support inviting registered AWOB users through AWOB, as well as individuals via email. The latter should be offered the chance to register before accepting the invitation. After the registration they should be added to the project, and the appropriate mailing list. Alternatively they may decide (if allowed) to join the project only as an "email user".

Status/Schedule

 * Status: Specification
 * Schedule:Demonstrator

Triggers

 * A project PI or Co-I wishes to invite scientists to join its project.

Actors
For actor definitions see AWOB concepts Actor
 * Inviter
 * who invites an individual to a project.
 * Project Invitee
 * who is invited to a project by a project PI or Co-I

Pre-Conditions

 * A project exists.
 * A PI of the project exists.
 * Inviter must be either a Project PI or Project Co-I.
 * Project Invitee must be an Individual

Flow of Events

 * 1. An inviter creates a list of invitees whom it wants to invite to participate in the project with a particular project role. It (the inviter) can do as follows:
 * 1.1 Select invitees from a list of RUs (=Registered User) displayed in an AWOB 'invitation page'.
 * 1.2 Copy/paste email addresses of non-registered invitees in an appropriate area in the same AWOB 'invitation page'.


 * 2. Possibly the PI makes the list available for review by Co-Is within the project or other possibilies.
 * TBD If we want this functionality, this item must be described in more detail

The inviter
 * 3. Writes an invitation text to be sent to the invitees.
 * 4. The invitation is submitted to the system.

The system
 * 5.updates the invitation message by adding a link to an invitation page that the invitee should follow and where the invitee can accept/reject the invitation as follows:
 * 5.1 For the RUs in the invitee list a link to the page where to choose accept/reject
 * 5.2 For the rest in the list a link to the page where one is given the option to register to AWOB before to accept/reject, or to accept as an email user.
 * 5.3 The generated link should allow the system to infer which invitation the invitee reacts to. See 9. below.
 * 6. creates an invitation
 * 6.1. Creates an invitation email with the appropriate link from 5 and the invitation text for each invitee.
 * 6.2. Creates an "AWOB invitation" for each invitee, to be added to the project (see 10. below).
 * 7. Send out the prepared emails to all the invitees including RUs.
 * 8. Create an invitation notification with the invitation text and the link from 5.1 for the invited RUs, which appear on their dashboards.


 * 9. all invitees receive an invitation email.
 * 9.1 all invited RUs see an invitation notification on their personal dashboard.
 * 10. on the project page the PI and Co-Is see all new invitations, one per invitee, added to a list of Invitations.
 * An invitation contains information about the invitee, the status (SENT, ACCEPTED, REJECTED) and the proposed role.
 * Additional information can be whether RU or by email only, time when sent, text of invitation etc).
 * 11. An invitee reads the message, either on email or in invitation on dashboard. In either case it clicks the link in the invitation.
 * 12. The system displays a page with accept/reject and other options depending on whether an invitee is an RU or not. For an RU go to 13. Otherwise go to 14.


 * 13. an invitee who is a RU is sent to a page which gives following options: "Reject", "Accept"
 * 13.1. if accepts:
 * 13.1.1. the system adds the invitee as a member to the project
 * 13.1.2. the system adds the invitee to the project mailing list.
 * 13.1.3. go to 15
 * 13.2. if rejects: go to 15


 * 14. an invitee who is not a RU is sent to a page which gives following options: "Reject", "Accept and become a user", "Accept, do not become a user". The last option may not be available depending on proposed project role.
 * 14.1. if the invitee selects "Reject": go to 15
 * 14.2. if invitee select "Accept and become user": system displays the registration page.->
 * 14.2.1. update invitation to indicate changed status of invitee (now an RU)
 * 14.2.2. go to 13
 * 14.3. if invitee selects "Accept, do not become a user", goto 13.1


 * 15. system updates the invitation on the project page (see 10 above) with the decision of the invitee.
 * 16. end of the story.

Post-Conditions / Results

 * An acccepted invitee become a project member with awob project roles specified in invitation.
 * The system keeps the invitation record including each invitee's response to the invitation.

Future development

 * From Angela: might be nice if user can set their user profile in AWOB so that an email is sent to them whenever a new notification/event happens.

Discussion

 * visible/invisible registered user?
 * if one wants to invite invitees for a sub project of a project choose invitees from the project member list of the project.
 * is it necessary to allow the invitee have a limited read only access to the invited project page?
 * In that case we need an extra link in the email as well. We will then need to do some more work as well. for example give "user" special privileges related to the invitation and derived from the URL. Remove those privileges if the user rejects the invitation, so that future clicking of the same link does NOT allow user access to project anymore.
 * Angela says not necessary: invitation text should include enough information.
 * Angela: A project member other than PI or Co-I could invite an individual to the project with PI's approval.
 * Wolfgang Pietsch: it happens that for an invitee to accept the invitation but also to ask for a different role in the project.

Comments
--Natasa 10:20, 21 June 2011 (CEST) Depending on the overall description, and planned future developments, it would be good to split the Invite Collaborators in several smaller use cases which are handlable (maybe we shall think of use cases in a very simple manner as a transaction which has its start, several steps in between and has an end - successfull or unsuccessfull; it can be performed by one or several actors). An example of how this can be splitted - thus also handled could be: todo proposal
 * prepare collaborator invitation
 * send collaborator invitation
 * confirm an invitation for collaboration
 * view invitations...

Triggers

 * A project PI wishes to invite scientists to join its project.

Actors

 * PI

Pre-Conditions

 * A project exists.
 * A project PI exists. [may be consequence of previous condition?]

Flow of Events

 * 1. A PI creates a list of Registered Users whom it wants to invite to participate in the project with a particular project role. It (the PI) can do as follows:
 * 1.1 Select Registered Users from a list of Registered Users displayed in an AWOB 'invitation page'.
 * 2. The PI writes an invitation text to be sent to the Registered Users selected in step 1.1.
 * 3. The invitation is submitted.

Alternatives

 * An email is sent to the registered user (as well).
 * If in the future we support "email members" as well, people only part of the project via email, something like this is necessary. In the demonstrator we do not require this.

Post-Conditions/Results

 * Each invited Registered User sees an invitation notification on their dashboard.
 * The PI can see for each invited user on invitation(s) in the Project page's list of invitations.

Triggers
A Registered User sees an invitation notification on its dashboard.

Actors
Registered User

Pre condition
An invitation exists for a registered user to join a project.

Flow of Events
1. An invited Registered User sees an invitation to join a project on its personal dashboard. 2. The invited Registered User reads the text of the invitation, sees who has invited it, and is presented with a choice/buttons to accept/reject the invitation. This can be a separate page, or invitation expands on list view. TBD in mock-up. 3. The invited Registered User chooses one of the options and submits.

Alternatives
None

Post-Conditions/Results

 * If the invited Registered User has chosen to reject the invitation:
 * the invitation message disappears from its dashboard.
 * The PI sees that the status of the invitation for that user which indicates 'rejected'.
 * If the invited Registered User has chosen to accept the invitation:
 * The invited Registered User sees the project on its dashboard's list of Projects.
 * The PI sees that the status of the invitation for that user which indicates 'accepted'.
 * The invited Registered User shows up on the project page's list of members.


 * I would suggest here something like "The invited registered user becomes a Project Member (or Project Collaborator)" - this is a new actor, which needs to be defined. This actor also needs to be referenced in the "Create task" and other task-assignment related use cases.--Natasa 12:22, 5 July 2011 (CEST)

Discussion

 * I think that we should give on option to provide a reason not accepting an invitation or accept with a different project role from the proposed one.