Talk:PubMan Func Spec Collection Administration

UC_PM_CA_01 create a context

One or more organizational units need a new context as an administrative container (for endusers, term "collection" might be used) for managing their items. The organizational unit(s) are responsible for managing the items. This responsibility is defined as "context of responsibility". Contexts have a specific workflow for releasing items and can have specific constraints (e.g. validation rules, allowed genre-types) and a certain scope defined by users (e.g. "Best of department xy", "all publications of institute xy" etc.)

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to define a new context of administering of publication items.

Actors

• Service Administrator

Pre-Conditions

• At least one publication workflow and one modification workflow are available.

Flow of Events

• 1. The user chooses to create a context.
• 2. The system displays a list of all open organizational units and subunits for which the user has the privileges as local administrator.
• 3. (Optionally) The user chooses to view the organizational unit description.
  • 3.1. The system displays the organizational unit description
• 4. The user selects one or more organizational units and confirms the choice.
• 5. The system creates a context in the state “created” with the selected organizational unit(s) and the standard workflows predefined. By default, all available genres are selected as “allowed genres”, all available submission methods are selected as “allowed submission methods”.

Comment Natasa: According the set-up of the context in the core services: we first define the content types allowed in the context and only then we define the allowed genres for the metadata profile associated as a default with the content type (i.e. in case the metadata profile in use is genre specific).

Comment Robert: if this is to be implemented we need filter methods to retrieve lists of content models from the framework. is defining content models also to be done via the admin interfaces? that would be a rather big new functionality.

We will not create new content models for PubMan R3, rather this should be separate topic. There are at present pre-defined content models. Another option is to have "internal" settings in Admin interfaces to allow for e.g. create pubman context, create faces context etc. This will enable pre-selected "default" content types (again internal to Admin interfaces configuration). There is an interface which enables to retrieve the content model information such as (http://xxxx/ctm/content-type/escidoc:persistent4) - we need to see however what information we can store in there - for start "manual" Fedora object update)--Natasa 11:17, 30 January 2008 (CET).

• 6. Continue with use case UC_PM_CA_02 edit context with the created context as selected context. The use case ends successfully.

Post-Conditions / Results

• A new context in the state “created” has been created.

Future development

• ad precondition: We should consider to restrict assignement of organisational units => only org units in status "open" can be assigned to new context. (A closed org unit would not be able to "manage" the context")--Ulla 11:43, 26 May 2008 (CEST)

UC_PM_CA_02 edit context

The user edits the context attributes name, type, description, orgunit(s), allowed genres.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to edit the context attributes.

• This use case is invoked by following use cases:
  • UC_PM_CA_01 create a context
  • UC_PM_CA_03 open context

Actors

• Service Administrator

Pre-Conditions

• One context is selected.

• The context is in state “created” or “opened”.

Flow of Events

• 1. The user chooses to edit the selected context or the context was selected by a previous use case.
• 2. The system displays the context edit view.
• 3. The user edits the context attributes name, type, description, orgunit(s), allowed genres.
• 4. (Optionally) The user adds other open organizational units for which the user has the privileges as local administrator.
• 5. The user chooses to confirm the input.
• 6. The system stores the data and displays a success message (MSG_PM_CA_02). The use case ends successfully.
• 7. (optionally) Continue with UC_PM_CA_03_open context
• 8. (optionally) Continue with UC_PM_CA_04 close context

Post-Conditions / Results

• The collection data is saved.

Future development

• Extend this use case /continue with UC_PM_CA_06 Select context workflow
• Extend this use case with "Specify default metadata and allowed genres for context" (to be specified)
• Extend this use case with UC_PM_UM_07 assign privileges to account user

We need a separate "include" or "continue" use case - as roles can be assigned to users independently of the collection configuration. Collection configuration can on its own be considered as a separate "administrative" workflow.--Natasa 11:31, 30 January 2008 (CET)

Comment Natasa: I think we should not mix the workflow definition and role assignment to a workflow definition with the granting user privileges for specific roles. --Natasa 11:31, 30 January 2008 (CET)

• After changing context attributes/default MD values, user can start separate action to modify existing items according to new settings or move them to other context.

• Modify Step 3 (optional): The user edits the context attributes or the default metadata values.

For default metadata values we need to assume: admin descriptor contains a metadata record with default values populated or admin descriptor references a "template publication item" tbd in further design--Natasa 11:31, 30 January 2008 (CET)

UC_PM_CA_03 open context

Users should be able to submit items to a context. For this reason the context must be opened.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to open a context for item submission.
• This use case is invoked by following use cases:

UC_PM_CA_02_edit context

Actors

• Service Administrator

Pre-Conditions

• One context is selected.

• The context is in the state “created” or “closed”.

Flow of Events

• 1. The user chooses to open a context.
• 2. The system prompts the user to confirm the opening of the context.
• 3. The user confirms to open the context.
• 4. The system checks for valid configuration for the context, i.e. at least one workflow is defined and validation rules are defined.
• 5. The system changes the state of the context to “opened” and displays a success message (MSG_PM_CA_03). The use case ends successfully.
• 6. (Optionally) The user wants to edit the context. Continue with UC_PM_CA_02_edit_context

Alternatives

• 3a. The user does not confirm to open the context.
  • 1. The selected context is unaffected. The use case ends without success.
• 5a. The system detects invalid configuration of selected context and displays a warning message.

Post-Conditions / Results

• The context is in the state “opened”.

UC_PM_CA_04 close a context

A context should no longer be available for the submission of new items. Therefore the context will be closed, thus no publication workflow can be further started. Anyway, items can be modified by triggering the modification workflow. Released items of a closed context can still be searched and browsed.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to close a context, because it should no longer be available for new submissions.
• This use case is invoked by following use cases:

UC_PM_CA_02 edit context

Actors

• Service Administrator

Pre-Conditions

• One context is selected.

• The context is in the state “opened”.

Flow of Events

• 1. The user chooses to close a context.
• 2. The system prompts the user to confirm the closing of the context.
• 3. The user confirms to close the context.
• 4. The systems changes the state of the context to “closed” and displays a success message (MSG_PM_CA_04). The use case ends successfully.

Alternatives

• 3a. The user does not confirm to close the context.
  • 1. The selected context is unaffected. The use case ends without success.

Post-Conditions / Results

• The context is in the state “closed”.

• Already started publication workflows for this context are unaffected.

UC_PM_CA_05 delete a context

A context in state created should be deleted.

Status/Schedule

• Status: implemented
• Schedule:R3

Triggers

• The user wants to delete a context.

Actors

• Service Administrator

Pre-Conditions

• One context is selected.
• Context is in state "created"

Flow of Events

• 1. The user chooses to delete a context.
• 2. The system deletes the context and displays a success message (MSG_PM_CA_06). The use case ends successfully.

Future development

Rework use case, so that deletion is possible also for context in state "open":

• A context is no longer required in the system and should be removed from all administrative interfaces. For this action the context is deleted. By deleting a context, all items of the context in state “pending” will be deleted as well. A context can not be deleted if it contains items in any other state than “pending”.

• Triggers: The user wants to delete a context, because it is no longer used.

• Actors: Local Administrator

• Pre-Conditions: One context is selected.

• Flow:

1. The user chooses to delete a context.

2. The system checks if the selected context contains items in any other state than “pending”.

• a. No item in any other state than “pending” exists.
• b. One or more items in any other state than “pending” exist. The system displays an error message (MSG_PM_CA_05). The use case ends without success.

3. The system displays a list of all “pending” items and prompts the user to confirm the deleting of the context and the items.

4. The user confirms to delete the context and the “pending” items.

5. The system deletes the items as well as the context and displays a success message (MSG_PM_CA_06). The use case ends successfully.

UC_PM_CA_06 select context worfklow

The user selects a publication and modification workflow for the context.

Status/Schedule

• Status: in specification
• Schedule:to be defined

Triggers

• The user wants to select a workflow for the context.

• This use case is included by following use cases:

UC_PM_CA_02 edit context

Actors

• Local Administrator

Pre-Conditions

• One context is selected.

• The context is in state “created”

• At least one publication workflow and one modification workflow are available by the workflow module.

Flow of Events

• 1. The system displays the lists of available publication and modification workflows.
• 2. The user selects the appropiate publication and modification workflow.
• 3. The user chooses to confirm the selection.
• 4. The system stores the selected workflows as defined for the context and displays a success message (MSG_PM_CA_07). The use case ends successfully.
• 6. (optionally) Continue with UC_PM_CA_07 Define validation point for workflow

Alternatives

• 4a. The user does not confirm the workflow selection for the context.
  • 1. The selected context is unaffected. The use case ends without success.

Post-Conditions / Results

• A publication and a modification workflow for the context is saved.

UC_PM_CA_07 define validation point for workflow

The user defines validation points and respective rules for the selected workflows of a context.

Status/Schedule

• Status: in specification
• Schedule:to be defined

Additional information

Collection States

In the following diagram are given all states of a collection and how they can be changed by the use-cases.

https://zim01.gwdg.de/repos/smc/tags/public/PubMan/Collection_states.gif

Figure: Graphical representation of the Collection States in PubMan

Use Case

Publication Management

Flexible Extensible Digital Object Repository Architecture

Central European Time

Central European Summer Time

Metadata