Rules for Changing Statuses
A set of rules is triggered when a user issues a command to change the status of an administered item. Registration status changes of administered items depend on the rules set in the Registration Status Change Rules object. This object defines the rules for transitioning from one status to another and who can change the status.
Status changes are performed in Commands in Data Manager. If the 4th position (certification) of the status mask is set to 1, certification rules are applied before the status is changed. If required, the following certification rules are executed:
Check 1: Is the Registration/ Administration status transition valid?In the example above, a Submitter can change the status from Blank to INCOMPLETE. The user group is determined based on the organizations assigned to an administered item. The following section provides examples of the authorization functionality in status transitions.
The status transition check looks at the Registration Status Change rules or Administrative Status Change rules to make sure the From/To transition is allowed.
The Administrative Status Change Checks follow the same process as above, but for Administrative Status.
Check 2: Is the user authorized to change status? The following scenario illustrates this check. A “Test” user belongs to ACCOUNTING DIVISION and ACCOUNTING FUNCTIONAL DIVISION. This setup is configured in the
Contacts tab, in
User Security. See
Registry Security.
The administered item is assigned the following Steward/Submitter/Registration Authority:
| Organization Assigned | User X Belongs to Group |
Submitter Organization | ACCOUNTING DIVISION | Submitter |
Steward Organization | ACCOUNTING FUNCTIONAL DIVISION | Steward |
Registration Authority | | |
The user's group is determined based on the user's assigned organization and the organization that is assigned to Submitter Organization/Steward Organization and Registration Authority. This group is then checked against Check #1 to make sure the user is authorized to make the status transition.
Check 3: Are all the mandatory attributes provided? This is a part of the Certification Process and is only conducted depending on the value of the Status Mask for the Registration Status being changed. See
Status Mask and Rules for information about status masks.
This verification compares the Status Change Required Columns entity to determine if all the required attributes are populated.
Check 4: Administered Item Specific Checks This is a part of the Certification Process and is only conducted depending on the value of the Status Mask for the Registration Status being changed.
Status Mask and Rules for information about status masks.
Data element validations: If you select the property
Derived Data Element? for the Data Element, the Derived DE Components table must have atleast one record for this data element.
If there are no Derived DE Components associated with the Data Element, you must not mark the property
Derived Data Element? for the Data Element.
Value domain specific validations:
If the value domain is of type:
Enumerated. At least one valid permissible value must be defined.
Non-enumerated. No permissible values should be defined for non-enumerated value domains. The non-enumerated Value Domain Description must be provided.
Conceptual domain specific validations: If Conceptual Domain is of Enumerated type, then at least one Value Meaning should be defined.
Check 5: Is Registration Status STANDARDIZED The following verifications are performed when the Registration status changes to STANDARDIZED:
All the parents of the administered items must be STANDARDIZED before the administered item can be STANDARDIZED.
Object Class, Property, Representation Class, and Derivation Rules cannot have a dependency.
Data Element Concept: Conceptual Domain, Object Class and Property must be specified and in STANDARDIZED state.
Value Domain: Conceptual Domain must be specified and in STANDARDIZED state.
Data Element: Data Element Concept and Value Domain must be specified and in STANDARDIZED state.
