An error occurred fetching the project authors.
- 07 Jun, 2016 7 commits
-
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
Feedback from: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194552
-
Lin Jen-Shin authored
Feedback from: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194489
-
Lin Jen-Shin authored
Feedback from: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4404#note_12194471
-
Lin Jen-Shin authored
- 06 Jun, 2016 1 commit
-
-
Timothy Andrew authored
- To hold registrations from U2F devices, and to authenticate them. - Previously, `User#two_factor_enabled` was aliased to the `otp_required_for_login` column on `users`. - This commit changes things a bit: - `User#two_factor_enabled` is not a method anymore - `User#two_factor_enabled?` checks both the `otp_required_for_login` column, as well as `U2fRegistration`s - Change all instances of `User#two_factor_enabled` to `User#two_factor_enabled?` - Add the `u2f` gem, and implement registration/authentication at the model level.
-
- 28 May, 2016 1 commit
-
-
DJ Mountney authored
-
- 16 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 11 May, 2016 1 commit
-
-
Sean McGivern authored
-
- 10 May, 2016 2 commits
-
-
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.
-
Zeger-Jan van de Weg authored
-
- 09 May, 2016 1 commit
-
-
Jeroen van Baarsen authored
In 8278b763 the default behaviour of annotation has changes, which was causing a lot of noise in diffs. We decided in #17382 that it is better to get rid of the whole annotate gem, and instead let people look at schema.rb for the columns in a table. Fixes: #17382
-
- 31 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 15 Mar, 2016 1 commit
-
-
Rémy Coutable authored
This reverts commit 01160fc0, reversing changes made to 4bff9daf.
-
- 13 Mar, 2016 2 commits
-
-
Zeger-Jan van de Weg authored
Also incorporates the review into this, mainly spec changes.
-
Zeger-Jan van de Weg authored
The user has the rights of a public user execpt it can never create a project, group, or team. Also it cant view internal projects.
-
- 11 Mar, 2016 2 commits
-
-
Yorick Peterse authored
-
Yorick Peterse authored
-
- 29 Feb, 2016 2 commits
-
-
Robert Speicher authored
Closes #13905
-
Robert Speicher authored
Prior, if the user enabled 2FA, then disabled it and came back some time after the grace period expired, they would be forced to enable 2FA immediately.
-
- 24 Feb, 2016 1 commit
-
-
Robert Speicher authored
-
- 20 Feb, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 09 Feb, 2016 1 commit
-
-
Rémy Coutable authored
Also: - Get rid of legacy :strict_mode - Get rid of custom :email validator - Add some shared examples to spec emails validation
-
- 02 Feb, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 08 Jan, 2016 1 commit
-
-
Gabriel Mazetto authored
-
- 06 Jan, 2016 1 commit
-
-
Stan Hu authored
-
- 03 Jan, 2016 1 commit
-
-
Robert Speicher authored
Closes #201 - two-year-old bug, woo!
-
- 15 Dec, 2015 1 commit
-
-
Gabriel Mazetto authored
-
- 14 Dec, 2015 1 commit
-
-
Drew Blessing authored
-
- 09 Dec, 2015 2 commits
-
-
Douwe Maan authored
-
Stan Hu authored
-
- 07 Dec, 2015 1 commit
-
-
Robert Speicher authored
-
- 18 Nov, 2015 2 commits
-
-
Yorick Peterse authored
These methods no longer include public groups/projects (that don't belong to the actual user) as this is handled by the various finder classes now. This also removes the need for passing extra arguments. Note that memoizing was removed _explicitly_. For whatever reason doing so messes up the users controller to a point where it claims a certain user does _not_ have access to certain groups/projects when it does have access. Existing code shouldn't be affected as these methods are only called in ways that they'd run queries anyway (e.g. a combination of "any?" and "each" which would run 2 queries regardless of memoizing).
-
Yorick Peterse authored
This new setup no longer loads any IDs into memory using "pluck", instead using SQL UNIONs to merge the various datasets together. This results in greatly improved query performance as well as a reduction of memory usage. The old setup was in particular problematic when requesting the authorized projects _including_ public/internal projects as this would result in roughly 65000 project IDs being loaded into memory. These IDs would in turn be passed to other queries.
-
- 13 Nov, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 03 Nov, 2015 1 commit
-
-
Yorick Peterse authored
The descriptions were not accurate and one particular spec seemingly expected the wrong User row to be returned.
-
- 02 Oct, 2015 1 commit
-
-
Robert Speicher authored
[ci skip]
-