Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Use `:empty_project` where possible in finder specsrs-empty_project-finders | Robert Speicher | 2017-01-25 | 1 | -1/+1 |
| | |||||
* | Allow Member.add_user to handle access requesters | Rémy Coutable | 2016-09-28 | 1 | -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_12658 | Douwe Maan | 2016-03-22 | 1 | -10/+11 |
| | |||||
* | Address feedback | Douwe Maan | 2016-03-22 | 1 | -37/+43 |
| | |||||
* | Code fixes | Felipe Artur | 2016-03-17 | 1 | -0/+19 |
| | |||||
* | Prevent projects to have higher visibility than groups | Felipe Artur | 2016-03-10 | 1 | -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_up | Valery Sizov | 2016-01-04 | 1 | -49/+0 |
| | |||||
* | Refactoed GroupsFinder into two separate classes | Yorick Peterse | 2015-11-18 | 1 | -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. |