Will this also be fixed in 9.4.x LTS?

Hi folks!

The issue's waiting for release to 9.9.0 (JSM 5.9.0) already, but while working with an affected customer on this we came up with a Linux command of curl-jq that may be helpful on reacting to these external system import Project Role changes.

It makes use of a non-public REST API endpoint, so don't rely on it for Production automation — only ad-hoc executions (and still it may change/break in minor releases as it's non-public):

$ curl -u jiraAdminAccount -X GET "https://jira-base-url/rest/auditing/1.0/events?limit=20&categories=projects&actions=Project%20roles%20changed" -s | jq '.entities[] | select (.method == "Browser") | "WHEN: ", .timestamp, "\n", "WHO: ", .author.name, "\n", "PROJECT: ", (.affectedObjects[] | select(.type == "PROJECT") | .name, " (", .id, ")"), "\n", "PROJECT ROLE: ", (.affectedObjects[] | select(.type == "PROJECT_ROLE") | .name, " (", .id, ")"), "\n", "FROM: ", .changedValues[].from, "\n", "TO: ", .changedValues[].to, "\n\n"' -j

Replace "jiraAdminAccount" and "jira-base-url" accordingly.

It scans for all Audit Log entries of "Project roles changed" and method "Task", indicating it was performed through a (import)Task, not "Browser" as the regular Project Roles changes would be. It also limits the output to 20 records (for sakes).

You may also replace the -u jiraAdminUsername for an Authorization Header with a PAT (Personal Access Tokens): -H "Authorization: Bearer REPLACExYOURxTOKENxHERE". It's good practice to revoke the PAT right after.

Sample output:

WHEN: 2023-05-11T13:05:38.436Z
WHO: admin
PROJECT: Audit Test (10101)
PROJECT ROLE: Developers (10100)
FROM: admin
TO: admin, JIRAUSER10100

WHEN: 2023-05-11T13:02:03.378Z
WHO: admin
PROJECT: Audit Test (10101)
PROJECT ROLE: Developers (10100)
FROM: null
TO: admin

On this example, the admin was first added to the Developers role, then JIRAUSER10100.
 

 
Hopefully this makes it easier to spot Project roles changes that were likely unexpected (through the import Task, not Project Admin UI) and help Admins assess and remove the users if needed.
 
Cheers

Confirmed it's happening in Jira 9.4.3

+1

#3 for us. I think we stopped using the Developers project role a long time ago.

Workaround #1

The unprivileged importer available at Issues > Import issues from CSV does not cause the Developers project role to be recreated.

Oh, btw, the unprivileged importer has less functionality and may be disabled.

or...

Workaround #2

Do not import issues with assignee field populated

or...

Workaround #3

Don't ever use the Developers role for any permission or workflow functionality, that way users in this role are meaningless and you can systematically schedule a process to remove this role for all users.

or...

Workaround #4

Do not import issues via CSV

or ...

Workaround #5

Pray that Atlassian will stop ignoring their users and fix their product.  (rarely works) 

I think this affects Cloud too.

Given that Server version is kill in less than a year, can anyone confirm if this affects the DataCenter version?

issue which is almost 4 years old, not fixed, easy to reproduce and " is waiting to be reviewed by a member of the Atlassian product team. Typically, only recently created issues are in this status.".

*** SHAME ***