| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
formatting
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Resolve "make project data via API report forks of this project"
Closes #20049
See merge request gitlab-org/gitlab-ce!14355
|
|
* Will dry up the code to find projects between the ForksController and the API
|
|
|
|
authentication
|
|
|
|
|
|
|
|
|
|
Re-use issue/MR counts for the pagination system
Closes #27168
See merge request !13805
|
|
This changes the issue and MR index pages so the pagination system
re-uses the output of the COUNT(*) query used to calculate the number of
rows per state (opened, closed, etc). This removes the need for an
additional COUNT(*) on both pages.
|
|
|
|
|
|
We're going to cache the total open count separately, and then just perform
these counts on the list. We already do that to get the pagination information,
through Kaminari, and a future change will make Kaminari reuse the query results
from earlier in the request.
|
|
|
|
'master'
Fix group and project search for anonymous users
Closes #31409
See merge request !13745
|
|
|
|
Closes #35994
|
|
|
|
|
|
When trying to run an UPDATE, this query is ran:
```sql
UPDATE `todos`
INNER JOIN `projects` ON `projects`.`id` = `todos`.`project_id`
SET `todos`.`state` = 'done'
WHERE `todos`.`user_id` = 4
AND (`todos`.`state` IN ('pending'))
AND (EXISTS
(SELECT 1
FROM `project_authorizations`
WHERE `project_authorizations`.`user_id` = 4
AND (project_authorizations.project_id = projects.id))
OR projects.visibility_level IN (10,
20))
AND `projects`.`id` IN
(SELECT `todos`.`project_id`
FROM `todos`
WHERE `todos`.`user_id` = 4
AND (`todos`.`state` IN ('pending')))
AND (`todos`.`state` != 'done')
```
But MySQL does not like the subquery used to filter on
`projects.id IN (SELECT ...`
Because the subquery queries from the same table:
> Error: You can’t specify target table ‘todos’ for update in FROM clause
So as workaround, wrap it in another subquery, where the original
subquery is aliased using the `AS` statement.
Mostly inspired by https://stackoverflow.com/a/43610081/89376
|
|
Having two states that essentially mean the same thing is very much like
having a boolean "true" and boolean "mostly-true": it's rather silly.
This commit merges the "reopened" state into the "opened" state while
taking care of system notes still showing messages along the lines of
"Alice reopened this issue".
A big benefit from having only two states (opened and closed) is that
indexing and querying becomes simpler and more performant. For example,
to get all the opened queries we no longer have to query both states:
SELECT *
FROM issues
WHERE project_id = 2
AND state IN ('opened', 'reopened');
Instead we can query a single state directly, which can be much faster:
SELECT *
FROM issues
WHERE project_id = 2
AND state = 'opened';
Further, only having two states makes indexing easier as we will only
ever filter (and thus scan an index) using a single value. Partial
indexes could help but aren't supported on MySQL, complicating the
development process and not being helpful for MySQL.
|
|
And add support for additional query parameters:
- `author_id`: Returns merge requests created by the given user `id`
- `assignee_id`: Returns merge requests assigned to the given user `id`
- `scope`: Return merge requests for the given scope: `created-by-me`, `assigned-to-me` or `all`
|
|
Allow issues filtering on `author_id` and `assignee_id`.
|
|
|
|
When an issuable's state changes, or one is created, we should clear the cache
counts for a user's assigned issuables, and also the project-wide caches for
this user type.
|
|
We were including controller params in the cache key, so the key for the header
didn't match the one for the list itself!
|
|
These cache a hash of counts by state, so the state isn't needed in the key
itself.
|
|
|
|
Add creation time filters to user search API for admins
Closes #29507
See merge request !12682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow unauthenticated access to the `/api/v4/users` API
Closes #34141
See merge request !12445
|
|
|
|
[ci skip]
|
|
34141-allow-unauthenticated-access-to-the-users-api
- Modify policy code to work with the `DeclarativePolicy` refactor
in 37c401433b76170f0150d70865f1f4584db01fa8.
|
|
- Use `GlobalPolicy` to authorize the users that a non-authenticated user can
fetch from `/api/v4/users`. We allow access if the `Gitlab::VisibilityLevel::PUBLIC`
visibility level is not restricted.
- Further, as before, `/api/v4/users` is only accessible to unauthenticated users if
the `username` parameter is passed.
- Turn off `authenticate!` for the `/api/v4/users` endpoint by matching on the actual
route + method, rather than the description.
- Change the type of `current_user` check in `UsersFinder` to be more
compatible with EE.
|
|
|
|
|
|
|
|
This runs a slightly slower query to get the issue and MR counts in the
navigation, but caches by user type (can see all / none confidential issues) for
two minutes.
|
|
When we are filtering by a single project, and the current user has access to
see confidential issues on that project, we don't need to filter by
confidentiality at all - just as if the user were an admin.
The filter by confidentiality often picks a non-optimal query plan: for
instance, AND-ing the results of all issues in the project (a relatively small
set), and all issues in the states requested (a huge set), rather than just
starting small and winnowing further.
|
