PubMan Func Spec Organizational Unit Management

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

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

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to create a new organizational unit.

Actors

• Service Administrator

Pre-Conditions

• None

Flow of Events

• 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.
• 4. (Optionally) The user selects one or more parent organizational units in the organizational unit structure.
• 5. The user confirms the creation.
• 6. 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.
• 7. The system creates and stores a new organizational unit in state “open” 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

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

UC_PM_OUM_02 Edit organizational unit

The user changes data of an organizational unit.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

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

Actors

• Service Administrator

Pre-Conditions

• An organizational unit is selected.

Flow of Events

• 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) The user changes the parent organizational units.
• 5. The user confirms the changes.
• 6. 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.

7. The system stores the changes and displays a success message (MSG_PM_OUM_02). The use case ends successfully.

Post-Conditions / Results

• The changed organizational unit is stored.

Future Development

• 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 closed organisational units to a publication
  • Requirement to assign pre-decessor to a publication (i.e. publication is published after org unit has merged into another one)

General rules

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 overall workflow of an organizational unit is:

1. New organizational unit is created with status "Created"
2. Organizational unit is valid organizational unit 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

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
hasPredecessor can be specified	Yes	Yes	Yes	Due to possible end-user errors, agreed to allow specification of predecessors at any time
hasSuccessor can be specified	Yes	Yes	Yes	Due to possible end-user errors, agreed to allow specification of predecessors at any time
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
Can be linked to content resources	No	Yes	Yes	Content resources: items, containers etc.
Can be linked to a new context	No	Yes	Yes	in case a new context is created to manage closed OUs

   * close organizational unit
         o if children in status "opened" the operation should not be allowed (or previously should be assigned to a new parent by the client solution)
         o if children in status "created" exist the operation should not be allowed (client solution should decide what it needs to do with these children)
         o if children is status "closed" only exist the operation should be allowed

Publication Management

Use Case

Organizational Unit