we're using crowd with ldap and our own PKI login. When a user accesses JIRA the first time, he can login ok, but he's not known to jira until the cache expires. So he sees that he's logged in, but he has no rights...

The best would really be to implement an event-drived cached that could say "i have a new user, let's have jira reload its cache"
1 vote for me (with 2000 licenses, so a big vote"

+1 on this for me as well.
I did some changes in Crowd. Suddenly I was able to authenticate the users in Crowd->Application->Test auth., but the same user was unable to log into Jira. Reason: Jira cache missed groups. Changes to Crowd should instantly be pushed to Jira.

Approach for solving this: https://studio.atlassian.com/browse/NOT

I would also like this issue resolved.

It is very frustrating to have to wait an hour between adding a user to Crowd, and being able to tell them that they are able to log into JIRA.

Also frustrating having to wait an hour between setting up user groups in Active Directory, and being able to use them to apply permissions on JIRA projects.

I'd like to echo a strong desire for this. Confluence (3.1) does now have the ability to invalidate the cache. I'm surprised such an old issue has not yet been addressed, especially given how easy this would be to do with ehcache. Atlassian?

In Crowd 2.1, with the conjunction of Confluence 3.5 / JIRA 4.3, the caching of the userbase will occur in the Confluence/JIRA databases. JIRA and Confluence will periodically poll Crowd and update the DB cache in a background thread. The polling interval will be customisable. To give you a rough idea, a 10k userbase will take 5 mins to sync. The option to manually kick off a sync in JIRA and Confluence will also be available. This solution should resolve a lot of pain points discussed in the comments of this issue.

Note that this will still not resolve the original issue of providing event-driven or delta cache updates. There are concerns about reliability and correctness when implementing event driven updates that still need to be addressed.

There doesn't seem to be much activity on this issue despite the significant impact it has on user administration. When evaluating this issue for a future release of JIRA or Crowd please consider the performance and security implications. Changes to users' permissions or lockout state should be instantaneous from a security context. Similarly, helping users with changes to passwords, groups and privileges is extremely frustrating when they are on the phone or in person. The options to wait an hour or dump all users while the application is bounced don't incite confidence.

An invalidate cache option in JIRA really would be an excellent quick fix to this. And it really does need a quick fix.

I have this problem in Confluence

I added a new group in Crowd and want to assign permissions to that group for a space. But browsing groups doesn't show it, and although when I search for a group the group shows up as the result of a query, if I then add that group it says the group doesn't exist.

As it's been over an hour, the only thing I can think to do is shut down Confluence and restart it and hope that that fixes the problem with the cache. Not great.

Thanks for your reply and acknowledgment of the problem.
I'm glad that Atlassian is now working on using Crowd on your own sites; I hope that that also leads to fixes in long-standing "most-voted" issues in Crowd.

Hi Ronald,

Unfortunately, there currently isn't a workaround. It's something we'll need to sort out shortly though.

We don't currently use Crowd behind a lot of our sites for reasons explained in CWD-1726. We are working right now on removing those limitations though.

Thanks for your patience - I can appreciate any "wtf, there's no workaround?!" reaction.

Cheers,
Dave.

An "invalidate cache" option in JIRA and confluence would really, really help. The most common day-to-day task when managing JIRA/confluence/crowd is a user requesting access to some projects/spaces, and this involves adding him to appropriate groups in Crowd. It's really inconvenient for the user to have to wait ~30 minutes before he can access the JIRA/confluence project.

Is there any workaround for this? For example, when using svn+apache with Crowd, I can manually delete the cache file (e.g. /tmp/FileCache/crowd) to force svn+apache to obtain the Crowd groups again. Is there such a workaround for JIRA or confluence?

Another question: does Atlassian use Crowd internally, for example in jira.atlassian.com and confluence.atlassian.com? How do you guys handle this problem?

We are also in need of a solution for this.

As a kind of workaround, after changing a users properties (or creating a user) in Crowd, I had expected to be able within Jira (or any other crowdified application) to be at least able to manually invalidate the cache. I guess event-driven from Crowd (and therefore transparent for the user) would be more elegant, but an invalidate cache option should be relatively easy to implement (okay, then this is not an issue for Crowd, but for the respective crowdified application).

Hi Dan,

Not yet. It's very close to the top of the list, but we've not yet got an exact release for it.

Cheers,
Dave.

Has this made it to the roadmap yet?

Crowd 1.6 supports directory monitoring and server-side caching for some directories: CWD-1346. This will offer significant improvements if you do not want to use a high JIRA cache timeout.

Event-driven caching is not on the roadmap for the next major release as it will first involve directory monitoring (and server side caching) for all directory types.

This is a very annoying issue... I was hoping a fix for it would make it into Crowd 1.6, but nothing yet.... will this be resolved anytime soon?