summaryrefslogtreecommitdiff
path: root/spec/finders/joined_groups_finder_spec.rb
Commit message (Collapse)AuthorAgeFilesLines
* Use `:empty_project` where possible in finder specsrs-empty_project-findersRobert Speicher2017-01-251-1/+1
|
* Allow Member.add_user to handle access requestersRémy Coutable2016-09-281-1/+1
| | | | | | | | | | | | | | | | | | | | | Changes include: - Ensure Member.add_user is not called directly when not necessary - New GroupMember.add_users_to_group to have the same abstraction level as for Project - Refactor Member.add_user to take a source instead of an array of members - Fix Rubocop offenses - Always use Project#add_user instead of project.team.add_user - Factorize users addition as members in Member.add_users_to_source - Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects - Destroy any requester before adding them as a member - Improve the way we handle access requesters in Member.add_user Instead of removing the requester and creating a new member, we now simply accepts their access request. This way, they will receive a "access request granted" email. - Fix error that was previously silently ignored - Stop raising when access level is invalid in Member, let Rails validation do their work Signed-off-by: Rémy Coutable <remy@rymai.me>
* Fix specsissue_12658Douwe Maan2016-03-221-10/+11
|
* Address feedbackDouwe Maan2016-03-221-37/+43
|
* Code fixesFelipe Artur2016-03-171-0/+19
|
* Prevent projects to have higher visibility than groupsFelipe Artur2016-03-101-0/+51
| | | | | | Prevent Groups to have smaller visibility than projects Add default_group_visibility_level to configuration Code improvements
* remove public field from namespace and refactoringnamespace-clean_upValery Sizov2016-01-041-49/+0
|
* Refactoed GroupsFinder into two separate classesYorick Peterse2015-11-181-0/+49
In the previous setup the GroupsFinder class had two distinct tasks: 1. Finding the projects user A could see 2. Finding the projects of user A that user B could see Task two was actually handled outside of the GroupsFinder (in the UsersController) by restricting the returned list of groups to those the viewed user was a member of. Moving all this logic into a single finder proved to be far too complex and confusing, hence there are now two finders: * GroupsFinder: for finding groups a user can see * JoinedGroupsFinder: for finding groups that user A is a member of, restricted to either public groups or groups user B can also see.