| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Expose project share expiration_date field on API
closes #22382
See merge request !6484
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| |/ /
| |
| |
| |
| |
| | |
Redis connection.
Reset expiry time of token, if token is retrieved again before it expires.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| |/ |
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And Snippets get awards
## What does this MR do?
Makes snippets more awesome, by making them awardables
## Why was this MR needed?
Because Snippets were left behind.
## What are the relevant issue numbers?
Closes #17878
See merge request !4456
|
| | |
| |
| |
| | |
Also incorporate feedback
|
| | | |
|
| | | |
|
| |\ \ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add optional 'author' param when making commits
This fulfills https://gitlab.com/gitlab-org/gitlab-ce/issues/20789 by adding the ability to specify a user's ID to be used as the author of a commit.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20789
See merge request !5822
|
| | | |/ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
LFS support for ssh enabled
## What does this MR do?
This is follow-up after https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6043 which is falsely shown as merged due to: https://gitlab.com/gitlab-org/gitlab-ce/issues/22334
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] 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)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
See merge request !6413
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6043"
This reverts commit 6d43c95b7011ec7ec4600e00bdc8df76bb39813c.
|
| | |\ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
'master'
Ensure invitees are not returned in Members API
## What are the relevant issue numbers?
Closes #22065
See merge request !6370
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |\ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
Allow to set request_access_enabled for groups and projects using API
Closes #20978
See merge request !6359
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6043
|
| | |\ \ \
| | |/ / |
|
| | | |/ |
|
| | | | |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
# Conflicts:
# app/controllers/projects/git_http_client_controller.rb
# app/helpers/lfs_helper.rb
# lib/gitlab/auth.rb
# spec/requests/lfs_http_spec.rb
|
| | | | |
| | | |
| | | |
| | | | |
LFS Tokens
|
| | | | |
| | | |
| | | |
| | | | |
simplify external code.
|
| | | | |
| | | |
| | | |
| | | | |
`/lfs_authenticate` and added tests.
|
| | | | |
| | | |
| | | |
| | | | |
a 1 use only token.
|
| | | | |
| | | |
| | | |
| | | | |
- Required on the GitLab Rails side is mostly authentication and API related.
|
| | | | | |
|
| | |\ \ \
| | |/ /
| | | |
| | | |
| | | | |
# Conflicts:
# db/schema.rb
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The practical effect of this commit is to make the API check the Rails session
cookie for authentication details. If the cookie is present and valid, it will
be used to authenticate.
The API now has several authentication options for users. They follow in this
order of precedence:
* Authentication token
* Personal access token
* OAuth2 Bearer token (Doorkeeper - application access)
* Rails session cookie
|
| | |_|/
|/| |
| | |
| | |
| | |
| | | |
The `guard_all!` method is never called, and `guard!` is not implemented. The
`doorkeeper_guard!` method is also never called, and is mostly the same as its
non-bang counterpart.
|
| | | | |
|
| | |/
|/|
| |
| | |
Groups can enable/disable LFS, but this setting can be overridden at the project level. Admin only
|
| | | |
|
| |/ |
|
