Controlling Lifecycle State Transitions
Contents
Altium Vault 2.5 brings greater flexibility for deciding who can make particular state transitions for an Item Revision in a vault - the action of transitioning a revision from one state, to another different state, as defined by the lifecycle definition employed for its parent Item. It is now possible to prohibit standard (non-administrative) users from transitioning between specific lifecycle states on-the-fly, while opening up permissions to more than just Vault Administrators. You now have the ability to specify permissions at the global level - as part of Global Vault Operation Permissions - and also at the individual state transition level. The latter act in conjunction with those settings at the global level, and facilitate fine-tuning of permissions for those more important transitions (for example setting an Item Revision to be Ready for Production).
Alternatively, standard users can be made to request approval for specific state transitions. In turn, these Approval Requests are sent to, viewed, and acted upon, by those designated to be members of one or more Approval Groups.
With various levels of permission control, you can define a lifecycle state transition strategy that adheres to your organization's preferred approach.
Defining Permissions
Permissions can be defined at two levels:
- Globally - defining which users and/or roles can perform state transitions, across the entire range of defined transitions across all defined lifecycle definitions.
- Locally - specifying permissions at the individual state transition level.
Global State Transition Permissions
Global state transition permissions are defined and managed using the Edit Operation Permissions in <AltiumVaultName> dialog. Access to this dialog is made from the Data Management - Vaults page of the Preferences dialog. Select the Altium Vault whose permissions you wish to browse/modify, then click the Properties button and choose the Edit Operation Permissions command, from the associated menu.
The vault operation entry of significance here is Move revision between lifecycle states.
Access and configure, at the global level, who is permitted to pefform lifecycle state transitions.
For a newly-installed Altium Vault, the default permission settings for this operation are:
- Collaborator
- Administrators.
Define additional permissions as required (click the Add button). State transition permissions at this global level can be assigned to the following entities:
Administrators (itself a defined role)- Collaborator (this is a user who has edit rights for an Item/Revision).
- Owner (for released data, this is the person who created the initial Item)
- Specific user-defined Role
- Specific User
Local State Transition Permissions
Permissions for a particular state transition are defined in the associated State Transition Properties dialog, accessed from the applicable States and Transitions region of the lifecycle definition currently being configured in the Edit Lifecycle Definitions dialog.
control, to the right of the transition's name.
Access controls for defining permissions for the state transition being edited.
Choose the type of permission control that you wish to employ for the transition, using the State Transition Permissions field. Two options are provided:
- Controlled - this type allows you to refine exactly who can perform this transition, through specification of one or more users and/or roles. This type of local permission control is used in combination with permissions set at the global level (see How Permissions are Applied). Use the controls in the region below to define permitted entities accordingly. By default, the Public entity is added, meaning that all users at this local level are permitted to perform the transition.
With Controlled permissions, you can switch from public access, to only those users/roles specified.
- Using Approvals - this type allows any standard user to request that this state transition be performed. Requests are handled by one or more users added (individually or through roles) to defined Approval Groups. Any member of such a group can authorize, or reject, a transition request. In addition, multiple approval groups can also be defined, and ordered. This allows for multiple levels of approval.
Use the controls in the region below to define the approval group(s) accordingly. By default a single, empty approval group is added ready - New Approval Group. This can be renamed as required using the Edit Approval Group Name command from the right-click context menu.
With Using Approvals, all non-admin users must request transition, which is acted on
by a user in a defined approval group.
How Permissions are Applied
How permissions are applied, depends on the type of permission control chosen and configured at the state transition level:
- Controlled Permissions - for a user to be able to perform the state transition, the following conditions must be met:
- They must have permission at the global level to Move revision between lifecycle states (defined in the Edit Operation Permissions dialog).
- They must have permission at the local level for this particular state transition.
- They must also be a collaborator for the Item Revision whose lifecycle state is being transitioned (i.e. they must have editing rights).
- Using Approvals - all non-administrative users must use the approvals system, and send a request to perform the state transition. The approvals system doesn't require the user to have permission to make state transitions at the global level, nor does a user require to be a collaborator for the Item Revision.
Approval Requests
The following sections take a closer look at the various aspects of using the approval system to allow non-administrative users to perform specific state transitions.
Creating a Request (Requesting Approval)
Requesting approval for a state transition is performed from the Lifecycle aspect view for the required Item Revision (in the Vaults panel), or from the graphical lifecycle region in the detailed Item view. Simply right-click on the lifecycle for the revision and choose the command that requests the transition. A Confirm dialog appears, in which you can enter a note as to why you are making the request - which can aide the approval group members in their deliberations over whether or not to ultimately approve your request! Click Yes to effect creation of the request.
Request the state transition, and add a helpful note to substantiate your case.
Upon creation, members of the approval group(s) for that state transition will receive notification in their message stream, on the Stream page of the vault's browser-based interface (and summarized on the Home page of that interface).
Once the request is created, notification is sent to the members of the approval group(s), alerting them that action is required.
Viewing Approval Requests
For both the originator of a state transition request (Requester) and the user(s) defined in the approval group(s) for that state transition (Approvers), pending requests are presented through the Vaults panel using a dedicated Approval Requests folder.
An example Approval Request in the Approval Requests folder, as seen by the requester (Wally Righter) and one of the members of the defined approval
group for the particular state transition (Jason Howie).
menu), then this number will reflect the total (pending + approved).The following information is presented for each approval request:
- Description - the following fields constitute a detailed description of the request. This information is standard, irrespective of whether the request is being viewed by the requester, or an approver:
- Item Revision - the specific Item revision for which the request is being made.
- Requested By - the originator of the request (the requester). The entry here takes the user's User Name.
- Requested At - the date and time at which the request was created.
- Status - the current status of the request. This can be one of the following states:
- Awaiting - the request is currently awaiting action by one or more approvers.
- Approved - the request was approved. Note that this state will only be entered upon full, complete approval, by all approval groups defined for that transition.
- Transition - the specific state transition that is being requested for this Item revision.
- Request Note - any note that has been added by the requester, at the time the request was made.
- Actions - the controls presented here are only for pending requests (those with a status of Awaiting). Controls differ to cater for the two parties as follows:
- Requester - the user who created the request can Remind or Cancel it.
- Approvers - a user within an approval group can Approve or Reject the request.
Actioning a Request
As briefly described in the previous section, both requester and approver have actions that they can take. Let's take a closer look at each of those actions:
- Remind - this action can be taken by the requester if they have been waiting for approval, but have not yet got it. It is analogous to nudging someone, or bumping a forum post - in other words a polite way of reminding those in the approval group(s) that they need to take action (either way). Simply click the Remind control associated with the approval request. A Confirm dialog appears, in which you can enter a note that perhaps raises the level of urgency for the approval to be made! Click Yes to effect the reminder - members of the approval group(s) for that state transition will receive the reminder in their message stream, on the Stream page of the vault's browser-based interface.
Example use of the Remind action, and the subsequent reminder notification received by an approval group member.
- Approve - this action can be taken by a member of an approval group, to approve that request. Simply click the Approve control associated with the approval request. A Confirm dialog appears, in which you can enter a note if required. Click Yes to effect the approval - the requester for that state transition will receive notification in their message stream, on the Stream page of the vault's browser-based interface.
Example use of the Approve action, and the subsequent notification received by the requester.
- Reject - this action can be taken by a member of an approval group, to reject that request. Simply click the Reject control associated with the approval request. A Confirm dialog appears, in which you can enter a note if required, perhaps indicative of why the request has been rejected. Click Yes to effect the rejection - the approval request will be deleted, and the requester for that state transition will receive notification in their message stream, on the Stream page of the vault's browser-based interface.
Example use of the Reject action, and the subsequent notification received by the requester.
- Cancel - this action can be taken by the requester if they have been waiting for approval, but have since decided to cancel the request. This could happen, for example, if another issue has since been found that would negate the need to transition to the required lifecycle state. Simply click the Cancel control associated with the approval request. A Confirm dialog appears, in which you can enter a note if required. Click Yes to effect the cancellation - the approval request will be deleted.
Example use of the Cancel action, available to the requester.
Approval Information Stream
When a request is approved, notification is also available in the central region of the page, when browsing that approval request. This information consists of the following elements:
- Created At - the date and time at which the approval request was approved.
- Created By - the member of the relevant approval group who approved the request (displayed as <FirstName> <LastName>).
- Description - an entry that consists of an auto-generated messsage, along with any note included by the approver, at the time approval was given. The auto-generated part of the description depends on the type of approval:
- Final approval (from a member of the only, or last, approval group) - task approved and completed.
- Intermediate approval (from a member of an approval group that is not the last approval group) - task approved and assigned to next approval group <ApprovalGroupName>.
An example of the approval stream for a particular Item Revision, as seen by the requester. In this case, the transition had to pass through two stages of
approval (obtaining approval from a member of two different approval groups).
The following people see this information:
- The requester of the state transition.
- The user who gives final approval for the request. So where multiple approval groups are involved, only the member of the final approval group - who gives the final approval - will see this information. A member of an approval group that gives intermediate approval will not see this stream.
Taking a Request Through Multiple Approval Groups
Where multiple approval groups have been defined for a particular state transition, approval needs to be obtained from a member of each approval group. The following example illustrates the procedure involved in taking an approval request through to completion. For this example, we'll consider a state transition involving two approval groups and a total of three users:
- WRighter (Wally Righter) - the user requesting approval to transition an Item Revision from the For Prototype to the For Production state.
- AltiumJase (Jason Howie) - a member of the first approval group defined for this particular state transition.
- NGeneare (Neal Geneare) - a member of the second approval group defined for this particular state transition.
The following steps are involved:
- WRighter creates an approval request for an Item Revision (CMP-00002-A.1).
- AltiumJase gets notification of this request and approves it.
AltiumJase, a member of the first approval group, approves the request.
- NGeneare gets notification of this approval and then also approves the request. At this point, since full approval is given, the transition automatically takes place.
NGeneare, a member of the second approval group, gives final approval to the request.
- WRighter receives notification of the approval from NGeneare.
WRighter receives notification that the request was fully approved and completed.