Managing Department Structures

This chapter contains the following subjects describing functionality to manage department structures:

For information on service operations provided by Stardust for predefined permissions concerning departments, please refer to the section Setting Application Permissions of the chapter Securing the Stardust Engine in the Operation Guide.

Department Interface

Stardust provides an interface Department to describe departments via the following methods:

The getScopedParticipant method throws an InvalidArgumentException if the participant argument is not compatible with the organization to which it belongs. Compatible means that it is either the same organization or a direct member of the organization.

Managing Departments

The AdministrationService provides the following methods for managing departments:

Please also refer to the section AdministrationService of the chapter Stardust Services for information on this service and the according Javadoc of the AdministrationService for detailed information on its methods and their parameter usage.

Create Departments

The method createDepartment creates a new department with the given id, in the scope of the parent department and assigned to the specified organization. The method has the following restrictions:

Exceptions are thrown in the following cases:

Retrieve Departments

The method getDepartment retrieves the department with the given OID. An ObjectNotFoundException is thrown in case no department with the given OID exists.

Modify Departments

The method modifyDepartment changes the name and the description of a department. An ObjectNotFoundException is thrown in case no department having the specified OID exists. If the name is null or contains an empty string, an InvalidArgumentException is thrown.

Remove Departments

The method removeDepartmentremoves the department having the specified OID, all his children and all user grants associated with the department. An InvalidArgumentException is thrown if there are non-terminated or terminated work items that are associated with either the given department or with any of its direct children. An ObjectNotFoundException is thrown in case no department with the specified OID exists. So the instance any activity gets associated with the department, it cannot be deleted. Because the audit trail maintains either ActivityInstance entries or ActivityInstanceHistory entries that references the department which has any activity associated with it. An ActivityInstanceHistory objects can be removed only by archiving the audit trail.

Delete All Existing Departments

To delete all existing departments, you can use the cleanupRuntimeAndModels method or the method cleanupRuntime(boolean keepUsers). In the cleanupRuntime(boolean keepUsers) set the parameter keepUsers, which is a flag to specify if the users should be deleted or not, to false.

Manipulating Grants for Scoped Participants

With the interface User, you can manage grants for scoped participants, as described in detail in section Adding and Removing Grants of chapter Declarative Security Usage in Stardust Services API.

Adding grants for scoped participants in their default department(s)

For every distinct scope in an organizational hierarchy, there is a dedicated null department. A scoped participant in its default department is granted to a user by granting his null department given by granting the organization for the superdepartment.

Declarative Security effecting Scoped Participants

On Data, Model and Partition Level

If a grant is given to a scoped participant (explicitly or implicitly) on data, model or participant level, then all users assigned to this participant do have execution permission. The department is not taken into account.

On Activity Level

On Activity Level each activity instance stores the department information. Thus, it depends on the concrete activity instance, if a user has execution permission. In that case, the grant including the department has to match the grant permission and the department of the activity instance.

On Process Level

Department information is not stored in the process instance. Instead, the relevant process data defining the department is evaluated on demand.

For example, a process definition permission is granted to a role Role 1. This role is a scoped role with scope data Data 1 defining the department. If the value of Data 1 is executed for a specific process instance, the department required to get the execution permission is evaluated.

Reflecting the Department Association

The method getDepartment of the interface Grant, provides the option to retrieve the department with which this grant is associated. In case the grant has no department association, the method returns null. Please also refer to the Javadoc of the interface Grant for detailed information on this interface and its methods.

The method findAllDepartments(DepartmentInfo parent, OrganizationInfo organization) of the QueryService interface, retrieves a list containing all the departments satisfying the search criteria. The search is performed as follows:

The resulting list can be empty if no departments are matching the search criteria. An ObjectNotFoundException is thrown if one of the following cases applies:

Distinguishing Between Scoped and Unscoped Participants

To distinguish between scoped and unscoped organizations and roles, use the method isDepartmentScoped() of the interface ModelParticipantInfo. It returns whether the role or organization is modeled to support the creation of its own departments.

The method definesDepartmentScope() returns true, if this particular organization defines a department scope.

Please refer to the Javadoc of the interface org.eclipse.stardust.engine.api.model.ModelParticipantInfo for detailed information on these methods.