Difference between revisions of "PubMan Func Spec Organizational Unit Management"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 160: Line 160:
**Requirement to assign pre-decessor to a publication (i.e. publication is published after org unit has merged into another one)
**Requirement to assign pre-decessor to a publication (i.e. publication is published after org unit has merged into another one)
:This is already possible.--[[User:Natasab|Natasa]] 10:21, 27 March 2009 (UTC)
:This is already possible.--[[User:Natasab|Natasa]] 10:21, 27 March 2009 (UTC)
* At the moment, only the predecessor relation can be added in the admin solution, so in the organizational unit edit view and the organizational unit detail view only predecessors and no successor organizational units are shown.
* Should also be possible to specify successor relationships in the edit mask and see them in the detail view of the organizational unit (See [[PubMan_History_of_affiliations#Future_Development|future development of history of affiliations in organizational unit management]] and [[PubMan_History_of_affiliations#Future_Development_2|future development for history of affiliations linked from item view]]).


==General rules==
==General rules==

Latest revision as of 10:14, 27 August 2009

PubMan Functional Specification

View · Browse
Full Submission · Easy Submission
Import · Export
Quality Assurance · Search
Collaboration · Copyright
Collection Administration
Organizational Unit Management
User Management
Feeding local webpages
History of affiliations


edit

UC_PM_OUM_01 Create organizational unit[edit]

The user creates a new organizational unit and specifies the position in the organizational unit structure.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R5 (improvement)

Triggers[edit]

  • The user wants to create a new organizational unit.

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • None

Flow of Events[edit]

  • 1. The user chooses to create an organizational unit.
  • 2. The system displays an organizational unit details view.
  • 3. The user enters the data for the new organizational unit. The following data can be entered: Title, alternative, identifier, description, organization_type, city, country, coordinates, start_date, end_date.
  • 4. (Optionally) The user selects one or more parent organizational units in the organizational unit structure.
  • 5. (Optionally) include use case UC_PM_OUM_06 Add predecessor to organizational unit
  • 6. The user confirms the creation.
  • 7. The system checks if an organizational unit with the given name already exists under the same parent.
    • a. An organizational unit with the given name does not exist under the same parent.
    • b. Otherwise the system displays an error message (MSG_PM_OUM_01), continue with 3.
  • 8. The system creates and stores a new organizational unit in state “created” and the relations to the parent organizational units. The system displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results[edit]

  • The new organizational unit in the state “created” is created.

UC_PM_OUM_02 Open organizational unit[edit]

The user opens an organizational unit with state "created".

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R3

Triggers[edit]

  • The user wants to set an organizational unit to state "opened".

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • One organizational unit is selected
  • The selected organizational unit is in status "created"
  • if there is a parent organizational unit, the parent organizational unit is in status "opened"

Flow of Events[edit]

  • 1. The user chooses to set an organizational unit to state "opened".
  • 2. The system displays an organizational unit details view.
  • 3. (Optionally) The user changes the data for the organizational unit.
  • 4. (Optionally) The user selects one or more parent organizational units in the organizational unit structure.
  • 5. The user confirms the opening.
  • 6. The system stores the changes and set the organizational unit to state “open”. The system displays a success message (MSG_PM_OUM_03). The use case ends successfully.

Post-Conditions / Results[edit]

  • The state of the organizational unit is set to “opened”.

UC_PM_OUM_03 Edit organizational unit[edit]

The user changes data of an organizational unit.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R5(improvement)

Triggers[edit]

  • The user wants to edit the data of an organizational unit.

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • An organizational unit is selected.

Flow of Events[edit]

  • 1. The user chooses to edit the selected organizational unit.
  • 2. The system displays the details of the selected organizational unit in an edit view.
  • 3. (Optionally) The user changes the data for the organizational unit.
  • 4. (Optionally) If organizational unit is in status "created" the user changes the parent organizational unit.
  • 5. (Optionally) include use case UC_PM_OUM_06 Add predecessor to organizational unit
  • 6. The user confirms the changes.
  • 7. The system stores the changes and displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results[edit]

  • Modifications to the selected organizational unit are saved.

UC_PM_OUM_04 Close organizational unit[edit]

The user closes an organizational unit.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R3

Triggers[edit]

  • The user wants to close an organizational unit.

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • An organizational unit is selected.
  • Selected organizational unit is in status "opened"
  • If there are child organizational units, then they are all in status "closed"

Flow of Events[edit]

  • 1. The user chooses to close the selected organizational unit.
  • 2. The system displays the details of the selected organizational unit in an edit view.
  • 3. The user provides the date of closing in appropriate metadata of the organizational unit.
  • 4. (Optionally) include use case UC_PM_OUM_06 Add predecessor to organizational unit
  • 5. The user confirms the operation of closure of organizational unit.
  • 6. The system stores the changes and displays a success message (MSG_PM_OUM_04). The use case ends successfully.

Post-Conditions / Results[edit]

  • The organizational unit is closed.

UC_PM_OUM_05 Delete organizational unit[edit]

The user deletes an organizational unit.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R3

Triggers[edit]

  • The user wants to delete an organizational unit.

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • One organizational unit is selected.
  • The selected organizational unit is in status "created"
  • The selected organizational unit has no child organizational units associated.

Flow of Events[edit]

  • 1. The user chooses to delete the selected organizational unit.
  • 2. The system displays the details of the selected organizational unit in an edit view.
  • 3. The user confirms the deletion.
  • 4. The system stores the changes and displays a success message (MSG_PM_OUM_06). The use case ends successfully.

Post-Conditions / Results[edit]

  • The organizational unit is deleted.

UC_PM_OUM_06 Add predecessor to an organizational unit[edit]

The user adds a predecessor to an organizational unit.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R5

Triggers[edit]

  • The user wants to add a predecessor to an organizational unit.

Actors[edit]

  • Service Administrator

Pre-Conditions[edit]

  • An organizational unit to which predecessor should be added is selected

Flow of Events[edit]

  • 1. The user chooses to add a predecessor to the selected organizational unit.
  • 2. The system displays the details of the selected organizational unit in an edit view.
  • 3. The user selects one or more organizational units in status "opened" or "closed" to specify them as predecessors for the selected organizational unit.
  • 4. The user specifies the type of relation of the predecessor organizational unit to the organizational unit she is editing.
  • 5. The user confirms the change. The system saves the change and displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results[edit]

  • A predecessor is added to the organizational unit. All predecessors and successors (derived from other predecessor relations) of the organizational unit are shown in the organizational unit edit view and organizational unit detail view.

Future Development[edit]

  • It should be possible to change the order of the organizational units. Currently the org. units are displayed in the org. unit browsing tree displayed in the order they were entered via the admin interfaces.
  • Prepare consequences for editing organisational units (Indexes, searches, browsing)
  • Prepare use cases/scenarios for "tracking history of org units" (ie. merging, closing etc.)
    • Requirement to assign pre-decessor to a publication (i.e. publication is published after org unit has merged into another one)
This is already possible.--Natasa 10:21, 27 March 2009 (UTC)

General rules[edit]

The overall workflow of an organizational unit is:

  1. New organizational unit is created with status "Created"
  2. Organizational unit is in reality valid and it can be opened (thus becoming the status "Opened")
  3. Organizational unit does not in reality exist any longer. It is transitted to a status "Closed" in the system.


When an organizational unit is closed it can not be reopened again. Schematically the life-cycle of an organizational unit is simple:


                      CREATED -> OPENED -> CLOSED

The table below shows general rules that need to be supported by the Organizational Unit handler in order to ensure the consistency of organizational unit data. The table explains which operations are allowed for an Organizational unit, in which status and under which conditions.


Action/Status Created Opened Closed Comment
delete OU Yes
If no children exist
No No
open OU Yes
If parents exist they must be in status "Opened"
No No
Predecessor can be specified Yes Yes Yes Due to possible end-user errors, agreed to allow specification of predecessors at any time
can be specified as "Predecessor" of other OU No Yes Yes
assign parent Yes
parent must be in status "Opened" or "Created"
No No
remove parent Yes
parent must be in status "Opened" or "Created"
No No
assign children Yes
children must be in status "Created"
Yes
children must be in status "Created"
No
remove children not to be directly supported, it is to be executed via remove parent for child units, therefore rules remove parent should apply for respective children
open organizational unit Yes
If parent exists, it must be in status "Opened"
No No If children exist, no effect to children OU
close organizational unit No Yes
If no children exist or children have status "Closed"
No If children in status "Created" exist, client solution must decide what to do with them, either set-up another parent or delete them.
Can be linked to content resources No Yes Yes Content resources: items, containers etc.
Can be linked to a new context No Yes No
Can be retrieved by anonymous user No Yes Yes
Can be selector in a user group No Yes Yes