As of JIRA 6.4, group memberships are still not aggregated across directories. ben4 are you able to provide more context around the decision for JIRA?

Hi dunterwurzacher, any news about this one? Will this be applied on JIRA as well, or the decision to prevent it is still valid? Could we have some justification about it if true?

dunterwurzacher This is great. Thanks for the Just hoping to see this soon on JIRA as well.

Hi angel6, dberrueta and jwalton, no need to raise more requests, this functionality is already in Confluence as of 5.7, and Stash as of 3.4. Currently aggregation is enabled by default, and can only be disabled by hitting a REST endpoint, as there's currently no UI to manage the aggregation semantics. EMBCWD-961 is actually just the request to add a UI checkbox to change the semantics.

The docs for how it works in Confluence, and how to disable it, are here.
For Stash, the docs are here.

This functionality is not currently available in JIRA, but this has been a conscious choice. I'm talking with the team to get an official answer about whether it will be brought into JIRA at some point, or if there's a way to enable it, and I'll get back to you as soon as I can. Thanks for your patience.

angel6 yes; that's right, separate JIRA and Confluence issues. There is shared code. However, the PMs on those teams are better placed to judge customer requirements and priority here.

jwalton, so you suggest creating respective issues for JIRA, Confluence etc. right? I had the impression that embedded crowd was integrated into other Atlassian products on a regular base to bring new features and improvements to them as well.

angel6 yes, that's an internal project. If you're interested in having this in other products then that is best tracked through issues filed against those products so they can consider it in their specific case.

dberrueta Sorry I don't have the right permissions to see EMBCWD-961. If it says that this particular feature is also available in embedded Crowd, then this is it. Is so, is it already fixed or pending?

angel6, is EMBCWD-961 the feature you are looking for?

Hi,

Is this feature going to be part also of embedded Crowd so that we can use it on other products as well (JIRA, etc)?

Cheers,
Aggelos

Hi,

had to vote this issue - this is a stopper for us to use Crowd at all. I can only imagine what people using this are experiencing...

Sincerely,

Iiro Niinikoski

Hi Brendon ,

We are interested in this solution. We are exploring the crowd sources and we are not able to build the project as we have the issues in pom s . COuld you please help us?

Thanks
Srividhya

To All,

Just to give you some insight and understanding as to why and how this
decision was made. During the work to embed large portions of Crowd's
user management into JIRA and Confluence, the Crowd codebase
went under a very high level of scrutiny by all the product teams that
would begin to leverage the Crowd code base. The decision (where we
currently are) was made and unfortunately it was a compromise
between the Confluence, JIRA, Crowd development leads and also Project
Management. This decision was not easy and we do understand the impact
that this decision has made to some of our customers, and
we are sorry if this has adversely affected you.

I can understand why some customers are suggesting that we just 'add a
flag' to restore the previous functionality, but unfortunately this
change due to its nature can result in a lot of unforeseen edge cases
that need to be tested and validated and this, as always, can require
significant time and effort. Currently I would have simply said (for
Brendan's sake here) you will need to look at re-implementing the
ApplicationService membership lookups, i.e. no longer looking just at
the first directory, specifically the
"ApplicationServiceGeneric.searchNestedGroupRelationships" method. The
only issue now is, the current release of Crowd allows for incremental
syncronisation of user, group and membership data from directories (a
new performance enhancement for Crowd) and this code would also need
to be tested and potentially modified to support across directory
amalgamation of membership information.

At this stage of Crowd's development lifecycle we are not in a position
to work on fixing this issue, and unfortunately would suggest
contacting an Atlassian partner (like Brendan) to look at helping
re-implementing this feature.

Also just to be clear, even though the statement was probably made in
jest, Atlassian will not be removing SSO as a feature from Crowd at
any time.

Kind regards,

Justin
- Atlassian Platform Team Lead

We must escalade this lake of feature in Crowd versions above 2.1 (at least in v.2.3.4)

Our Company requires Atlassian to build a patch a.s.a.p. to add again these removed feature.
It is just one of the two critical features we used in our architecture, the second being the SSO.

When Atlassian will remove SSO too ?

Atlassian cannot say one side to us to upgrade Jira and Confluence (because your Jira 4.2.4 was hugely slow too much) to new version which do not support Crowd.v.2.0.7 and in another side remove the major feature of Crowd which did the aggregation of the memberships between the directories !

Definitely a major issue for us as well.

Atlassian required our customer to migrate from Crowd 2.0.7 to Crowd 2.1 or above so as to upgrade Jira and Confluence. And now the only option would be to downgrade everything to Crowd 2.0.7 to get the aggregated groups back

Absolutely agree with Brendan,

Anyone with CROWD license, please create a new issue and ask for resolution of this ticket (this way hopefully atlassian will assign someone to this). I think they have to look at the new issues but not the old ones.

We hold JIRA and Confluence unlim. licenses and this little issue among some more prevents us from using CROWD for our SSO ;(

Can Atlassian give hints as to how to code this back in? With some pointers I will take a swing at creating a patch.

Honestly without this it is pretty much impossible to have SSO across multiple applications where you don't want all the apps to have access to all your users. This one little thing is kind of a stopper between allowing Crowd to offer the services admins need in an organization of moderate complexity.

Thanks!!

Link to the support ticket with my requirement:
https://support.atlassian.com/browse/CWDSUP-5228

I deploy crowd as sso for several services, this is a blocker for future, as I need seperation of concerns on that level (inlcude to directory servers independently).

Any news on when this will be fixed?

More or less same story for us. We also need this functionnality back.

https://support.atlassian.com/browse/CWDSUP-4172

This is a major stopper for us.
Users Authenticated via Companies AD but their jira-users and confluence-users memberships in internal CROWD directories.
Upgraded to ver. 2.1.0 from 2.0.7 and vuala no group membership aggregation ;(
Users can't use JIRA and Confluence anymore.

I'm rolling back to ver. 2.0.7 for now.
Please bring back this feature at least as an option.