Winnie Hellmann authored 5 years ago and Bob Van Landuyt :neckbeard: committed 5 years ago

This reverts merge request !30613

Charlie Ablett authored 5 years ago and Paul Slaughter committed 5 years ago

- DB migration of board milestone values
- issue finder & spec updates

We dropped MySQL support and a lot of mysql specific code has been
removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608.

This comes in from the other direction and removes any `if postgresql?`
branches.

If we're not using a trigram index, then ignore the
min_chars_for_partial_matching setting

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Remove label_name and milestone_title params support
Add mutually_exclusive validation for author_id and author_username
Add mutually_exclusive validation for assignee_id and assignee_username
Add validation to allow single value for asignee_username on CE
Add separate issue_stats_params helper for statistics params and
reuse in issues_params.

When issues_controller endpoint was used for search, the parameters
passed to the controller were slightly different then the ones
passed to API. Because the searchbar UI is reused in different
places and builds the parameters passed to request in same way
we need to account for old parameter names.


Add issues_statistics api endpoints

Adds issue_statistics api endpoints for issue lists and returns
counts of issues for all, closed and opened states.


Expose more label attributes based on a param

When requesting issues list through API expose more attributes
for labels, like color, description if with_labels_data param is
being passed, avoiding this way to change response schema for users
that already use API.

https://gitlab.com/gitlab-org/gitlab-ce/issues/57402

Francisco Javier López authored 5 years ago and James Lopez committed 5 years ago

Removed the conditions added to
Project.with_feature_available_for_user, and moved to the
IssuableFinder. Now, we ensure that, in the projects retrieved
in the Finder, the user has enough access for the feature.

This was removed by a previous MR but broke some links

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

This fixes the bug, when approver filter is provided,
but dashboard asks to enter any filter

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.

The Upcoming milestone filter only considers active milestones, but the
Started one included closed milestones, too. This was inconsistent.

Since the CTE is faster than a subquery and the only reason we're using
a subquery is that the CTE can't handle sorting by certain attributes,
let's use the CTE always (when the feature flag is enabled) when
counting, since we can ignore ordering if we just want a count of
results.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Refactored to use Rails 5 ActiveRecord `or` so that it can handle ids,
objects, array of objects, or relations properly.

We already had a flag to use a CTE, but this broke searching in some
cases where we need to sort by a joined table. Disabling the CTE flag
makes searches much slower.

The new flag, to use a subquery, makes them slightly slower than the
CTE, while maintaining correctness. If both it and the CTE flag are
enabled, the subquery takes precedence.

By using the parameters `?labels=None|Any` the user can filter
issues/mrs from the API that has `none/any` label.

Affected endpoints are:

- /api/issues
- /api/projects/:id/issues
- /api/groups/:id/issues
- /api/merge_requests
- /api/projects/:id/merge_requests
- /api/groups/:id/merge_requests

We don't think this is needed any more - see
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521, and
https://gitlab.com/gitlab-org/gitlab-ce/issues/52271 for removing the flag.

In GET `api/v4/projects/:id/issues` the user can filter issues
that have an assigned milestone through the parameter
`milestone=Any+Milestone`.

Partially addresses #47424.