UC AWOB CM 08 Manage Working Group Projects

MPDL,GAVO

link to R0.8

=CM_08 Manage Working Group Projects=

Actors

 * 1) Working Group (WG) Lead
 * 2) WG Manager
 * 3) WG Project Manager

Preconditions

 * 1) The system status of WG is open.
 * 2) The system status of consortium is open.

Steps

 * 1) Actor selects a working group of which actor is member of
 * 2) From page showing WG project list actor chooses an option to create a project.
 * 3) Actor is sent to standard "create project page". UC_AWOB_PM_01SPEC_Create_Project
 * 4) Short Name(mandatory) - indicate required field, explain rule if exists (eg., white space allowed? max length? something like info button)
 * 5) Title (optional)
 * 6) Goal (optional)
 * 7) Project status(mandatory):
 * 8)  Provide information to whether the project’s status to the project members, WG or consortium members if relevant.
 * 9)  differs from AWOB project status ‘open’ and ‘closed’
 * 10)  A piece of information. No workflow is defined
 * 11) Enumeration
 * 12) Pending(default)
 * 13) In progress
 * 14) Completed:
 * 15) Even if a project status is either completed, or cancelled, the project is still editable not like in task.
 * 16) Cancelled
 * 17) Actor submits
 * 18) The system may provide two options: [Up to discussion ]
 * 19)  Submit and go to ‘Overview’ of the workspace of the new project.
 * 20) Submit and go back to WG project list.
 * 21) the system validates the request.
 * 22) Check whether all the mandatory fields are provided by the actor.
 * 23) The validation rules are similar to those implemented for standalone project.
 * 24) Uniqueness: awob-wide
 * 25) If valid
 * 26) the system creates a new WG project (see Post conditions.).
 * 27) If not valid
 * 28) the system shows the error messages: what's missing, or what's wrong with given values.

Post conditions
For valid request:
 * 1) The system creates a project(similar to Create project use case).
 * 2) It appears on working group project list immediately.
 * 3) Default WG project status = ‘proposed’
 * 4) For setting WG project status see CM_08_4_Change_WG_Project_Status
 * 5) It appears on the project list in the actor’s personal workspace.
 * 6) It appears on what's new of the affected WG with category like ‘WG projects’.
 * 7) It is notified to the members of the affected WG by
 * 8) Email
 * 9) AWOB notification
 * 10) Depending on actor’s choice  the system  brings up
 * 11) ‘overview’ of new project if actor chose to go to ‘overview’ of the new project, or
 * 12) WG project list if actor chose to WG project list.

Actors
Any consortium members can view any WG project list.
 * 1) Consortium Lead
 * 2) Consortium Manager
 * 3) Consortium Project Manager
 * 4) Consortium Member

Steps

 * 1) Actors browse WG project list.
 * 2) See table of consortium/wg/project roles vs privileges: https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/consortium_member_privilege_r08.xlsx

Post conditions

 * 1) For any consortium member following options are available: [to decide to implement it in 0.8 or 0.9]
 * 2) Request to join membership (AWOB_Meeting_2013-02-04 implementation not in 0.8)
 * 3) For some WG projects and WG members an option to announce to consortium is available
 * 4) See CM_08_5_Announce_Project_To_Consortium_From_WG

CM_08_3_Edit_Project_Metadata_in_WG
Until R0.7 both project/consortium lead and manager were able to edit project/consortium/WG metadata. However, the use case is changed so that only Project lead can change project metadata and the way to keep log of its metadata changes.

Actors

 * 1) Project Lead

Preconditions

 * 1) The selected project’s AWOB system status is ‘open’.
 * 2) The selected WG’s AWOB system status is ‘open’.
 * 3) The selected consortium’s AWOB system status is ‘open’.

Steps

 * 1) Actor can change the following metadata:
 * 2) Title
 * 3) Goal
 * 4) Status
 * 5) Submit.

Post conditions
The system does the followings:
 * 1) Save the change.
 * 2) Display the change in what’s new of the selected project. (in a category like project info)
 * 3) Modify the layout of project overview.
 * 4) Synchronize WG project list according to the change.
 * 5) if the project is already listed in consortium projects
 * 6) Synchronize Consortium project list according to the change.
 * 7) The following is up to discussion
 * 8) Display the change in what’s new of the WG where the project belongs to. (in a category like WG projects) [TBD ]
 * 9) if the project is already listed in consortium projects
 * 10) Display the change in what’s new of the consortium where the project belongs to. (in a category like WG projects)[TBD ]

CM_08_4_Change_WG_Project_Status
‘WG Project Status’ (mandatory)
 * 1) Enumeration(wording)
 * 2) Proposed(default): actor propose it to working group
 * 3) Accepted/Approved
 * 4) Rejected/Disapprove
 * 5) Withdrawn

Actors
In the WG where a selected project is defined
 * 1) WG lead 
 * 2) WG manager
 * 3) Project Lead who has at least WG project manager privilege.
 * 4) The additional condition to a project lead is to provide preventive measures from users abusing the system. Eg., if a project lead sets WG project status of his/her project ‘accepted’ or  announce it to consortium without WG manager’s consent, a WG lead or manager can demote him/her to WG member so that in the future he/she cannot create a project in the WG.
 * ok, so we ignore this in implementatioh, in general is only WG Lead and WG Manager --Natasa 14:01, 11 February 2013 (CET)

--Jkim 14:24, 11 February 2013 (CET) To understand your comment: Does this mean that project lead cannot edit his/her wg project status in R0.8?
 * my comment was written too fast - it was meant in general only WG lead, WG Manager and Project lead (as usual) - as if the demotion is done, then it can only be valid for future projects (the demoted WG project manager to Wg member is still project lead for his/her existing projects)

Preconditions

 * 1) The selected project’s AWOB system status is ‘open’.
 * 2) The selected WG’s AWOB system status is ‘open’.
 * 3) The selected consortium’s AWOB system status is ‘open’.

Steps

 * 1) Actor changes ‘WG project status’ of a project from the WG project list.

Post conditions

 * 1) The system saves the change.
 * 2) The change shows up in what’s new
 * 3) of the WG where the project belongs to. (in a category like WG projects)
 * 4) The following is up to discussion
 * 5) of the selected project. (in a category like project info or  overview)
 * 6) Synchronize WG project list according to the change.
 * 7) If the status is ‘completed/cancelled’
 * 8) Is the project still editable? Yes. The awob system status of the project doesn’t change.
 * 9) Notify the change to
 * 10) Whom
 * 11) All WG members of the affected WG or the followings
 * 12) WG lead of the affected WG
 * 13) WG manager of the affected WG
 * 14) Project Lead of the affected project (regardless whether the project lead is at least a WG project manager)
 * 15) By
 * 16)  AWOB message
 * 17)  email

CM_08_5_Announce_Project_To_Consortium
Use case for announcing a project approved in a WG to consortium-wide.

Actors

 * 1) WG lead
 * 2) WG manager
 * 3) Project Lead who has at least WG project manager privilege.

Preconditions

 * 1) The consortium’s AWOB system status is open.
 * 2) The following is up to discussion
 * 3) It is reasonable to assume that a project can be announced to consortium only if its WG project status is ‘approved/accepted’.  But I’m not sure whether this condition is considered as a workflow.

Steps

 * 1) From working group project list actor chooses an option to announce a selected project to consortium project list.
 * 2) Optionally, the actor sets the value of consortium project status of the affected project from consortium project list.
 * 3) By default consortium project status = ‘proposed’

Post conditions

 * 1) The project shows up on ‘Consortium project list’.
 * 2) The change shows up in what’s new of the affected consortium. (in a category like consortium projects)
 * 3) The change shows up in what’s new of the affected WG. (in a category like WG projects).
 * 4) Notify all consortium members by
 * 5) Awob notification
 * 6) email
 * 7) The following is up to discussion
 * 8) The change appears in what’s new of the affected project itself.

CM_08_6_Change_Consortium_Project_Status_of_WG_Created_Project
This use case is for changing consortium project status of a project created in WG-level. The use case for changing

this status of a project created in consortium-level is in CM_03_4_Change_Consortium_Project_Status.

Actors
The real use case is
 * 1) Consortium Manager
 * 2) WG lead of the WG to which the project belongs.
 * 3) WG manager to which the project belongs.
 * 4) Project Lead who has at least WG project manager privilege.

But due to LR implementation issue, added extra condition on each WG roles to link Consortium roles. Didn't impose that Project lead (see *)must be at least WG Project manager of the WG which manages the project.
 * 1) Consortium Lead
 * 2) WG lead of the WG to which the project belongs AND either
 * 3) Consortium Manager OR
 * 4) Consortium Project Manager
 * 5) WG manager to which the project belongs AND either
 * 6) Consortium Manager OR
 * 7) Consortium Project Manager
 * 8) Project Lead  of the project AND either
 * 9) Consortium Manager OR
 * 10) Consortium Project Manager

Preconditions

 * 1) The consortium’s AWOB system status is open.
 * 2) The selected project is announced in consortium project list.
 * 3) This is not the same as the project is created in a consortium level.

Steps

 * 1) From consortium project list actor chooses an option to change consortium project status of a selected project.
 * 2) Actor updates it.

Post conditions

 * 1) The system saves the change.
 * 2) Synchronize the consortium project list accordingly.
 * 3) Synchronize the affected WG project list according to the change if a WG project list displays it in the interface.
 * 4) The change shows up in what’s new of the affected consortium. (in a category like consortium projects)
 * 5) Notify
 * 6) Whom
 * 7) all consortium members  or
 * 8) selected members
 * 9) Consortium Lead
 * 10) Consortium Manager
 * 11) WG lead of the WG to which the project belongs.
 * 12) 'WG manager to which the project belongs.
 * 13) Project Lead (regardless whether the project lead is at least a WG project manager)
 * 14) by
 * 15) Awob notification
 * 16) email
 * 17) The followings are up to a discussion
 * 18) The change shows up in what’s new of the affected WG. (in a category like WG projects).
 * 19) The change shows up in what’s new of the affected project. (in a category like project overview).

CM_08_7_Change_Project_Overview
This use case is the same as changing ‘overview’ a stand-alone project which is already implemented.

Actors

 * 1) Project Lead
 * 2) Project manager