| Age | Commit message (Collapse) | Author |
|---|
|
|
|
'security-53543-user-keeps-access-to-mr-issue-when-removed-from-team' into 'master'
[master] Adds validation to check if user can read project
See merge request gitlab/gitlabhq!2645
|
|
Add spec for all release API - GET, POST, PUT, DELETE.
Also, fixes some minior bugs.
|
|
This commit introduces Releases API under /api/v4/projects/:id/releases
* We are introducing release policies at project level.
* We are deprecating releases changes from tags, both api and web
interface.
* Tags::CreateService no longer create a release
This feature is controlled by :releases_page feature flag
|
|
Allow user to add cluster when there are ancestor clusters
See merge request gitlab-org/gitlab-ce!23569
|
|
Include a new policy in Clusterables
(projects and groups), which checks if another cluster
can be added
clusterable_has_cluster? and multiple_clusters_available
private methods will be overriden in EE
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/34758
|
|
- we now use the hierarchy class also for epics
- also rename supports_nested_groups? into supports_nested_objects?
- move it to a concern
|
|
An issuable should not be available to a user if the
project is not visible to that specific user
|
|
[master]Fixed ability to comment on and edit/delete comments on locked or confidential issues
See merge request gitlab/gitlabhq!2612
|
|
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
|
|
|
|
- maintainer for group can read, create, update, and admin cluster
- project user, at any level, cannot do anything with group cluster
|
|
When a Merge request is merged, shows only the Report abuse menu item
in the dropdown menu instead of showing the close_reopen_report toggle
with an unusable Close button.
The Report abuse is still hidden when the author of the Merge request
is the current_user.
Hides the Reopen button on a closed and locked issue when the
issue.author is not the current_user
|
|
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
|
|
Allow to delete group milestones
Closes #36138
See merge request gitlab-org/gitlab-ce!21057
|
|
This is more idiomatic than checking membership explicitly.
|
|
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
|
|
|
