Jira Permission schemes should not allow you to attempt to configure nonsensical permission states

Problem Definition

Several past cases have been reported of Jira admins trying to use a user custom field value or a group custom field value to set a project permissions such as 'Create Issue' or 'Browse Project'. The intention of the admin here is to only allow the possible users in that custom field options to have that specific permission. This does not work though for these specific permissions, because in order to evaluate these permissions the issue has to already be created in Jira. These custom fields would have to have a value set within them on an issue already created. The potential values of that field are not valid as a means to impose a permission grant on those specific permission options. In the case of creating issues, it can't possibly work because the issue is not created yet.

Suggested Solution

Change the way permission schemes work and edit the screens there in to prevent admins trying to set permissions that can never possibly be valid within Jira. This could be done by specifically removing 'user custom field value' and 'group custom field value' from the objects that cannot possibly honor their hypothetical values yet. We know this includes at least create issue and browse project, but there could be others in play here as well.

Why this is important

Lots of admins in Jira have attempted to configure this because Jira allows it, But can't possibly honor it. It causes high levels of frustration and angry users to have Jira let you do something that it has no expectation of being able to do.
https://jira.atlassian.com/browse/JRASERVER-26659
https://jira.atlassian.com/browse/JRASERVER-30783
https://jira.atlassian.com/browse/JRACLOUD-66317
https://jira.atlassian.com/browse/JRASERVER-21613
https://jira.atlassian.com/browse/JRACLOUD-30783
https://community.atlassian.com/t5/Jira-Software-questions/JIRA-Bug-with-Group-Custom-Field-Permission-Settings/qaq-p/734856

Workaround

none