User By Workflow Step

What it is ?

The Custom Field User by Workflow Step is a field that allows to identify a set of users depending on a criteria hold by Workflow Step. It mean that you can specify for each step of a workflow, which type of users are allowed.

How it works ?

The set of users is defined by criteria stored in Meta-Attributes of the Workflow Step descriptor, and is rendered as a User Custom field.

And as User Custom field, it is possible to use this field in your Project Permission Scheme.

Which usage ?

One if the main usage is very similar as WorkflowBasedPermissionManager (see also JTriks Tutorial).

It will allow you to define Permission at Workflow Level. The difference is that this Workflows Configuration is defining the set of user and not the permission. The permission is always defined in the Permission Scheme.

How to configure it ?

Add a Custom Field per Permission

Create a new Users By Workflow Step customfield

1. Create it by selecting "Users By Workflow Step"
   
2. Name it as Assignable Users,
    
3. Once custom field is created, go to Configure, 
   
   At this stage, if no permission is selected, then the PrefixKey to use for the rest of the configuration is the customfield Id. (by exemple "customfield_10000").
   If you prefer to have a more explicit naming, you can associate the CustomField to a permission. Then continue with next configuration step; 
   (it is more clear to use a permission, since the most current use will the permission management at Workflow Level)
   
   
4. Click on edit Permission, and in the Edit Permissions page, select the permission to use as key prefix in the Workflow properties
   In the sample (Assignable User), select the relevant Permission Assignable User :
   
   
5. A property key is now associated to this customfield (here AssignableUser.rolesOrGroups) instead of customfield_10000.
   

Associate the CustomField to a its Permission

In your Project Permission scheme, grant the Assignable User permission to this Assignable User Customfield ...

Also, we try to stay coherent ...

Limit the Permission to a subset of Users

Now that you have created a dedicated User Field for Assignable Users ... you can configure how the relevant set of Users will be built.

For each concerned Workflow Step (it may be different for each of them) you have to define a relevant property for your Customfield.

1. Go to View Properties for each relevant Workflow Steps
   
   

2. an Add a new Workflow Step Property, named AssignableUser.rolesOrGroups,
   

   To assist you in this edition, you use the Workflow Meta-Attribute Editor provided here.

   

3. Build the value by concating the User criteria following the below syntaxes
   • scopeType:scopeValue
   • or scopeType(conditon):scopeValue

The supported scopeType are :

• role : For adding users depending on their Project Role
• group : For adding users depending on their Group Membership
• issue : For adding users depending on their Issue Role

The supported scopeValue will depends on scopeType :

• for role : the Project Role Name
• for group : the Group Name
• for issue : the Issue Roles (assignee, reporter, watcher or voter)

The only supported condition are (Not managed by the Attribute Editor) :

• IfAssigned : the criteria is implemented only if the issue is assigned,
• IfNotAssigned : the criteria is implemented only if the issue is not assigned

By example, the below selection will identify as Assignable User :

• any member of the group Team A,
• any member of the Project Role Developers,
• and any Issue Watcher.

Also, you can have different Custom Field User by Workflow Step implemented with variant configuration ...

In above screenshot, each properties will affect a dedicated CustomField add in the Permission Scheme, and will affect permission only for the current Workflow Step.

• The AssignIssue.rolesOrGroups properties will allows members of Project Role RD Team Leader to assign the current issue,
• Following the AssignableUser.rolesOrGroups property, only members of group RD Team will be assignable to this issue,
• Only te current assignee is allowed to work on issue due to WorkOnIssues.rolesOrGroups property,
• and finally, in respect of EditIssues.rolesOrGroups property the issue is editable by the assignee if the issue is assigned else by the reporter.