Aakriti Gupta authored 5 years ago and mksionek committed 5 years ago

in a project members' list. Add tests for possible scenarios

Re-factor and remove N + 1 queries

Remove author from changelog

Don't use memoisation when not needed

Include users part of parents of project's group

Re-factor tests

Create and add users according to roles

Re-use group created earlier

Add incomplete test for ancestoral groups

Rename method to clarify category of groups

Skip pending test, remove comments not needed

Remove extra line

Include ancestors from invited groups as well

Add specs for participants service

Add more specs

Add more specs

use  instead of

Use public group owner instead of project maintainer to test owner acess

Remove tests that have now been moved into participants_service_spec

Use :context instead of :all

Create nested group instead of creating an ancestor separately

Add comment explaining doubt on the failing spec

Imrpove test setup

Optimize sql queries

Refactor specs file

Add rubocop disablement

Add special case for project owners

Add small refactor

Add explanation to the docs

Fix wording

Refactor group check

Add small changes in specs

Add cr remarks

Add cr remarks

Add specs

Add small refactor

Add code review remarks

Refactor for better database usage

Fix failing spec

Remove rubocop offences

Add cr remarks

When updating group and project members, new system hooks
`user_update_for_group` and `user_update_for_team` will be executed.

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/12252

We had a number of team members struggle to find invited members of a
group. Searching for the e-mail address did not work because search only
works with members with user accounts.

This commit changes two things:

1. Breaks out the invited members into a separate table.
2. Adds search capability for the invited members.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/61948

When using the members/all api the same user was returned multiple times
when he was a member of the project/group and also of one of the
ancestor groups.
Now the member is returned only once giving priority to the membership
on the project and maintaining the same behaviour of the members UI.

Suppose you have this configuration:

1. Subgroup `hello/world`
2. Subgroup `hello/mergers`.
3. Project `hello/world/my-project` has invited group `hello/world` to
access protected branches.
4. The rule allows the group to merge but no one can push.
5. User `newuser` has Owner access to the parent group `hello`.

Previously, there was no way for the user `newuser` to be added to the
`hello/mergers` group since the validation only allowed a user to be
added at a higher access level.

Since membership in a subgroup confers certain access rights, such as
being able to merge or push code to protected branches, we have to
loosen the validation and allow someone to be added at an equal level
granted by the parent group.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11323

Renamed EmailValidator to DeviseEmailValidator to avoid 'email:' naming collision with ActiveModel::Validations::EmailValidator in 'validates' statement.
Make use of the options attribute of the parent class ActiveModel::EachValidator.
Add more options: regex.

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

Signed-off-by: Rémy Coutable <remy@rymai.me>

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

Resolve "Can add an existing group member into a group project with new permissions but permissions are not overridden"

GitLab EE extends Member#add_user by adding some LDAP specific flags.
Prior to these changes, the only way this could be done was by modifying
Member#add_user in place. This could lead to merge conflicts whenever a
developer wants to change this method.

To resolve this issue, the logic that EE extends has been moved into a
separate method with the appropriate arguments. This allows EE to extend
the logic by prepending the method using an EE specific module.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Partially addresses #47424.

* Show 2fa badge on a group members page
* Make group members page UI consistent with project members page
* Fix ambiguous sql in User.with/without_two_factor methods

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Move it to Members::ApproveAccessRequestService.

Also, note that there was a double audit event log for access request
destruction.

Signed-off-by: Rémy Coutable <remy@rymai.me>

- Create MemberPresenter alongside with GroupMemberPresenter and ProjectMemberPresenter
- Make Member model Presentable
- Move action_member_permission from MembersHelper into the MemberPresenter
- Added rspec using double, separate specs for GroupMemberPresenter and ProjectMemberPresenter

Fixes #28004.

Signed-off-by: Rémy Coutable <remy@rymai.me>

The following optimizations were performed:

- Add new association to GroupMember and ProjectMember

  This new association will allow us to check if a user is a member of a
  Project or Group through a single query instead of two.

- Optimize retrieving of Members when adding multiple Users

since this is for user invites and the like.