Adding a group containing a large number of users as subgroup is very slow
When adding a group with a large number of users as a subgroup of another group, the request takes a long time to be completed. For example:
Child_Group contains 6000+ users. Adding this as a sub group to Parent_Group via REST API take more than 30 seconds.
Steps to Reproduce
Using the REST API (Postman Collection is attached):
Create two groups child_group and parent_group
Create 6000+ users and add them to child_group
Add child_group to parent_group
It take a significant amount of time return from step 3. For a child_group with a smaller numbers of users the time taken is shorter. It seems that as the number of users grow, so does the time taken to add child_group as a subgroup of parent_group.
The performance of adding a child group should not be impacted by the number of users inside that child group.
Great work Eva! Thanks a lot for your involvement, the result are very impressive from 30s to 4s you exceeded my client’s expectation!
We spend the afternoon with Eva thinking on a solution to replace group by roles. She found a track of solution that is interesting follow, I’ll discuss it later today with the developer at the client site. We will not remove the use of group entirely, there are still some case where it will be required. And in a big repo having to work with a group of 4000 users is not uncommon. Linked to this MNT, there is another MNT talking about the same issue. So this issue still need to be fixed and our client is looking forward this fix before going in production.
Whatever my current action are, my client need to go in prod in March and he will not have the time to do the role modification before that. As presented yesterday to Eva the business is very complicated, it is not going to be cheap neither fast to fix the current client’s solution. I emphasis on the urgency of the situation and the risk they face when they reach production, the change is going to be integrated in the next Project Increment and we have added analyses task to this sprint and the next one to find a good solution to go from a group based solution to a role based solution.
So please proceed with the fix of this issue on the timeline that has been proposed, I already told my client it was going to be fixed.
I think that is on the right track.
The use cases that are connected to the code (as far as I remember, it was quite a long time ago) are the following:
Admins are always authorised. So any new member that is added to admin hierarchy of groups needs to be authorised.
It should not be possible to add a deauthorised user to the admin hierarchy
It is not possible to remove these features, so adding a check for parents to be in admin group looks like a valid solution. My only concern is that it may not be possible to improve performance due to limitations of the user/group graph architecture.