- 11 Oct, 2016 1 commit
-
-
Rémy Coutable authored
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: https://gitlab.com/gitlab-org/gitlab-ce/blob/494269fc92f61098ee6bd635a0426129ce2c5456/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>
-
- 10 Oct, 2016 1 commit
-
-
Rémy Coutable authored
From 8.15s to 4.55s by grouping expectations Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 07 Oct, 2016 1 commit
-
-
Nick Thomas authored
This commit adds a number of _html columns and, with the exception of Note, starts updating them whenever the content of their partner fields changes. Note has a collision with the note_html attr_accessor; that will be fixed later A background worker for clearing these cache columns is also introduced - use `rake cache:clear` to set it off. You can clear the database or Redis caches separately by running `rake cache:clear:db` or `rake cache:clear:redis`, respectively.
-
- 04 Oct, 2016 2 commits
-
-
Sean McGivern authored
-
Ben Boeckel authored
FIxes #19361, #3119.
-
- 28 Sep, 2016 1 commit
-
-
Felipe Artur authored
-
- 19 Sep, 2016 1 commit
-
-
Felipe Artur authored
-
- 01 Sep, 2016 1 commit
-
-
Felipe Artur authored
-
- 24 Aug, 2016 1 commit
-
-
Marc Dequènes (Duck) authored
-
- 09 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 04 Aug, 2016 1 commit
-
-
Z.J. van de Weg authored
Also, fix the failing test in the process
-
- 20 Jul, 2016 1 commit
-
-
Alejandro Rodríguez authored
Also, in favour of consistency, deprecate `/projects/:id/keys/...` routes in favour of `/projects/:id/deploy_keys/...`
-
- 19 Jul, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 13 Jul, 2016 1 commit
-
-
tiagonbotelho authored
-
- 12 Jul, 2016 4 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 11 Jul, 2016 2 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 08 Jul, 2016 1 commit
-
-
Robert Schilling authored
-
- 01 Jul, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 29 Jun, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 27 Jun, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 13 Jun, 2016 1 commit
-
-
Felipe Artur authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 10 May, 2016 1 commit
-
-
Sean McGivern authored
`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.
-
- 25 Apr, 2016 1 commit
-
-
Stan Hu authored
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15580
-
- 13 Apr, 2016 3 commits
-
-
Robert Schilling authored
-
Robert Schilling authored
-
Robert Schilling authored
-
- 24 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
Also the specs have a minor improvement. Mainly the access right spec. Changes are reflected in the docs
-
- 23 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 19 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 13 Mar, 2016 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 06 Mar, 2016 1 commit
-
-
Robert Speicher authored
-
- 19 Jan, 2016 1 commit
-
-
Josh Frye authored
-
- 07 Jan, 2016 1 commit
-
-
Douwe Maan authored
-
- 03 Jan, 2016 1 commit
-
-
Stan Hu authored
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
-