In one of the workflow steps (e.g. status Open) the workflow step property key "jira.permission.create" has been set to the value "denied".

      However, when you browse to an issue which has been set to this status, then it is still possible to create a sub-task by accessing more actions->create sub-task.

            [JRASERVER-32230] Workflow step property jira.permission.create has no effect

            ColinM added a comment -

            Same question as @Melanie Liguet above.  We tried setting jira.permission.create.denied.projectrole on both the "create" transition properties and the first status properties and it still allows all issues to be created with no restrictions. 

            ColinM added a comment - Same question as @Melanie Liguet above.  We tried setting jira.permission.create.denied.projectrole on both the "create" transition properties and the first status properties and it still allows all issues to be created with no restrictions. 

            Hi,

            It is possible to add a properties to authorize only admin to create Epic.

            I try jira.permission.create.denied or jira.permission.create.projectrole=administrators on first transition of  Epic workflow

            but it is always possible to create an epic.
            Is it a jira bug, or an error in my properties?

            Mélanie Liguet added a comment - Hi, It is possible to add a properties to authorize only admin to create Epic. I try jira.permission.create.denied or jira.permission.create.projectrole=administrators on first transition of  Epic workflow but it is always possible to create an epic. Is it a jira bug, or an error in my properties?

            Rusi Popov added a comment -

            Please note that the expected format is not <property> = denied This format actually grants access to the user named denied.
            The proper format is is:
            <property>.denied = whatever

            The complete format is:

            <permission key> = jira.permission[.subtasks].<system project permission>.<grant type>[.<suffix>]
            
            <system project permission> =   assign
                                            | assignable
                                            | attach
                                            | attachdeleteall
                                            | attachdeleteown
                                            | browse
                                            | close
                                            | comment
                                            | commentdeleteall
                                            | commentdeleteown
                                            | commenteditall
                                            | commenteditown
                                            | create
                                            | delete
                                            | edit
                                            | link
                                            | managewatcherlist
                                            | modifyreporter
                                            | move
                                            | project
                                            | resolve
                                            | scheduleissue
                                            | setsecurity
                                            | transition
                                            | viewversioncontrol
                                            | viewvotersandwatchers
                                            | viewworkflowreadonly
                                            | work
                                            | worklogdeleteall
                                            | worklogdeleteown
                                            | worklogeditall
                                            | worklogeditown
                                                   
            <grant type> =  denied
                            | groupCF
                            | assignee
                            | assigneeassignable
                            | reporter
                            | reportercreate
                            | userCF
                            | applicationRole
                            | group  
                            | lead 
                            | projectrole  
                            | user 
            
            <suffix> = any text that makes the permission key unique among all keys of permissions in the same workflow step.
            

            Rusi Popov added a comment - Please note that the expected format is not <property> = denied This format actually grants access to the user named denied . The proper format is is: <property>.denied = whatever The complete format is: <permission key> = jira.permission[.subtasks].<system project permission>.<grant type>[.<suffix>] <system project permission> = assign | assignable | attach | attachdeleteall | attachdeleteown | browse | close | comment | commentdeleteall | commentdeleteown | commenteditall | commenteditown | create | delete | edit | link | managewatcherlist | modifyreporter | move | project | resolve | scheduleissue | setsecurity | transition | viewversioncontrol | viewvotersandwatchers | viewworkflowreadonly | work | worklogdeleteall | worklogdeleteown | worklogeditall | worklogeditown <grant type> = denied | groupCF | assignee | assigneeassignable | reporter | reportercreate | userCF | applicationRole | group | lead | projectrole | user <suffix> = any text that makes the permission key unique among all keys of permissions in the same workflow step.

            vogoltsov, I'm so sorry - there is another Vitaly with a very similar name to yours inside Atlassian and I thought he was commenting on this issue!

            We're still trying to figure out exactly what's going on here, so I recommend you contact https://support.atlassian.com who should be able to help you out with your particular case.

            Regards,
            Eric

            Eric Dalgliesh added a comment - vogoltsov , I'm so sorry - there is another Vitaly with a very similar name to yours inside Atlassian and I thought he was commenting on this issue! We're still trying to figure out exactly what's going on here, so I recommend you contact https://support.atlassian.com who should be able to help you out with your particular case. Regards, Eric

            edalgliesh, no, I haven't set jira.permission.create for subtask workflow. If I do so, will I be able to create sub-tasks on later stages in parent issue workflow?
            A bit of background: we have Story issue type with the following workflow (simplified): In Review -> To Do -> QA -> Done. Story is to be broken into several Tecnhical Task and Research using sub-tasks. The latter both have the same workflow: To Do -> Code Review -> Done. A Story is completed when all of its sub-tasks have been done. So I put jira.permission.create=denied on Story's In Review step - and everything is as I described in my previous comments.

            Vitaly Ogoltsov added a comment - edalgliesh , no, I haven't set jira.permission.create for subtask workflow. If I do so, will I be able to create sub-tasks on later stages in parent issue workflow? A bit of background: we have Story issue type with the following workflow (simplified): In Review -> To Do -> QA -> Done. Story is to be broken into several Tecnhical Task and Research using sub-tasks. The latter both have the same workflow: To Do -> Code Review -> Done. A Story is completed when all of its sub-tasks have been done. So I put jira.permission.create=denied on Story 's In Review step - and everything is as I described in my previous comments.

            Eric Dalgliesh added a comment - - edited

            vogoltsov, does the workflow for the subtask itself have the permission turned off?

            Eric Dalgliesh added a comment - - edited vogoltsov , does the workflow for the subtask itself have the permission turned off?

            By the way in Greenhopper plan/work modes I am also able to create sub-tasks for an issue which current workflow step has jira.permission.create=denied if that matters.

            Vitaly Ogoltsov added a comment - By the way in Greenhopper plan/work modes I am also able to create sub-tasks for an issue which current workflow step has jira.permission.create=denied if that matters.

            I also confirm this. We have 'In Review' as a first step in workflow with jira.permission.create set to denied. I still am able to create sub-tasks via More Actions -> Create Sub-Task. Though when viewing a parent issue in sub-tasks list I don't see a plus sign, which is normally visible when jira.permission.create=granted.

            Vitaly Ogoltsov added a comment - I also confirm this. We have 'In Review' as a first step in workflow with jira.permission.create set to denied . I still am able to create sub-tasks via More Actions -> Create Sub-Task. Though when viewing a parent issue in sub-tasks list I don't see a plus sign, which is normally visible when jira.permission.create=granted .

              Unassigned Unassigned
              rtandon@atlassian.com Ruchi Tandon
              Affected customers:
              19 This affects my team
              Watchers:
              16 Start watching this issue

                Created:
                Updated: