State security rules

States have two types of security: privilege and attribute. Both are used to establish the requirements for modifying specific attributes. You decide which types of security to set on each state.

Privilege security

Privilege security defines a list of attributes that are modifiable when the change request (CR) is in the selected state and the user has the required privilege.

For example, for the in_review state, the verifier privilege has the synopsis and description that is listed as modifiable attributes. Therefore, any user with the verifier privilege can modify those attributes when the CR is in the in_review state.

Attribute security

Attribute security on a state defines a list of attributes that are modifiable when the CR is in the selected state and the value of a specific attribute matches the user ID. For example, resolver="john" or enterer="sam".

For attribute security to work, the selected attribute must contain a user ID as its value. That is, the attribute has the type CCM_USER.

You can define attribute security on an attribute, or on a combination of an attribute and a user's privilege.

If a privilege is specified, then both of these conditions must be met to modify the attribute list:
  • The attribute value must be equal to the user ID.
  • The user must have the specified privilege.

For example, a rule states that when the CR is in the assigned state, only the user who submitted the CR (the value for the submitter attribute on the CR must be equal to the logged in user ID) and who has the developer privilege can modify the defect_type attribute. The defect_type attribute is listed in the modifiable attributes. Therefore, if user tom submitted a CR and he has the developer privilege, then he can modify the defect_type attribute when the CR is in the assigned state.

How privilege and attribute security rules work together

If either the attribute security or the privilege security rules are satisfied, then the corresponding set of attributes is modifiable. The privilege security and attribute security rules are ORed together to obtain the set of modifiable attributes.

Consider this example. You set the following rules for CRs in the assigned state:

Rule 1 - privilege level security

Rule 1 - privilege level security

Only users with the assigner privilege can modify the release and resolver_name attributes on a CR that is in the assigned state.

Rule 2 - attribute level security

Rule 2 - attribute level security

Only the user who is the resolver of the CR (the resolver_name attribute value on the CR must be equal to the logged in user ID) and who has the developer privilege can edit the estimate, associated_task, and comments attributes while the CR is in the assigned state.

Scenario:

You give user sam the tester privilege, user joe the assigner privilege, and user john the developer privilege.

sam submits a CR and joe assigns it to john. So, sam is the submitter and john is the resolver of the CR. The value for resolver_name attribute on the CR is john. The CR is in the assigned state and the rules are ORed together.
  • sam does not satisfy any of the rules, so he cannot modify any attributes on the CR.
  • joe satisfies Rule 1 because he has the assigner privilege. He can modify the release and resolver_name attributes when the CR is in the assigned state.
  • john satisfies Rule 2. The value for the resolver_name attribute on the CR is john, so john is the resolver of this CR. Also, john has the developer privilege, so he can modify the estimate, associated_task, and comments attributes when the CR is in the assigned state.

Feedback