UC AWOB PM 09 Change Task Status

MPDL,GAVO

= UC_AWOB_PM_09 Change Task Status- v0.5 = '' Reminder for JK: May or may not to change the use case so that those files on task 'work' folder may/may not be available to all the project members other than the task members once a task is closed/cancelled. If decided not to make 'work' folder available to the general project members update the table in http://colab.mpdl.mpg.de/mediawiki/AWOB_Task_006#Task_Visibility.''

Status/Schedule

 * Status: Specification
 * Schedule:v0.5

Trigger

 * Need to change task status.

Actor

 * Task Manager
 * whgat about task lead additionally?--Natasa 13:51, 10 February 2012 (CET)
 * Jkim 14:18, 10 February 2012 (CET)Please follow the link.
 * maybe we have an understanding problem in here - what shall be in Actors of use cases - imho these are roles in the system, but seems in the use case descriptions it is something else--Natasa 14:31, 13 February 2012 (CET)

Precondition

 * Project status must not be 'closed'.
 * One task is selected
 * The status of the selected Task is 'pending'.
 * task status is only "pending", right? --Natasa 17:36, 9 February 2012 (CET)
 * --Jkim 10:44, 10 February 2012 (CET) agreed, updated the precondition.

Trigger

 * The actors want to change the task status to 'in progress'.

Steps

 * An actor selects an action 'start task' from a menu or something equivalent.
 * The system updates the task metadata as follows. (These could be post conditions.)
 * set the task status to 'in progress'.
 * set the task visibility to 'task'.

Alternatives

 * An actor sets the task status value to 'in progress' and submits the change.

Post conditions

 * The task content including wiki, private wall, uploaded resources other than input resources are readable, and editable by task members only.
 * Project Members can only browse the task's metadata(See Task attributes in the conceptual model) and read/view the public task wall and task input resources.
 * The system notifies all the task members of the change on their dashboard.
 * The system notifies all the task members of the dependent tasks if any of the change on their dashboard.
 * Are dependent tasks in scope of 0.5?--Natasa 16:17, 16 January 2012 (CET)


 * --Jkim 16:22, 7 February 2012 (CET) No.
 * The system updates the project's task list in synch with the change in the task.
 * The system posts the change in 'What's new' of the project.


 * --Natasa 18:22, 9 February 2012 (CET)Would suggest rephrasing the postconditions (as these are switching from pending/started) and taking another view on this (referring here also to create task use case)


 * when a task is created we can create a "restricted" and a "private" area for the task
 * "restricted" area are all project members (including task members, task lead and task manager)
 * "private" area is only visible by the task lead, task manager and task members
 * in this case the visibility status of the "restricted" area does not have to be switched to "private" (in our opinion it makes no sense to hide information which was already visible to the users)
 * Jkim 14:19, 10 February 2012 (CET) Changed the post conditions on Create Task use case as suggested.
 * Jkim 12:17, 13 February 2012 (CET) I thought that 'restrict' and 'private' areas meant 'public', and 'private' walls. But reading your comments again from UC_AWOB_PM_09 Change Task Status- v0.5, I misunderstood. What are 'restrict', and 'private' areas? I have posted the same comments on 'create task' use case.
 * "restricted" area is what you name "public" wall (as it is not indeed public). Suggestion here is to not use use the term "public" as it is not indeed a public wall, but a wall restricted to the project members only. --Natasa 15:20, 13 February 2012 (CET)


 * Jkim 17:21, 2 May 2012 (CEST) Reminder: In current implementation, start date should be set manually by user not by the system. The idea is that 'start date' stores the actual date the task starts, not the date the status of the task is changed from pending to in progress in awob. This is in contrary with closing date. All the date handling should be redone. It might be useful to track two types of dates (real dates vs system dates).

Actor

 * Task Lead

Precondition

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

Trigger

 * An actor want to change the task status to 'complete'.

Steps

 * An actor selects the action 'close task' from a menu or something equivalent.
 * The system updates the task metadata as follows. (These could be post conditions.)
 * set the task status to 'complete'.
 * set 'closing date' to a current date.
 * enter an entry in the task status change log.
 * set the task visibility to 'project'.

Alternatives

 * An actor changes the value of the task "status" field to 'complete' submits the change.

Post conditions

 * All the task content is no longer editable by any one including task members, task managers, task lead, & becomes read only.
 * The Project Members can browse all the task content except 'private task wall'.
 * The system notifies all the task members and the task creator of the change on their dashboard.
 * The system notifies all the task members of the dependent tasks if any of the change on their dashboard.
 * The system updates the project's task list in synch with the change in the task.
 * The system posts the change in 'What's new' of the project.

Actor

 * Task Lead

Precondition

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

Trigger

 * An actor wants to change the task status to 'cancelled'.

Steps

 * An actor selects the action 'cancel task' from a menu or something equivalent.
 * The system updates the task metadata as follows. (These could be post conditions.)
 * set the task status to 'cancelled'.
 * set 'closing date' to a current date.
 * enter an entry in the task status change log.
 * set the task visibility to 'project'.

Alternatives

 * An actor changes the value of the task "status" to 'cancelled' submits the change.

Post conditions

 * All the task content is no longer editable, & becomes read only.
 * The Project Members can browse all the task content except 'private task wall'.
 * The system notifies all the task members and the task creator of the change on their dashboard.
 * The system notifies all the task members of the dependent tasks if any of the change on their dashboard.
 * The system updates the project's task list in synch with the change in the task.
 * The system posts the change in 'What's new' of the project.
 * The system does not delete any content from 'cancelled' task.