Anyone encountering this issue in JIRA, note that it has now been confirmed as a bug in CROWD and being tracked here: https://jira.atlassian.com/browse/CWD-4733

This is definitely the expected behaviour. If you have 2 admins maintaining groups of the same name in differrent systems, then you have a managerial mess. Other solutions lead to a wide variety of security concerns; it may be possible to support amalgamated groups but it was decided not to try and support that for a number of reasons.

The workaround, or really correct behaviour is to have a group of a different name. If there is an accidental clash, then work just needs to be done.

Maybe the message could be improved, but it seems self explanatory to me.

So what is the solution for mixed membership groups where LDAP users are controlled by LDAP and local users are added locally?

I agree with Os - this is working as it should.

For the reasons above, IMO this should be resolved as Won't fix works as designed. edalgliesh, do you agree?

edalgliesh Investigated this issue this morning and had a discussion with jwinters about it.

It seems like we need some design input here to come up with a solution to this scenario, because it seems like the current behaviour is expected. We can not just drop the existing local group because someone added an LDAP group with the same name, it seems like giving preference to the local group at least preserves existing data which we need to continue doing. As far as our understanding goes this is working as designed.

From my understanding the suggested workaround is too drastic, in order to get the LDAP group into JIRA instead of the local one, it should just be a matter of removing the local group first and then performing a synch, tcampbell mlassau can you confirm?

To summarise, the current design of the feature is given a read-only;local-groups directory configuration:

If a remote group is added and it matches the name of pre-existing local group --> We will ignore the remote group and keep using the existing local group.

At this time we were in test phase, so I think all tickets were related to users which also were stored in the internal user directory. In confluence, hopefully I remember correctly, you cannot delete a user directory if there is content which is related to users which would be dropped, but who knows if jira behaves like confluence. So I would not drop it, without a reliable answer.

If I use this workaround and recreate the LDAP connection, will there be any adverse effects for ticket ownership, group membership, etc. or will I have to reassign tickets?

After deleting the ldap user directory and added an equal new one with exactly the same configuration, the "jira-users" are now added during synchronizing - might be a workaround, also for others.

This ISSUE is a show stopper for us, because the "jira -users" group is also not added to the user if we activate the "Default Group Memberships" with "jira-users". We need this group, otherwise no login is possible for anybody.