UC AWOB PM 10 Change Task Visibility

MPDL,GAVO

= UC_AWOB_PM_10 Change Task Visibility- v0.5 =


 * would suggest to carefully reconsider the "visibility" issue. We can create "private" and "restricted" area (see similar comment on Change task status" use case).
 * --Jkim 12:30, 13 February 2012 (CET)In our opinion visibility is well enough understood to be able to be supported in 0.5. It is not related to larger workflows. Please specify the reason.
 * it is not about the concept, it is about more investigation what we need to do on the implementation side. --Natasa 16:26, 13 February 2012 (CET)

Status/Schedule

 * Status: Specification
 * Schedule:v0.5

Trigger

 * Some tasks require a change in the visibility of the task to be performed. Examples are open/close task for comments or review.

Actor

 * Task Manager

Precondition

 * Project status must not be 'closed'.
 * Task status is neither 'complete' nor 'cancelled'.
 * task status is "in progress", "pending" ? --Natasa 15:26, 13 February 2012 (CET)

Trigger

 * The task is or has arrived at a stage where the task lead and other members would like to receive comments on the task's results from project members who are not task members.

Steps

 * An actor selects an action option 'open for comments from a menu.
 * The system updates the task metadata as follows. (The followings could be post conditions.)
 * set the task visibility to 'project'. Task Visibility = 'project' is defined in the discussion:

Alternatives

 * An actor sets the task visibility value to 'project' and submits the change.

Post conditions

 * The system gives all the Project Member
 * 'write' privilege to the public task wall.
 * 'read' privilege to the task content including its wiki, uploaded resources but not its private wall.
 * The system notifies all the project members of the change on their dashboard.
 * The system updates the task list in synch with the change in the task.
 * The system posts the change in 'What's new' of the project.

Discussion

 * When creating a task its default status = 'pending' and default visibility = 'project'. Even for 'pending' status it is possible to close for comments.
 * Task Visibility = 'project' is defined as follows:
 * all the Project Member have 'write' privilege to the public task wall.
 * all the Project Member have 'read' privilege to the task content including its wiki, uploaded input, output resources but not its private wall.


 * --Natasa 14:27, 10 February 2012 (CET)We could introduce this workflow via "Public comments" category and "one or more threads" - which in this case would be opened for all project members (and natively, for task members). They could link to Wiki pages, Resources, reply to each others post as long as the category is opened. The responsible actor (Task Manager, Task Lead?) would be able to lock/unlock each thread for comments (or complete category) as needed. On-the same line with the visibility proposal and the "public wall". A category "Internal discussions" will only be visible only to task members.
 * --Jkim 11:38, 13 February 2012 (CET) That sounds fine for the first implementation. There should be predefined categories for public/private walls with proper 'default visibility' setting, so that the task manager or lead don't need to define them from scratch. The availability of each wall should be inferred from (and set in) the task metadata by using Task visibility, it should not be necessary to define this individually at category or thread level. This page [TBD add link, in development] shows the matching of Task visibility and status to privileges for all task components.

Actor

 * Task Manager

Precondition

 * Project status must not be 'closed'.
 * Task status is neither 'complete' nor 'cancelled'.

Trigger

 * No need to gather more comments from the project members.

Steps

 * An actor selects an action option 'close task for comment' from a menu or something equivalent.
 * The system updates the task metadata as follows.
 * set the task visibility to 'task'. Task Visibility = 'task' is defined in the discussion:

Alternatives

 * An actor sets the task visibility value to 'task' and submits the change.

Post conditions

 * The system
 * remove 'write' privilege to the public task wall from all the Project Member including the members of the task.
 * all the Project Member have 'read' only privilege to the public task wall.
 * remove 'read' privilege to the task content including its wiki, uploaded resources except input resources from all the Project Member.
 * The system notifies all the project members of the change on their dashboard.
 * The system updates the task list in synch with the change in the task.
 * The system posts the change in 'What's new' of the project.

Discussion

 * Task Visibility = 'task' is defined as follows:
 * all the Project Member including members of the task have 'read' only privilege to the public task wall.
 * all the Project Member have neither read nor write privileges to the task content including its wiki, uploaded resources except input resources.
 * all the Project Member has only 'read' privileges to 'task metadata(attributes)' and input resources. P