| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6043"
This reverts commit 6d43c95b7011ec7ec4600e00bdc8df76bb39813c.
|
|
|
|
| |
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6043
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Groups can enable/disable LFS, but this setting can be overridden at the project level. Admin only
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
# 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
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
'master'
API: Use Search::GlobalService in projects search API
See merge request !6280
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also streamline the sorting part while we're at it.
That being done, there's currently a duplication between
`GET /projects/search/:query` and `GET /projects?search=:search`
so we might want to keep only the latter for 9.0...
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix API issues sorting
## What does this MR do?
Fix the sorting of issues in the API.
## Are there points in the code the reviewer needs to double check?
Instead of removing the '_at' suffix manually, we could add those versions to the `Sortable` concern instead.
## Why was this MR needed?
There were a couple of bugs:
* The global and project-specific issues endpoints wouldn't sort at all.
* Group sorting would work, but only if you applied two undocumented workarounds:
* Always pass both `order_by` and `sort` (both are optional, so only one should be needed to change ordering).
* Instead of passing `created_at` or `updated_at`, you needed to pass `created` or `updated`.
This makes the API implementation match the docs.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [ ] 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?
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/983.
See merge request !6281
|
| |/ |
|
|/
|
|
| |
Use NotificationSetting::EMAIL_EVENTS for params
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Browser interface allows forking to an owned grup.
This commit brings API up to speed by providing optional namespace
parameter to fork API. This allows forking to users and groups under
forker's control using their id or unique name.
Fixes #21591
|
|\
| |
| |
| |
| |
| |
| | |
Minor edits to two_factor_recovery_codes API error catching
Minor fixes to the `two_factor_recovery_codes` internal API making the conditionals more sane. Thanks @DouweM for pointing it out.
See merge request !6000
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Project tools visibility level
## part of #19734

## 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 [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 !5606
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Merge request sha info
## What does this MR do?
Exposes `sha` and `merge_commit_sha` items in `MergeRequest` API endpoint data.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
It's useful information.
## What are the relevant issue numbers?
Closes #20456.
## Screenshots (if relevant)
N/A
## 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 [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 !5966
|
| | |
| | |
| | |
| | | |
Fixes #20456.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Refactor ability.rb into Policies
## What does this MR do?
Factors out `ability.rb` into a new abstraction - the "policy" (stored in `app/policies`). A policy is a class named `#{class_name}Policy` (looked up automatically as needed) that implements `rules` as follows:
``` ruby
class ThingPolicy < BasePolicy
def rules
@user # this is a user to determine abilities for, optionally nil in the anonymous case
@subject # this is the subject of the ability, guaranteed to be an instance of `Thing`
can! :some_ability # grant the :some_ability permission
cannot! :some_ability # ensure that :some_ability is not allowed. this overrides any `can!` that is called before or after
delegate! @subject.other_thing # merge the abilities (can!) and prohibitions (cannot!) from `@subject.other_thing`
can? :some_ability # test whether, so far, :some_ability is allowed
end
def anonymous_rules
# optional. if not implemented `rules` is called where `@user` is nil. otherwise this method is called when `@user` is nil.
end
end
```
See merge request !5796
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|