Link to the user's profile in the abuse reports
Link to the user's profile in the abuse reports and add a link to the
admin area view if the user viewing the profile is an admin
Fixes#9127
See merge request !5118
Allow specifying protected branches using wildcards
Closes#18627
# Tasks
- [ ] #18627!4665 Allow specifying protected branches using wildcards
- [x] Find existing usages of protected branches
- Protecting branches
- `ProtectedBranchesController` is used to mark a branch protected/unprotected
- `API::Branches` can be used to mark a branch protected/unprotected
- Enforcing branch protection
- `Gitlab::GitAccess` has helpers (`can_push_to_branch?`, `check`) that are used to deny pushes if a branch is protected
- Over SSH: `gitlab-shell` receives a push, and calls `/allowed` on the GitLab API, which calls `GitAccess.check`
- Over HTTP:
- `gitlab-workhorse` receives the request, and forwards it to rails
- Rails (in the `GitHttpController#git-recieve-pack`) runs basic checks (is the user logged in, not protected branch checks) and returns ok with `GL_ID` and `RepoPath`
- `gitlab-workhorse` looks at the response, and calls the relevant `gitlab-shell` action from `git-http/handlePostRPC`
- Rest of this flow is the same as the SSH flow above
- [x] Implementation
- [x] Backend
- [x] Change `project#protected_branch?` to look at wildcard protected branches
- [x] Change `project#developers_can_push_to_protected_branch?`
- [x] Change `project#open_branches`
- [x] Better error message when creating a disallowed branch from the Web UI
- [x] Frontend
- [x] Protected branches page should allow typing out a wildcard pattern
- [x] Add help text explaining the use of wildcards
- [x] Show matching branches for each protected branch
- [x] ~~On the index page~~
- [x] On a show page
- [x] Index?
- [x] Can't have the "last commit" column for wildcard protected branches
- [x] Fix / write tests
- [x] What happens if a hook is missing in dev?
- [x] Refactor
- [x] Test workflows
- Create a branch matching a wildcard pattern
- Push to a branch matching a wildcard pattern
- Force push to a branch matching a wildcard pattern
- Delete a branch matching a wildcard pattern
- [x] Test using Web UI
- [x] Test over SSH
- [x] Test over HTTP
- [x] Test as developer and master
- [x] Investigate performance
- [x] Test with a large number of protected branches / branches
- [x] Paginate list of protected branches
- [x] ~~Possibly rewrite `open_branches`~~
- [x] Add `iid`s to existing `ProtectedBranch`es
- [x] Add documentation
- [x] Add CHANGELOG entry
- [x] Add screenshots
- [x] Make sure [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/2f753e3ed2ce681b4444944d521f4419e8ed37f7/builds) passes
- [x] Assign to endboss for review
- [x] Address @DouweM's comments
- [x] `protected_branch_params`
- [x] `exact_match` instead of `explicit_match`
- [x] When would self.name be blank?
- [x] Move `protected_branches.each` to a partial
- [x] Move `matching_branches.each` to a partial
- [x] If the branch is in @matching_branches, it's not been removed
- [x] move this regex to a method and memoize it
- [x] `commit_sha` directly for exact matches
- [x] Number of matches for wildcard matches, with a link
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/43f9ce0e88194b8f719bb1c1e656b7fc13278d56/builds) to pass
- [x] Respond to @DouweM's comments
- [x] Don't use iid
- [x] Controller should use `@project.protected_branches.new`
- [x] move the memoization to `def wildcard_regex`
- [x] render with `collection: @protected_branches`
- [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/f7beedf122fa0c7aa89e86181fe7499321fb10ca/builds) to pass
- [x] Wait for @DouweM's review
- [x] Wait for @jschatz1's review
- [x] Respond to @jschatz1's comments
- [x] Use the new dropdown style
- [x] description should be moved to the description section without the styling
- [x] Protect button should be disabled when no branch is selected
- [x] Update screenshots
- [x] Merge conflicts
- [x] Make sure [build](https://gitlab.com/gitlab-org/gitlab-ce/commit/20f3cfe8d5540eab64c2ba548043d600b28c61ba/builds) passes
- [ ] Revisit performance, possibly with staging/production data
- [ ] Get a dump of staging / run against staging live
- [ ] Get SSH access to staging
- [ ] Wait for review/merge
# Screenshots
## Creating wildcard protected branches




### Using the `GLDropdown` component

## Enforcing wildcard protected branches
### From the Web UI

### Over SSH

### Over HTTPS

## Listing matching branches

See merge request !4665
Added blank state to issues
## What does this MR do?
Adds new blank state to issues when no issues exist.
Part of #18519
## Screenshots (if relevant)

See merge request !4908
New diff notes
Fixes#12732, #14731, #19375, #14783
Builds on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4110
To do:
- [x] Get it mostly working
- [x] Validate position validity
- [x] Fix: Don’t link to `#`
- [x] Fix: Base ref can be `nil`, potentially, when the MR has an oprhan source branch => Yep, doesn’t work. We need to store a `start_id`
- [x] Optimize: Fewer duplicate `git diff` compares
- [x] Optimize: Pass paths to `PositionTracer#diff` for faster diffs
- [x] Refactor: Use `head_id` in `MergeRequest`/`MergeRequestDiff` instead of `source_sha`
- [x] Refactor: Convert existing array-based diff refs to the DiffRefs model
- [x] Tweak: Use `note_type` in `Autosave` key
- [x] Tweak: Remove `line_code: note.line_code` from `link_to_reply_discussion`
- [x] Update: `SentNotifications` and reply-by-email receiver
- [x] Update: MR diff notification email
- [x] Update: API (MR, Commit note creation and entity)
- [x] Update: GitHub importer
- [x] Address any other TODO comments
- [x] Fix: Suppress "edited 4 minutes ago"
- [x] Write tests
- [x] `LineMapper`
- [x] `PositionTracer`
- [x] `Position`
- [x] `DiffPositionUpdateService`
- [x] `DiffNote`
- [x] `MergeRequests::RefreshService` / `MergeRequest#update_diff_notes_positions`
- [x] Make sure commits with diff notes don't get cleaned up, since this would prevent the diff notes from being rendered (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5062)
Future improvements:
- Display unresolved comments on files outside the diff, if the comment was added when that file _was_ part of the diff
- Allow commenting on sections between hunks, when expanding the diff using `...`
- (We'd need to generate line code based on Position if we have it, even if it falls outside bounds of diff)
- `diff_hunk` on diff note API entity
- Show diff hunk in notification email
- Resolved line notes would have a boolean, and be inactive through `notes.any? { !active? || resolved? }`
- Multi line notes would store a number of positions, and do the right thing (™) in grouping and then rendering if the first item is multiline? => true
- Image diff notes could store x,y,width,height instead of old_line,new_line for similar grouping. Does it need a reference to say if it's on old or new? These can't have line_codes, clearly. Rendering would be interesting.
- Show commit line comments in the MR diff
- Comment on specific selected words
- Comment on file header
- Unfold top of discussion diff note
- New diff notes API for commits and MRs
/cc @rspeicher
See merge request !4101
1. Modify the component to support a callback for every key press in the
filter. We need this so we can update the "Create: <branch_name"
label.
2. Modify the component to use `$(<selector>).first().click()` instead
of `$(selector)[0].click()`, because the latter is non-standard, and
doesn't work in PhantomJS.
Get rid of pluralize on stage names
## What does this MR do?
Removes `pluralize` from stage names
## What are the relevant issue numbers?
Closes#18283
Part of https://gitlab.com/gitlab-org/gitlab-ce/issues/18920
## Screenshots (if relevant)

cc @ayufan
See merge request !5117
Don't show "request access" button to project owners
This MR fixes an issue where project owners that are not in the project's members list (I believe this is how we handled project owners before, now we seem to create a "Master" member for the project creator) would see the `Request Access` button.
This MR fixes this issue in a clean way by adding a new `:request_access` ability to replace an ugly helper.
It also give project owners the ability to update & destroy a requester that would happen to be themselves (since owners could request access to their own project before this MR).
Related to #18790.
See merge request !5091
- Group / project members cannot request access
- Group members cannot request access to a group's project
This addresses an issue where project owners could request access
to their own project, leading to UI inconsistency where their requester
status would replace their owner status.
Signed-off-by: Rémy Coutable <remy@rymai.me>
1. Doesn't seem like there's an easy way to do this for the actual
branch protection, since we'd have to test an actual `git push`.
2. Testing branch creation the web UI is also not straightforward,
since the factory repo doesn't have any hooks, and so access checks
at the `gitlab-shell` level aren't run.
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
* upstream/master: (120 commits)
Update CHANGELOG for 8.9.4, 8.8.7, and 8.7.9.
Remove additional entries from CHANGELOG
Catch permission denied errors and ignore the disk
Remove coveralls lines
Make GH one-off auth the default again for importing GH projects
Import from Github using Personal Access Tokens.
Remove hardcoded gitlab-shell version in test env now that the required tag is published
Updated breakpoint for sidebar pinning
Expire branch/tag git data when needed.
Remove unnecessary parens
Enable Style/UnneededCapitalW Rubocop cop
Expiry date on pinned nav cookie
Fix broken spec in git_push_service_spec by stubbing an external issue tracker
Handle external issues in IssueReferenceFilter
Move Changelog entry for build retry fix to 8.9.4
Add Changelog entry for build sidebar retry link fix
Improve method that tells if build is retryable
Do not show build retry link when build is active
Remove coveralls as its unused
Move changelot item "Add sub nav to file page view" to 8.9.4
...
The regression was introduced by:
https://gitlab.com/gitlab-org/gitlab-ce/commit/1b8f52d9206bdf19c0dde04505c4c0b1cf46cfbe
I did that because there's a test specifying that a shared runner cannot
be enabled, in the API. So I assume that is the case for non-admin, but
admins should be able to do so anyway.
Also added a test to make sure this won't regress again.
Closes#19039
Fix an information disclosure when requesting access to a group containing private projects
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19102.
The commit speaks for itself:
Fix an information disclosure when requesting access to a group containing private projects
The issue was with the `User#groups` and `User#projects` associations
which goes through the `User#group_members` and `User#project_members`.
Initially I chose to use a secure approach by storing the requester's
user ID in `Member#created_by_id` instead of `Member#user_id` because I
was aware that there was a security risk since I didn't know the
codebase well enough.
Then during the review, we decided to change that and directly store the
requester's user ID into `Member#user_id` (for the sake of simplifying
the code I believe), meaning that every `group_members` / `project_members`
association would include the requesters by default...
My bad for not checking that all the `group_members` / `project_members`
associations and the ones that go through them (e.g. `Group#users` and
`Project#users`) were made safe with the `where(requested_at: nil)` /
`where(members: { requested_at: nil })` scopes.
Now they are all secure.
See merge request !1973
The issue was with the `User#groups` and `User#projects` associations
which goes through the `User#group_members` and `User#project_members`.
Initially I chose to use a secure approach by storing the requester's
user ID in `Member#created_by_id` instead of `Member#user_id` because I
was aware that there was a security risk since I didn't know the
codebase well enough.
Then during the review, we decided to change that and directly store the
requester's user ID into `Member#user_id` (for the sake of simplifying
the code I believe), meaning that every `group_members` / `project_members`
association would include the requesters by default...
My bad for not checking that all the `group_members` / `project_members`
associations and the ones that go through them (e.g. `Group#users` and
`Project#users`) were made safe with the `where(requested_at: nil)` /
`where(members: { requested_at: nil })` scopes.
Now they are all secure.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Display group/project access requesters separately in admin
## What does this MR do?
It displays the access requesters in a separate list in group & project members pages.
It also harmonize the members counter UI to use `%span.badge` everywhere (in the admin & non-admin members views).
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
To not confuse access requesters with actual members.
## What are the relevant issue numbers?
Closes#18871.
## Screenshots
### Group members
| Before | After |
| --------- | ---- |
|  |  |
### Project members
| Before | After |
| --------- | ---- |
|  |  |
### Admin group members
| Before | After |
| --------- | ---- |
|  |  |
### Admin project members
| Before | After |
| --------- | ---- |
|  |  |
## Does this MR meet the acceptance criteria?
- [x] No CHANGELOG since this is related to the original "request access" MR.
- [ ] 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 !4798
Resolve "Destroying a project causes post_decline_request to be executed"
## What does this MR do?
Ensure we don't send "access request declined" to access requesters when a project is deleted.
## Are there points in the code the reviewer needs to double check?
I've created a service to decouple the notification sending from the AR model.
## Why was this MR needed?
Because there was an issue.
## What are the relevant issue numbers?
Fixes#18755, #18750.
## Does this MR meet the acceptance criteria?
- [x] No CHANGELOG needed.
- [x] Tests
- [x] Added for this feature/bug
- [x] 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 !4744
Updated blank state for environments and deployments
## What does this MR do?
Adds a designed blank state to environments and deployments.
@markpundsack do we want to hide the new environments when empty? Looks weird otherwise with the green button at the top.
## What are the relevant issue numbers?
Closes#18661
## Screenshots (if relevant)


See merge request !4818
Show proper image ID on registry page
## What does this MR do?
Display the container registry image ID (from the config blob) instead of the first image layer ID
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
To show proper image ID on container_registry page.
This only supports manifest V2, since the manifest V1 doesn't expose information about Image ID.
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/18159.
## Screenshots (if relevant)

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] 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 !4821
GitLab CI Yaml template dropdown
## What does this MR do?
Make it possible to select a dropdown for an easy start with GitLab CI.
## What are the relevant issue numbers?
Closes#17521
## TODO
- [ ] Backend
- [x] CHANGELOG item
- [x] Fix rubocop failure
- [x] API Support
- [x] New tests
- [x] Add disclaimer to the top of the gitlab-ci.yml
- [ ] Frontend
- [x] New tests
See merge request !4411
Make it possible to lock runner on a specific project
Make it possible to lock runner on a specific project.

----

----

Closes#3407
See merge request !4093