| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
Restrict reopening locked issues for non authorized issue authors
Closes #39665
See merge request gitlab-org/gitlab-ce!21299
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow date parameters on Issues, Notes, and Discussions API for group owners
Closes #40059
See merge request gitlab-org/gitlab-ce!21342
|
| | | |
| | |
| | |
| | | |
This is more idiomatic than checking membership explicitly.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Allow to delete group milestones
Closes #36138
See merge request gitlab-org/gitlab-ce!21057
|
| | | | |
|
| | |/
|/|
| |
| | |
This whitelists all existing places where we use "destroy_all".
|
| | |
| |
| | |
This reverts merge request !21044
|
| | |
| |
| |
| |
| | |
Making the migrations and the default do the right thing in the first
place. This makes 20180806094307 a no-op.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow users to set a status
Closes #35463
See merge request gitlab-org/gitlab-ce!20614
|
| | | |
| | |
| | |
| | |
| | | |
This can be done trough the API for the current user, or on the
profile page.
|
| | |/
|/| |
|
| | |
| |
| |
| |
| | |
into 'master'"
This reverts merge request !20679
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
'master'
Resolve "Making instance-wide data tools more accessible"
Closes #41416 and #48507
See merge request gitlab-org/gitlab-ce!20679
|
| | |/ |
|
| |/
|
|
| |
if all methods are also presented in the user.
|
| | |
|
| | |
|
| |
|
|
|
| |
This allows us to check specific abilities in views, while still
enabling/disabling them at once.
|
| |
|
|
| |
repository or builds are disabled
|
| |
|
|
|
|
| |
branch"
"Maintainer" will be freed to be used for #42751
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The `access_git` and `access_api` were currently never checked for
anonymous users. And they would also be allowed access:
An anonymous user can clone and pull from a public repo
An anonymous user can request public information from the API
So the policy didn't actually reflect what we were enforcing.
|
| |
|
|
|
|
| |
When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enforces the terms in the web application. These cases are
specced:
- Logging in: When terms are enforced, and a user logs in that has not
accepted the terms, they are presented with the screen. They get
directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
with the screen to accept the terms. After they accept they are
directed to the dashboard.
- While a session is active:
- For a GET: The user will be directed to the terms page first,
after they accept the terms, they will be directed to the page
they were going to
- For any other request: They are directed to the terms, after they
accept the terms, they are directed back to the page they came
from to retry the request. Any information entered would be
persisted in localstorage and available on the page.
|
| |
|
|
|
| |
When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.
|
| |
|
|
|
|
|
| |
We will reuse the the dropdown, but exclude some menu items based on
permissions.
So moving the menu to a partial, and adding checks for each menu item here.
|
| |
|
|
| |
child project
|
| |
|
|
| |
This prevents performing the requests, and disables all emoji reaction buttons
|
| |
|
|
|
|
|
|
|
|
| |
So we can distinguish between the permissions on the source and the
target project.
- `create_merge_request_from` indicates a user can create a merge
request with the project as a source_project
- `create_merge_request_in` indicates a user can create a merge
request with the project as a target_project
|
| |
|
|
|
|
|
| |
This prevents creating merge requests targeting archived projects.
This could happen when a project was already forked, but then the
source was archived.
|
| | |
|
| | |
|
| |
|
|
| |
prevent confusion with destroy_protected_branch
|
| |
|
|
| |
Also, fixes broken specs
|
| |
|
|
|
|
| |
Also:
- Changes scopes from serializer to use boolean columns
- Fixes broken specs
|
| | |
|
| |
|
|
|
|
| |
- Remove extra method for authorize_admin_project
- Ensure project presence
- Rename 'read_repo' to 'read_repository' to be more verbose
|
| |
|
|
|
|
|
| |
- When using 'read_repo' password and project are sent, so we used both
of them to fetch for the token
- When using 'read_registry' only the password is sent, so we only use
that for fetching the token
|
| |
|
|
|
|
|
|
| |
read_project can be prevented by a very expensive condition, which we want to
avoid, while still not writing manual SQL queries. read_project_for_iids is used
by read_issue_iid and read_merge_request_iid to satisfy both of those
constraints, and allow the declarative policy runner to use its normal caching
strategy.
|
| | |
|
| | |
|
| |
|
|
| |
Explored Policy framework to create something I can use as a starting point.
|
| |
|
|
|
| |
The query becomes a lot simpler if we can check the branch name as
well instead of having to load all branch names.
|
| |
|
|
|
|
|
|
| |
When an MR is created using `allow_maintainer_to_push`, we enable some
abilities while the MR is open.
This should allow every user with developer abilities on the target
project, to push to the source project.
|
| | |
|
| |
|
|
|
|
| |
'security-10-4-25223-snippets-finder-doesnt-obey-feature-visibility' into 'security-10-4'
[Port for security-10-4]: Makes SnippetFinder ensure feature visibility
|
| |\
| |
| |
| |
| |
| |
| | |
Hide pipeline schedule 'take ownership' for current owner
Closes #35285
See merge request gitlab-org/gitlab-ce!12986
|
| | | |
|
| |/
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
