Affects Version/s: 5.7.0
Fix Version/s: 6.1.0
Sprint:SR4J Sprint 76, SR4J Sprint 77
After Jira restart, some groups were removed from application access license giving groups impacting thousands of users. It was the fist time that we saw this behavior we though it may have been someone manually removing them unintentionally and added those group back and the app users were able to function normally.
I want to admit that class cast exception in question is caused by Scriptrunner plugin spring import misconfiguration and we will address it.
Also, I performed investigation and my side and found some clues on why it looks like groups are removed from application access.
At the beginning we confirmed that group application access isn't actually modified because contents of DB table "licenserolesgroup" isn't changed after issue happens.
Then I dig into the code and found the following.
Whenever that class cast exception happens it's caught and wrapped into
Then it comes to ApplicationServiceGeneric from crowd-core (decompiled code below)
DirectoryInstantiationException extends OperationFailedException, method above logs and ignores it. And then throws GroupNotFoundException.
Then CrowdServiceImpl handles this exception and transforms it to null response.
Then it comes to DefaultApplicationRoleManager.RoleLoader class, which loads group names that have application access and maps them to group object filtering out nulls.
And this result is cached and sits there until cache is flushed.
Which in turn looks like some groups from remote directory where removed from the application access.
Clearing internal Jira caches which can be done using Built-in script in Scriptrunner
Jira Software 7.13.12 and SR 5.7.x