jira.permission.create.clone.denied in workflow property breaks Get create issue meta API

Hi everyone,

This is an update to inform you that this ticket is invalid.

The key used here, jira.permission.create.clone.denied, is invalid, and JIRA is just throwing a valid error:

Unknown type 'clone' in meta attribute 'jira.permission.create.clone.denied'. Valid permission types are defined in permission-types.xml

Using the right key, jira.permission.createclone.denied, the problem shouldn't happen.

JRASERVER-67652 is about a similar, valid bug when using the right key, and there is a Workaround. Please watch it for more details.

Summary

When a user adds jira.permission.create.clone.denied in a workflow property, running the Get create issue meta with expand=projects.issuetypes.fields fail

http://localhost:8080/jira/rest/api/latest/issue/createmeta?expand=projects.issuetypes.fields

I understand that this is an incorrect usage of the property (JRA-34816), but the reason this Bug is raised is because workflow properties seems unrelated to metadata for creating issues. Adding workflow properties should not break an unrelated part of JIRA

Steps to Reproduce

1. Add jira.permission.create.clone.denied in a workflow property of a Status
2. Verify that users won't be able to clone issues in that particular status
3. Run Get create issue meta

Expected Results

The metadata should be returned normally

Actual Results

1. The below exception is thrown as a response

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <status>
       <status-code>500</status-code>
       <message>Unknown type 'clone' in meta attribute 'jira.permission.create.clone.denied'. Valid permission types are defined in permission-types.xml</message>
       <stack-trace>java.lang.RuntimeException: Unknown type 'clone' in meta attribute 'jira.permission.create.clone.denied'. Valid permission types are defined in permission-types.xml
   	at com.atlassian.jira.permission.WorkflowPermissionFactory.createWorkflowPermission(WorkflowPermissionFactory.java:86)
   	at com.atlassian.jira.permission.WorkflowPermissionFactory.getWorkflowPermissions(WorkflowPermissionFactory.java:42)
   	at com.atlassian.jira.security.WorkflowBasedPermissionManager.workflowPermissionCheck(WorkflowBasedPermissionManager.java:196)
   	at com.atlassian.jira.security.WorkflowBasedPermissionManager.workflowPermissionCheck(WorkflowBasedPermissionManager.java:172)
   	at com.atlassian.jira.security.WorkflowBasedPermissionManager.workflowPermissionCheck(WorkflowBasedPermissionManager.java:137)
   	at com.atlassian.jira.security.WorkflowBasedPermissionManager.hasPermission(WorkflowBasedPermissionManager.java:83)
   	at com.atlassian.jira.security.DefaultPermissionManager.hasPermission(DefaultPermissionManager.java:103)
   	at com.atlassian.jira.security.WorkflowBasedPermissionManager.hasPermission(WorkflowBasedPermissionManager.java:76)
   	at com.atlassian.jira.security.ApplicationRequiredPermissionManager.lambda$hasPermission$235(ApplicationRequiredPermissionManager.java:71)
   	at com.atlassian.jira.security.ApplicationRequiredPermissionManager$$Lambda$365/587147594.getAsBoolean(Unknown Source)
   	at com.atlassian.jira.security.ApplicationRequiredPermissionManager.checkUserHasApplicationOrFalse(ApplicationRequiredPermissionManager.java:177)
   	at com.atlassian.jira.security.ApplicationRequiredPermissionManager.hasPermission(ApplicationRequiredPermissionManager.java:71)
   	at sun.reflect.GeneratedMethodAccessor392.invoke(Unknown Source)

2. Results are returned when expand=projects.issuetypes.fields is removed, but this doesn't return the required data

Workaround

No known workaround