Workflow Properties

I just tried adding a comment permission restriction to a workflow state in 3.6.5 jira.permission.comment.user  and it works fine. I then tried doing a builk operation to transfer a couple of issues to another workflow state and didn't get any errors. Does anybody know what areas of bulk operations actually break as per the warning above?

Has anyone else experienced bulk change errors when implementing these permissions?

Where is the list of possible "values" for each of the properties and a description of what they do?

E.g. Where does it show that you can set jira.issue.editable = false

I've seen the constant values API documentation but it only shows the permission name but not what possible values it can hold. There is also no description of what each of the properties does?

Your documentation for jira.permission.* give me the following "wrong" information:

The format is 'jira.permission.[subtasks.]

is a short name specified in Permissions

• Unknown macro: {type}
  is a type (group, user, assignee, reporter, lead, userCF) of permission granted, or denied to deny the permission.
• subtasks., if specified, indicates that the permission applies to the subtasks of issues in this step.
  

With "wrong" i mean that

is really a short name, but they can not be found in Permissions. For example i looked for the ability to grant the permission to create attachments.

The correct way is to use jira.permission.attach.user - but following your instruction i tried jira.permission.CREATE_ATTACHMENT.user which won't work. So i had to guess the verb attach  

here it says:

The format is 'jira.permission.[subtasks.]{permission}.{type}[.suffix]', where:

But it doesn't say what .suffix is for.

Update: Ahha, I see in the example the suffix is used, e.g. jira.permission.edit.group.2, so I guess it's simply used when you want to specify a value for the same property more than once and the underlying OSWorkflow system requires unique property keys.

Hi,

The WorkflowBasedPermissionManager documentation says:

group, user, assignee, reporter, lead, userCF

I took a look at the JIRA 3.11 source code and it is also possible to use projectrole where the value is a JIRA project role ID number. E.g.

I've started using the step property functionality, but encountered a problem. I'm using sub-tasks, and in one particular step I would like to restrict the create permission, so that only the assignee could create a sub-task in this particular step. I've got the edit, assign and more or less all other permissions to work, but not the create permission. Probably the problem is that I'm using the wrong short name for create.. I've tried jira.permission.create.assignee for example, but I'm sick of guessing Anyone, helt please! ;S

I can't find a good list of all possible workflow step and transition properties - I see some references to others not listed above and I know having a complete list will help me come up with better workflows.  Can someone please post a definitive list??

See JRA-6381 for examples of restricting workflow steps using the jira.permission.* property.

I have used jira.permission.assignable.projectrole many times with the role-id as its value.

Watch out for white spaces!

Leading or trailing white spaces need to be trimmed in workflow transition properties entry boxes. Currently extra spaces cause enties to be unrecognized.

"jira.field.resolution.exclude " does not equal "jira.field.resolution.exclude"

I would restrict possibility of Create issue down to a particular project role.

How can I do this using transition properties on initial Create workflow transition? thanks