| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Projects that have a pipeline may need to check whether the user has
permission to read the build (`can?(current_user, :read_build,
project)`), which requires checking the `project_features` table.
This would cause an N+1 SQL query for each project.
This change also has a beneficial side effect that may avoid a race
condition. When a user deletes a project, the project is queued for
deletion and the user is redirected back to the dashboard page. However,
the following may happen:
1. The dashboard page may load this deleted project in the list of
20 projects.
2. The view will load the project pipeline status from the cache and
attempt to show each project.
3. When the view encounters the deleted project, it calls
`can?(current_user, :read_build, project)` to determine whether to
display the pipeline status.
4. Sidekiq deletes the project from the database.
5. However, since the deleted project is still loaded in memory, it will
attempt to call `project.project_feature.access_level`.
6. Since `project_feature` was not eager loaded, a lazy `SELECT` call is
made to the database.
7. This `SELECT` call returns nothing, and the user sees a 500 error.
By eager loading `project_feature`, we can ensure that we have a
consistent view and avoid records from being deleted later.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66482
|
| |
|
|
|
|
|
| |
Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).
|
| | |
|
| |
|
|
|
| |
Check if we're gitlab.com and the
:user_onboarding feature flag is enabled.
|
| |
|
|
| |
- Render EE specific partial if exists
|
| |
|
|
|
| |
To make sure all known issues are linked to the correct epic, I've gone
through the code base, and updated the comments where required.
|
| |
|
|
|
|
| |
This mistake seems to have always been there, but it only resulted in
errors on the `/explore*.json` since they were the one that _actually_
relied on the local variables.
|
| |
|
|
|
|
| |
Allow developers to load GitLab root page locally without errors.
Since we know this issue for a while now, no point letting the exception
be triggered constantly.
|
| | |
|
| |
|
|
| |
This removes remaining N+1 queries
|
| |
|
|
|
| |
[master] Resolve "Personal access token with only `read_user` scope can be used to authenticate any web request"
See merge request gitlab/gitlabhq!2583
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enables frozen string for the following:
* app/controllers/dashboard/**/*.rb
* app/controllers/explore/**/*.rb
* app/controllers/google_api/**/*.rb
* app/controllers/groups/**/*.rb
* app/controllers/import/**/*.rb
* app/controllers/instance_statistics/**/*.rb
* app/controllers/ldap/**/*.rb
* app/controllers/oauth/**/*.rb
* app/controllers/profiles/**/*.rb
Partially addresses #47424.
|
| |
|
|
|
| |
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This solves an N+1 query problem where we'd run multiple queries when
getting the namespace owners of the displayed projects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes various controllers to use the new EventCollection class
for retrieving events. This class uses a JOIN LATERAL query on
PostgreSQL to retrieve queries in a more efficient way, while falling
back to a simpler / less efficient query for MySQL.
The EventCollection class also includes a limit on the number of events
to display to prevent malicious users from cycling through all events,
as doing so could put a lot of pressure on the database.
JOIN LATERAL is only supported on PostgreSQL starting with version 9.3.0
and as such this optimisation is only used when using PostgreSQL 9.3 or
newer.
|
| |
|
|
|
| |
This solves an N+1 query problem where for every project we'd query the
creator separately just to figure out what avatar to display.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extended ProjectFinder in order to handle the following options:
- current_user - which user use
- project_ids_relation: int[] - project ids to use
- params:
- trending: boolean
- non_public: boolean
- starred: boolean
- sort: string
- visibility_level: int
- tags: string[]
- personal: boolean
- search: string
- non_archived: boolean
GroupProjectsFinder now inherits from ProjectsFinder.
Changed the code in order to use the new available options.
|
| | |
|
| |
|
|
|
|
| |
Also, don't use limit in subquery, MySQL don't like that.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
| |
Dashboard::ProjectsController#index
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| |
|
|
|
|
| |
default""
This reverts commit 617bb1096deb1fb5dea66d04b9bbd7da0dfb57ba.
|
| |
|
|
| |
This reverts commit 70d6455284717f938016b1e1b569e0d0dadb11fc.
|
| |
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
