| 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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Add missing values to linter (`only`, `except`) and add new one `Environment`
Closes #21744
See merge request !6276
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Initialize Redis pool in single-threaded context
See merge request !6613
|
| | | | |
| | | |
| | | |
| | | | |
This side-steps the need for mutexes and whatnot.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Remove the "soon to be deprecated" `alias_method_chain` in favor of `Module#prepend`.
## Are there points in the code the reviewer needs to double check?
Double check whether the behavior of `attr_encrypted_no_db_connection` is still the desired one.
## Why was this MR needed?
The `alias_method_chain` becomes deprecated in Rails 5 in favor of the `Module#prepend` introduced in Ruby 2.0.
This MR prevents future deprecated warnings in light of a possible Rails version bump.
Closes #22302
See merge request !6570
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Take filters in account in issuable counters
## What does this MR do?
This merge request ensure we display issuable counters that take in account all the selected filters, solving #15356.
## Are there points in the code the reviewer needs to double check?
There was an issue (#22414) in the original implementation (!4960) when more than one label was selected because calling `#count` when the ActiveRecordRelation contains a `.group` returns an OrderedHash. This merge request relies on [how Kaminari handle this case](https://github.com/amatsuda/kaminari/blob/master/lib/kaminari/models/active_record_relation_methods.rb#L24-L30).
A few things to note:
- The `COUNT` query issued by Kaminari for the pagination is now cached because it's already run by `ApplicationHelper#state_filters_text_for`, so in the end we issue one less SQL query than before;
- In the case when more than one label are selected, the `COUNT` queries return an OrderedHash in the form `{ ISSUABLE_ID => COUNT_OF_SELECTED_FILTERS }` on which `#count` is called: this drawback is already in place (for instance when loading https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&state=all&utf8=%E2%9C%93&label_name%5B%5D=bug&label_name%5B%5D=regression) since that's how Kaminari solves this, **the difference is that now we do that two more times for the two states that are not currently selected**. I will let the ~Performance team decide if that's something acceptable or not, otherwise we will have to find another solution...
- The queries that count the # of issuable are a bit more complex than before, from:
```
(0.6ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('opened','reopened')) [["project_id", 2]]
(0.2ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('closed')) [["project_id", 2]]
(0.2ms) SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 [["project_id", 2]]
```
to
```
(0.7ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND ("issues"."state" IN ('opened','reopened')) AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
(0.5ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND ("issues"."state" IN ('closed')) AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
(0.5ms) SELECT COUNT(*) AS count_all, "issues"."id" AS issues_id FROM "issues" INNER JOIN "label_links" ON "label_links"."target_id" = "issues"."id" AND "label_links"."target_type" = $1 INNER JOIN "labels" ON "labels"."id" = "label_links"."label_id" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = 2 AND "labels"."title" IN ('bug', 'discussion') AND "labels"."project_id" = 2 GROUP BY "issues"."id" HAVING COUNT(DISTINCT labels.title) = 2 [["target_type", "Issue"]]
```
- We could cache the counters for a few minutes? The key could be `PROJECT_ID-ISSUABLE_TYPE-PARAMS`.
A few possible arguments in favor of "it's an acceptable solution":
- most of the time people filter with a single label => no performance problem here
- when filtering with more than one label, usually the result set is reduced, limiting the performance issues
## What are the relevant issue numbers?
Closes #15356
See merge request !6496
|
| | |/ / /
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Expose the Koding application settings in the API
## Why was this MR needed?
When saving the GitLab application secrets in Koding, and authorising your admin user to have access to the UI, we want to let Koding enable the integration, and populate the url in GitLab for the user.
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22705
See merge request !6555
|
| | | | |
| | | |
| | | |
| | | | |
This will allow the Koding app to enable the integration itself once is has authorized an admin user using the application secrets.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
New `AccessRequestsFinder`
Part of #21979.
## Does this MR meet the acceptance criteria?
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] 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 !6268
|
| | | |_|/
| |/| |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |/ /
|/| |
| | |
| | | |
retrieve it, but before we can set the new expiry time.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Expose project share expiration_date field on API
closes #22382
See merge request !6484
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Remove duplicate VersionInfo class
This was brought over during the CI merge and already exists at
`lib/gitlab/version_info.rb`.
See merge request !6586
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This was brought over during the CI merge and already exists at
`lib/gitlab/version_info.rb`.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Expose pipeline data in builds API
Exposes pipeline data in builds API, as suggested by #22367.
The fields exposed were 'id', 'status', 'ref', and 'sha'.
Closes #22367
See merge request !6502
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
add pipeline ref, sha, and status to the build API response
add tests of build API (pipeline data)
change API documentation for builds API
log change to builds API in CHANGELOG
CHANGELOG: add reference to pull request and contributor's name
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called
## What does this MR do?
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called, instead return the saved token if one is present.
This was causing a lot of 401s, leading to 403s, as state in #22527
As it turns out, when pushing a lot of LFS objects, the LFS client was calling `git-lfs-authenticate` in the middle of the request again. This caused the `lfs_token` to be regenerated. The problem lies in that the LFS client was not aware of this change, and was still using the old token. This caused all subsequent requests to fail with a 401 error.
Since HTTP Auth is protected by Rack Attack, this 401s where immediately flagged and resulted in the IP of the user being banned.
With this change, GitLab returns the value stored in Redis, if one is present, thus if the LFS client calls `git-lfs-authenticate` again during the request, the auth header will remain unchanged, allowing all subsequent requests to continue without issues.
## What are the relevant issue numbers?
Fixes #22527
cc @SeanPackham @jacobvosmaer-gitlab
See merge request !6551
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Redis connection.
Reset expiry time of token, if token is retrieved again before it expires.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
called, instead return the saved token if one is present.
|
| | |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before we weren’t caching current_project_ref because normally the reference to
the current project doesn’t include the path with namespace. But now we store
the current project in the projects reference cache to be used for the same
filter when accessing using path with namespace of for subsequent filters executed on the cache.
|
| | |/ / /
|/| | |
| | | |
| | | | |
without references
|
| | |_|/
|/| |
| | |
| | | |
Signed-off-by: Roger Meier <r.meier@siemens.com>
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
* No need to re-fetch issues from GH to read their labels, the labels
are already there from the index request.
* No need to look up labels on the database for every application, so we
cache them.
|
| |/ /
| |
| |
| |
| | |
This should avoid having large memory growth when importing GitHub repos
with lots of resources.
|
| | |
| |
| |
| | |
relevant specs.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add organization field to the user profile
## What does this MR do?
Add organization field to the user profile
## Are there points in the code the reviewer needs to double check?
no
## Why was this MR needed?
So we can let users fill organization information separately
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [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)
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/21903
See merge request !6526
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
New `Members::ApproveAccessRequestService`
Part of #21979.
## Does this MR meet the acceptance criteria?
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] 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 !6266
|
| | |/
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Keep API mounts in alphabetical order
## What does this MR do?
Just a cosmetic change to keep the API mounts in order.
See merge request !6515
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Also fixed CustomIssueTrackerService title setter and added relevant specs.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use base SHA for patches and diffs
## What does this MR do?
Switch from using 'start SHA' to 'base SHA' for patches and diffs
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
Makes the downloaded patches and diffs on the merge request page match the frontend-rendered "changes" in these scenarios:
* Unpatched gitlab-workhorse, downloading patchsets of open MRs (https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/68)
* Unpatched gitlab-workhorse, downloading diffs of open and merged MRs
* Patched gitlab-workhorse, downloading patchsets of merged merge requests
## What are the relevant issue numbers?
Closes #22229
See merge request !6435
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit changes the revisions used for diffs. The current behaviour is
to show all changes between current tip of master and tip of the MR, rather
than matching the output of the web frontend (which just shows the changes
in the MR). Switching from start_sha to base_sha fixes this.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix a memory leak in HTML::Pipeline::SanitizationFilter::WHITELIST
See merge request !6456
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous fix introduced another leak; as it made
Banzai::Filter::SanitizationFiler#customized? always return false, so we
were always appending two elements to
HTML::Pipeline::SanitizationFilter::WHITELIST[:elements]. This growth in
the elements array would slow the sanitization process over time.
|
| | | | |
| | | |
| | | |
| | | | |
This reverts commit 504a3b5e6f0b2e2957cf1e4d9d8eebbf32234bdb.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix database seeds for development environment
## What does this MR do?
This MR fixes database seeds for development environment and adds CI test for it.
## Why was this MR needed?
Database seeds for development environment are often broken, and we are not able to catch that when someone modified `db/fixtures` and forgets to reseed database.
Closes #22422
See merge request !6475
|
| | | | | |
|
| | | | | |
|
