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.
Attempting to use the /projects/:id API by specifying :id in
"namespace/project" format would always result in a 404 if the namespace
contained a dot.
The reason? From http://guides.rubyonrails.org/routing.html#specifying-constraints:
"By default the :id parameter doesn't accept dots - this is because the dot is
used as a separator for formatted routes. If you need to use a dot within an
:id add a constraint which overrides this - for example id: /[^\/]+/ allows
anything except a slash."
Closes https://github.com/gitlabhq/gitlabhq/issues/9573
This was previously possible through the API but can now be done
through the project#edit settings screen if the current user is
the owner of the project.
Update changelog
Added support for order_by and sort parameters, to sort the projects by the specified values.
Updated projects api documentation including the order_by and sort parameters
Update the project API controller to use `Projects::DestroyService`
instead of calling `Project#destroy` directly.
Also add an optional parameter, `:keep_repo`, that allows a project to
be deleted without deleting the repository, wiki, and satellite from
disk.
This change adds POST /projects/fork/:id to the API for forking
a project into the namespace of the authenticated user, like the
"create fork" link in the GUI does. It also calls the same code.
Failure and permission checks (except for conflict) are already
implemented and handled in ForkService and the API, so the added
code is simple and does not alter anything.
* users (#6878, #3526, #4209): Validation error messages are now exposed through 400 responses, 409 response are sent in case of duplicate email or username
* MRs (#5335): 409 responses are sent in case of duplicate merge request (source/target branches), 422 responses are sent when submiting MR fo/from unrelated forks
* issues
* labels
* projects
Let users limit by archived/not archived projects in GitLab API GET /projects
Adds a boolean parameter, archived, to the /projects endpoint.
See merge request !158
To prevent leaking of users info we reduce amount of user information
retrieved via API for normal users.
What user can get via API:
* if not admin: only id, state, name, username and avatar_url
* if admin: all user information
* about himself: all informaion
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Added visibility_level icons to project view (rather than just text).
Added public projects to search results.
Added ability to restrict visibility levels standard users can set.
This allows you to set the namespace ID for projects via the the API. By default it is created for the current user. You can assign it to the global namespace by passing `GLN` which translates to 'Global Namespace'.
Added a helper method to check if required parameters are given in an API call. Can be used
to return a `400 Bad Request` return code if a required attribute is missing.
Code clean up and fixed tests.
The API documentation of repository is updated and now contains infos to status codes.
Code documentation is also adjusted for `GET /projects/:id/repository/commits` and includes infos to
pagination attributes. Tests are updated.
When a user is not authorized to see the list of hooks for a project, he is
still able to access the hooks separately. For example if access to
`GET /projects/:id/hooks` fails and returns a `403 Unauthorized` error it is
still possible to access a hook directly via `GET /projects/:id/hooks/:hook_id`.
Fixes access, also added tests to check access and status codes of hooks.
When the project limit is reached the user is not allowed to create new ones.
Instead of error code 404 the status code 403 (Forbidden) is returned with error
message via API.
Extracted a method for 400 error (Bad request) and adjusted code accordingly. The name of
the missing attribute is used to show which one was missing from the request. It is used to
give an appropriate message in the json response.
When using project snippets via API the functions now provide status codes for
different situations other then only returning 404 error. If required parameters are missing,
e.g. `title` when creating a project snippet a 400 (Bad request) error is returned. The snippet
delete function now is idempotent and returns a 200 (Ok) regardless if the snippet with the
given id is available or not. Changing return codes of these functions has the advantage that
the 404 error is used only for resources, which are not available.
Tests added to check these status codes when handling project snippets.
Different status codes in the API lib are returned on hook creation, update or deletion.
If a required parameter is not given (e.g. `url` in `/projects/:id/hooks/:hook_id`) status
code 400 (Bad request) is returned. On hook deletion a 200 status code is returned, regardless if
the hook is present or not. This makes the DELETE function an idempotent operation. Appropriate tests
are added to check these status codes.
When adding a project hook a url must be specified or a 400 error code is returned
* Specs added to check status code on handling project hooks
* refactored code, extracted a method
When a user is added to a project that is already a member of, a status code 201 is now returned to
signal an idempotent operation. If something fails then instead of returning error code 404 different
more specific error codes are returned. Status code 400 (Bad request) is returned when a required
attribute, e.g. `access_level` is not given or 422 if there is a semantic error, e.g. should
the `access_level` have an unsupported value.
Specs are added to check these status codes.
The attempt to revoke project access for a user that was not member of the
project results in a 500 Internal Server error where it actually should
result in a 200 OK since after the operation, the user is not member of
the project. This turns the operation into an idempotent call that can
be repeated with no ill effects.
Updated the spec and changed the code accordingly. However, the result differs
slightly, as we can't return the users project access level if the user was not
member. I'm not aware if anybody relies on the result of this call.
Fixes#2832
Patricio Cano
Marc Dequènes (Duck)
Stan Hu
Robert Schilling
tiagonbotelho
Grzegorz Bizon
Kamil Trzcinski
Sean McGivern
Zeger-Jan van de Weg
Dmitriy Zaporozhets
Josh Frye
Douwe Maan
Tomasz Maczukin
Zeger-Jan van de Weg
Han Loong Liauw
Valery Sizov
Stephan van Leeuwen
Vinnie Okada
Mika Mäenpää
Jeroen van Baarsen
Marin Jankovski
Ciro Santilli
Bernhard Kaindl
jubianchi
Sasha Joseph
Nihad Abbasov
Ábner Silva de Oliveira
skv
Maxime Brugidou
Jason Hollingsworth
Izaak Alpert
Angus MacArthur
Drew Blessing
babatakao
Andrew8xx8
Alex Denisov
Sebastian Ziebell
Matt Humphrey
Angus MacArthur
Felix Gilcher
GitLab
Riyad Preukschas
Saito
jozefvaclavik
Dmitriy Zaporozhets
miks
Robert Speicher
Jeremy Anderson