How i can add a user to a specified group by Jira Automation (Jira, Crowd)?

[Mari Pervushina]

Hello

We have Jira Data Center 9.14.1, user management via Crowd.

I have a problem with performing automation. Automation is started when the status of the problem changes, two variables {{username}} and {{groupname}} are set in it, and the web request api POST

/rest/api/2/group/user is executed?groupname={{groupname.urlEncode}}

in the body of

{

"name": "{{username}}"

}

The expected result of automation: the user {{username}} is added to the group {{groupname}} and sees problems that are accessible only to the group {{groupname}}. The actual result: automation is being performed, and in the User Management System, I see that the user has been added to the group, but the user does not get access to the issues. And if after that, I manually update any user's membership in any group through the UI (it doesn't matter if I add or delete it), then the changes made by automation are applied and the user sees the problems that he needed access to. I have already tried to solve it by running scripts, the same result. Who knows how to solve the problem? I think the problem is with some kind of event or cache.

[Marc -Devoteam-]

Hi @Mari Pervushina 

Maybe a silly question os the group a crowd group or a local group?

As the API you are making is towards the local group.

If your users and groups are managed in Crowd and these are used in permission schemes, etc..

The user should be added to the group in Crowd.

Crowd has its own API endpoint: https://developer.atlassian.com/server/crowd/rest/v700/api-group-users/#api-rest-usermanagement-1-user-group-direct-post 

[Arkadiusz Wroblewski]

Hello @Mari Pervushina 

you’re basically right: this smells like cache / directory refresh.

Your REST call does add the user to the group (you can see it in User Management), but Jira doesn’t immediately re-evaluate permissions because group membership is still cached (and on Data Center it can be cached per node). That’s why any random manual change in the UI “fixes it”, the UI path triggers extra cache invalidation / refresh.

What to do:

1) Confirm it’s a node/cache problem (DC)

If you have multiple Jira nodes, the user might hit a node that still has old membership cached.
Quick test: stick the user to one node (or test via each node) and see if behaviour differs.

2) Force the directory/group refresh after automation

Run a directory sync for the directory that comes from Crowd (Jira Admin → User directories → sync).
That often makes the new membership “visible” immediately.

3) Check Crowd authorization caching

Crowd can cache group membership for connected applications. If the TTL is long, Jira won’t see the change right away. Lower the TTL / flush Crowd caches as a test.

4) Flush Jira caches (or restart one node to prove it)

Jira has caches for users/groups/permissions. Flushing those (on all nodes) or restarting a node is a quick way to prove the root cause.

Your automation is doing the change, but Jira/Crowd caching delays the permission effect. Fix is to refresh/flush (directory sync + cache), and on DC make sure it’s applied across all nodes.

[Mari Pervushina]

@Arkadiusz Wroblewski Thank you for you attention!

1) Confirm it’s a node/cache problem (DC)

I haven't multiple Jira nodes. My Jira don't clusterising

2) Force the directory/group refresh after automation

When i run a directory sync for the user directory this not make the new membership “visible”, i tried it.

3) Check Crowd authorization caching

Are  TTL and Synchronisation Interval (minutes) same? Synchronisation Interval = 60 minutes now.

4) Flush Jira caches 

How i can flush cahes by the Scrupt runner?

 And i know something intresting now: user can see issue from direct link (but don't see this issue on Project -> Kanban Board, and don't see on Project -> Issues).

[Arkadiusz Wroblewski]

@Mari Pervushina 

the detail “user can open the issue via direct link, but can’t see it in Boards / Issue Navigator / Project → Issues” is the key clue. That usually means permissions are already OK, but search/board results are stale.

Direct issue view can be loaded directly, while Boards + Issue Navigator depend on the Lucene index. If the index hasn’t caught up with the new group membership, the issue won’t appear in search/boards until index/caches refresh.

TTL vs Synchronisation Interval (Crowd)

No  these are different:

Synchronisation interval (e.g. 60 minutes) = how often Crowd syncs directory data (users/groups).

Authorization caching / TTL (if enabled) = how long membership/permission decisions can be cached before they’re re-evaluated.

So “Sync = 60” does not guarantee immediate visibility changes.

What to do next (Order are important)

Re-index
Administration → System → Indexing → run Background re-index.
If it still doesn’t show, run a Full re-index (more disruptive).

Flush Jira caches (no ScriptRunner)
If you have it: Administration → System → Cache management → flush caches related to users/groups/permissions.
If you don’t have that UI (or it’s locked down), on a single-node system the practical equivalent is a Jira restart.

One extra gotcha:

Even with correct permissions, the issue can still be excluded by the board filter JQL (or quick filters). But since it’s also missing from Project → Issues, index/caching is the first thing to fix.

[Mari Pervushina]

Unfortunatly, the solution with re-index and stuff doesn't suit me. since you need to add a user to the group periodically and at the same time update the security scheme. It is currently unclear how to trigger the security schema update event, and there may be a problem with it. If you manually change the security scheme or the security level of the project (add or remove a group), this also leads to an update.

[Arkadiusz Wroblewski]

@Mari Pervushina 

If this must run periodically, then re-index/restart indeed isn’t an operational solution.

There is also no supported “security scheme refresh event” you can trigger via Automation/REST to make Jira immediately re-evaluate visibility after a group membership change.

What you’re seeing is caching behavior:

POST /rest/api/2/group/user updates the membership (you see it in user management).

Jira doesn’t instantly refresh all permission/search layers.

Changing the Issue Security Scheme / security level in the UI forces an internal refresh, so it “wakes up”. That’s a side effect of the admin action, not an event you can reliably call from automation.

If you need this to work repeatedly, the sustainable options are:

Tune/disable authorization caching on the Crowd side for the Jira application (sync interval is not the same thing).

Or change the access model so you don’t rely on frequent directory group changes for issue visibility (e.g., project roles / user-based security where possible).

Toggling the security scheme just to force refresh will work sometimes, but it’s risky and noisy long-term.