Defect #25289

Adding a principal to 2 projects with member inheritance leads to an error

Added by Felix Schäfer about 5 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:


Target version:3.4.0
Resolution:Fixed Affected version:


When batch adding a user or a group to a project through the projects tab of the user/group page, adding the a user or group to 2 projects where one project inherits its members from the other might lead to an error (depending on the order of the projects, the parent project must come before the child project for this to happen, which it should as in the batch add view projects are arranged in trees). If more than those 2 projects are involved in the batch addition to a project, the user or group won't be added to all projects that come after the child project as the processing stops on the error.

This happens in source:/trunk/app/models/member.rb@16379#L175: First all Member s are created, then they are saved in the principal.members << members line. Saving the Member object for a parent project with a child project inheriting its members will create a Member object for the child project too, which then leads to an error when the Member error created for that child project is saved and recognised as a duplicate.

25289.patch Magnifier (692 Bytes) Felix Schäfer, 2017-03-08 20:56

Associated revisions

Revision 16381
Added by Jean-Philippe Lang about 5 years ago

Adding a principal to 2 projects with member inheritance leads to an error (#25289).

Patch by Felix Schäfer.

Revision 16382
Added by Jean-Philippe Lang about 5 years ago

Adds a test for #25289.


#1 Updated by Felix Schäfer about 5 years ago

The attached patch solves this problem. No test though as this method is currently untested, we can provide tests too if required.

The patch saves each new Member directly in the loop instead of saving all in one go at the end of the loop. Please note that this does not significantly affect performance as principal.members << members still saves each Member one at a time. This allows the loop to recognise if a previous iteration already created a Member we are trying to instantiate and avoids the clash described above.

Please note that roles are added to the Member instead of destructively replacing already present roles. This would also allow changing the "Add project" modal of groups/users from being able to only add the group/user to projects it is not already a member of to adding the user/group with the selected role to any project in addition to already existing role/project combinations for that user/group.

#2 Updated by Jean-Philippe Lang about 5 years ago

  • Category set to Administration
  • Status changed from New to Closed
  • Assignee set to Jean-Philippe Lang
  • Target version set to 3.4.0
  • Resolution set to Fixed

Patch committed, thanks for catching this issue. I've added a test for this.

#3 Updated by Felix Schäfer about 5 years ago

Looks great, thanks!

Also available in: Atom PDF