| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'21983-member-add_user-doesn-t-detect-existing-members-that-have-requested-access' into 'master'
Resolve "`Member.add_user`doesn't detect existing members that have requested access"
## What does this MR do?
This merge request handle the case when an access requester is added to a group or project (via the members page or the API).
In `Member.add_user`, if an access requester already exists, we simply accept their request (and set the `created_by`, `access_level` and `expires_at` attributes if given).
## Are there points in the code the reviewer needs to double check?
I've taken the opportunity to cleanup the whole `{Group,Project}Member.add_user*` methods since it was quite a mess.
## What are the relevant issue numbers?
Closes #21983
See merge request !6393
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
New `Members::RequestAccessService`
Part of #21979.
See merge request !6265
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
* Created a force=true param that will continue with the previous
behaviour of the unsubscribe method
* Created a filter for not-logged users so they see a unsubsribe
confirmation page
* Added the List-Unsubscribe header on emails so the email client can
display it on top
|
| |\
| |
| |
| | |
# Conflicts:
# db/schema.rb
|
| | |\ |
|
| | | | |
|
| |\ \ \
| | |/
| |/| |
|
| | |/ |
|
| | |
| |
| | |
This object will manage Gitlab::Git::Compare instances
|
| |/ |
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Exclude requesters from Project#members, Group#members and User#members
## What does this MR do?
It excludes requesters from the `Project#members`, `Group#members` and `User#members` associations, and adds new `Project#requesters` and `Group#requesters` associations.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
Without this, if you call `project.members`, requesters are included in the results! This is at best misleading, and at worst can lead to security issues. By excluding requesters from the `#members` associations, we avoid introducing security inadvertently since you have to call the `#requesters` association explicitly to get requesters.
## What are the relevant issue numbers?
This is something I realized while fixing the security issue #19102.
## Does this MR meet the acceptance criteria?
- [x] I don't think this needs a CHANGELOG since this is an internal change
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4946
|
| | |
| |
| |
| |
| |
| | |
And create new Project#requesters, Group#requesters scopes.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/ |
|
| |
|
|
|
|
|
| |
A project in a group can have no explicit owners/masters,
in that case we fallbacks to the group's owners/masters.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
+ Move 'Edit Project/Group' out of membership-related partial
+ Show the access request buttons only to logged-in users
+ Put the request access buttons out of in a more visible button
+ Improve the copy in the #remove_member_message helper
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also removes the note from the development/testing.md guide
|
| |
|
|
|
| |
Based on:
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
|
| |
|
|
|
|
|
|
|
| |
The repository push email can be very expensive to generate, especially
with syntax-highlighted diffs. Instead of generating the email for each
recipient, generate one email object and reset the Message-Id and To
headers for each recipient. (Cloning would also be expensive in the case
of large emails, although probably not as bad as generating from
scratch.)
|
| |\
| |
| |
| |
| |
| |
| | |
use ! rather than # for merge request references
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/15278
See merge request !3740
|
| | | |
|
| |/ |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Closes #14943.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the reply-by-email feature
A few things to note:
- The IncomingEmail feature is now enabled even without a
correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
notifications to this thread are grouped in the thread by the email
service that receives the notification
(i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
| |
1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
|
| |
|
|
|
|
|
|
| |
Related to #2235.
This is done by:
1. Delaying the notification sending after the SSH key is commited in DB
2. Gracefully exit the mailer method if the record cannot be found
|
