This adds counters for build artifacts and LFS objects, and moves
the preexisting repository_size and commit_count from the projects
table into a new project_statistics table.
The counters are displayed in the administration area for projects
and groups, and also available through the API for admins (on */all)
and normal users (on */owned)
The statistics are updated through ProjectCacheWorker, which can now
do more granular updates with the new :statistics argument.
API: Share projects only with groups current_user can access
Aims to address the issues here: https://gitlab.com/gitlab-org/gitlab-ce/issues/23004
* Projects can be shared with non-existent groups
* Projects can be shared with groups that the current user does not have access to read
Concerns:
The new implementation of the API endpoint allows projects to be shared with a larger range of groups than can be done via the web UI.
The form for sharing a project with a group uses the following API endpoint to index the available groups: 494269fc92/lib/api/groups.rb (L17). The groups indexed in the web form will only be those groups that the user is currently a member of.
The new implementation allows projects to be shared with any group that the authenticated user has access to view. This widens the range of groups to those that are public and internal.
See merge request !2005
Signed-off-by: Rémy Coutable <remy@rymai.me>
Also streamline the sorting part while we're at it.
That being done, there's currently a duplication between
`GET /projects/search/:query` and `GET /projects?search=:search`
so we might want to keep only the latter for 9.0...
Signed-off-by: Rémy Coutable <remy@rymai.me>
Browser interface allows forking to an owned grup.
This commit brings API up to speed by providing optional namespace
parameter to fork API. This allows forking to users and groups under
forker's control using their id or unique name.
Fixes#21591
Instead of redirecting from the project service to the service and back to the model,
put all destruction code in the service. Also removes a possible source of failure
where run_after_commit may not destroy the project.
`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.