| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We use a leading dash for certain things like the WebIDE, which
had the side effect of losing the `params[:continue][:to]` param when
opening the WebIDE on a project where the user doesn't have push access
and therefore needs to fork the project first.
|
| |
|
|
|
|
|
|
|
|
| |
The check for continue_params&.key?(:to) in Projects::ImportsController
caused an exception in redirect_to if this key contained a nil value.
Since url_for won't add any params for an empty hash, we can just return
that in continue_params if params[:continue] isn't present, and simplify
the code in the controllers to check for the values we actually want to
use.
|
| |
|
|
|
| |
Disabled password authentication for the users registered using
omniauth-ultraauth strategy
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- Add serializers and Grape::Entity
- Replace to_json
- Add specs
|
| |
|
|
|
|
|
|
| |
Previously import_url would always be present in the update parameters,
which would cause the validation to fail. We now only include this
parameter only if there is URL given.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/62708
|
| |\ |
|
| | |\
| | |
| | |
| | |
| | | |
Handling password on import by url page
See merge request gitlab/gitlabhq!3061
|
| | | | |
|
| | |\ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
'master'
Fix confidential issue label disclosure on milestone view
See merge request gitlab/gitlabhq!3098
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add changelog entry
Method should be public
Use milestonish method
Use render data to filter labels
Add specs for label visibility on milestone
|
| |/ /
| |
| |
| |
| | |
- adding a "Manual" option to the dropdown
- show 100 issues list when manually sorting
|
| | | |
|
| | |
| |
| |
| |
| | |
Since this needs to be called on every find_routable!(Project, ...
we can instead move it to a RoutableActions check.
|
| |/ |
|
| |
|
|
| |
Try to simplify feature flag checks by using policies
|
| | |
|
| |
|
|
|
|
|
| |
When rendering a label we want to check 'scoped_label' feature
availability on a project/group where label is being used. For
this reason a label presenter is used in UI and information about
context project/group is passed to this presenter.
|
| |
|
|
| |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |
|
|
|
| |
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
|
| |
|
| |
This reverts merge request !26823
|
| |
|
|
| |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |\
| |
| |
| |
| | |
[CE] Add mutually exclusive labels
See merge request gitlab-org/gitlab-ce!26804
|
| | |
| |
| |
| | |
Scoped labels in EE require additional changes in CE code.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Extend CTE search optimisation to projects
Closes #55170
See merge request gitlab-org/gitlab-ce!26908
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
|
| | |/
|/|
| |
| |
| | |
- added suggestions to mock data
- fixed props to be not required
|
| |/
|
|
| |
Also removes specs related to the flag
|
| |
|
|
|
|
|
| |
- concerns
- dashboard
- groups
- import
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
'master'
Fix project serialization in quick actions response
Closes #2826
See merge request gitlab/gitlabhq!3001
|
| | |
| |
| |
| |
| | |
When executing quick actions, this limits the `commands_changes`
response to only those used by the frontend
|
| | |
| |
| |
| | |
Move this to EE-only. It isn't useful here since there's only one board
|
| |/
|
|
| |
Move common functionality to BoardsActions concern
|
| |\
| |
| |
| |
| |
| |
| | |
Enable reply_to_individual_notes feature flag by default
Closes #30299
See merge request gitlab-org/gitlab-ce!25575
|
| | | |
|
| |/
|
|
|
| |
This style change enforces `return if ...` instead of
`return nil if ...` to save maintainers a few minor review points
|
| |\
| |
| |
| |
| | |
Show only MRs visible to user on milestone detail
See merge request gitlab/gitlabhq!2895
|
| | | |
|
| | |
| |
| |
| |
| | |
Fix misspellings in app/spec comments
See merge request gitlab-org/gitlab-ce!25517
|
| | |
| |
| |
| |
| |
| |
| | |
Ability to filter confidential issues
Closes #50747
See merge request gitlab-org/gitlab-ce!24960
|
| | |
| |
| |
| |
| | |
This reverts commit 9202bbd129537a698b986e6295d0c783b5a84815, reversing
changes made to 4b282e9ce1ae246c4538b3ede18d1380ea778029.
|
| | |
| |
| |
| |
| | |
This reverts commit d133bf84c668df3dfc9938bb04150754cb873c8b, reversing
changes made to 7981c0292b07a0138b096fa082341fcb13e9ce2b.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Ability to filter confidential issues
Closes #50747
See merge request gitlab-org/gitlab-ce!24960
|
| | | |
| | |
| | |
| | | |
Use internally only boolean params.
|
| | |/
| |
| |
| |
| | |
Add a new search bar filter for confidential issues. Add filtering
support to the IssuesFinder.
|
| | |
| |
| |
| | |
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
|
| |/
|
|
|
|
|
| |
Removes unneeded params from permitted list
This also fixes commenting on commits with a hash starting with a large
number
|
| |
|
|
|
|
|
|
|
| |
Due to a regression in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24919,
Content-Disposition is hard-coded to `attachment` instead of `inline`.
We now use the argument `disposition` to fix that problem.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57660
|
