PubMan Func Spec Organizational Unit Management
|
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:R3
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.
- 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[edit]
- The new organizational unit in the state “open” is created.
UC_PM_OUM_02 Edit organizational unit[edit]
The user changes data of an organizational unit.
Status/Schedule[edit]
- Status: implemented
- Schedule:R3
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) 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[edit]
- The changed organizational unit is stored.
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 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[edit]
The overall workflow of an organizational unit is:
- New organizational unit is created with status "Created"
- Organizational unit is in reality valid and it can be opened (thus becoming the status "Opened")
- 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 | |
| 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 |
| can be specified as "hasPredecessor" of other OU | No | Yes | Yes | |
| can be specified as "isSuccessor" 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 | Yes | in case a new context is created to manage closed OUs |