An error occurred fetching the project authors.
- 17 Nov, 2016 1 commit
-
-
Lin Jen-Shin authored
-
- 16 Nov, 2016 2 commits
-
-
Ben Bodenmiller authored
- 07 Nov, 2016 3 commits
-
-
tiagonbotelho authored
reactivates all tests and writes more tests for it
-
Douwe Maan authored
email token be reset
-
Yorick Peterse authored
This method can be used to retrieve a list of projects for a user that said user has reporter access to. This list is then be reduced down to a specific set of projects. This allows you to reduce a list of projects to a list of projects you have reporter access to in an efficient manner.
-
- 04 Nov, 2016 1 commit
-
-
Valery Sizov authored
-
- 01 Nov, 2016 1 commit
-
-
Yar authored
It is not possible to search for a user by his secondary email address in the Users search bar in the admin interface(/admin/users). A use-case could be that an admin wants to remove a specific secondary email address of an user, because it interferes with another user. Issue #23761 This commit adds ability to search not only by main email, but also by any secondary email in the admin interface.
-
- 27 Oct, 2016 1 commit
-
-
Steve Halasz authored
If notification_email is blank, it's set from email. If an admin attempted to create a user with an invalid email, an error would be displayed for both fields. Only validate the notification_email if it's different from email.
-
- 25 Oct, 2016 1 commit
-
-
Timothy Andrew authored
1. Changes in 8.13 require `Referable`s that don't have a project reference to accept two arguments - `from_project` and `target_project`. 2. `User#to_reference` was not changed to accept the `target_project` (even though it is not used). Moving an issue containing a user reference would throw a "invalid number of arguments" exception. Fixes #23662
-
- 24 Oct, 2016 1 commit
-
-
David Wagner authored
They were Rails' default and are unnecessarily overridden. Signed-off-by: David Wagner <david@marvid.fr>
-
- 11 Oct, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 07 Oct, 2016 1 commit
-
-
dev-chris authored
+ Don't expose all whitelisted domains
-
- 05 Oct, 2016 1 commit
-
-
Yorick Peterse authored
This refactors Gitlab::Identifier so it uses fewer queries and is actually tested. Queries are reduced by caching the output as well as using 1 query (instead of 2) to find a user using an SSH key.
-
- 04 Oct, 2016 1 commit
-
-
Sean McGivern authored
Copy logic from `Devise::Models::Lockable#valid_for_authentication?`, as our custom login flow with two pages doesn't call this method. This will increment the failed login counter, and lock the user's account once they exceed the number of failed attempts. Also ensure that users who are locked can't continue to submit 2FA codes.
-
- 15 Sep, 2016 2 commits
-
-
Patricio Cano authored
-
Patricio Cano authored
- Required on the GitLab Rails side is mostly authentication and API related.
-
- 01 Sep, 2016 1 commit
-
-
Felipe Artur authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 24 Aug, 2016 1 commit
-
-
Paco Guzman authored
-
- 17 Aug, 2016 1 commit
-
-
Paco Guzman authored
Use just SQL to check is a user can admin_issue on a project Tradeoff - we duplicate how we check admin_issue in a SQL relation in the Ability class
-
- 12 Aug, 2016 1 commit
-
-
Paco Guzman authored
-
- 04 Aug, 2016 1 commit
-
-
Adam Niedzielski authored
-
- 03 Aug, 2016 1 commit
-
-
Sean McGivern authored
.secret stores the secret token used for both encrypting login cookies and for encrypting stored OTP secrets. We can't rotate this, because that would invalidate all existing OTP secrets. If the secret token is present in the .secret file or an environment variable, save it as otp_key_base in secrets.yml. Now .secret can be rotated without invalidating OTP secrets. If the secret token isn't present (initial setup), then just generate a separate otp_key_base and save in secrets.yml. Update the docs to reflect that secrets.yml needs to be retained past upgrades, but .secret doesn't.
-
- 01 Aug, 2016 1 commit
-
-
Adam Niedzielski authored
-
- 20 Jul, 2016 1 commit
-
-
Alejandro Rodríguez authored
Currently, even when searching for all authorized issues of *one* project, we run the `Users#authorized_projects` query (which can be rather slow). This update checks if we are handling issues of just one project and does the authorization check locally. It does have the downside of basically repeating the logic of `Users#authorized_projects` on `Project#authorized_for_user`.
-
- 19 Jul, 2016 1 commit
-
-
Robert Speicher authored
Prior, when providing a `min_access_level` parameter to this method, we called `Gitlab::Access.values` instead of `all_values`, mistakenly omitting the `OWNER` level. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19878
-
- 18 Jul, 2016 5 commits
-
-
Patricio Cano authored
-
Patricio Cano authored
Refactor and rename `restricted_signup_domains` to `domain_whitelist` to better conform to its behavior and newly introduced behavior.
-
Patricio Cano authored
-
Patricio Cano authored
-
Patricio Cano authored
-
- 15 Jul, 2016 1 commit
-
-
Kamil Trzcinski authored
-
- 12 Jul, 2016 1 commit
-
-
Sean McGivern authored
-
- 07 Jul, 2016 1 commit
-
-
Dravere authored
As requested by the issue #14508 this adds an option in the application settings to set newly registered users by default as external. The default setting is set to false to stay backward compatible.
-
- 05 Jul, 2016 1 commit
-
-
Robert Speicher authored
`avatar.present?` goes through CarrierWave, and checks that the file exists on disk and checks its filesize. Because we're hitting the disk, this adds extra overhead to something where the worst-case scenario is rendering a broken image. Instead, we now just check that the _database attribute_ is present, which is good enough for our purposes. See https://gitlab.com/gitlab-org/gitlab-ce/issues/19273
-
- 01 Jul, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 29 Jun, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 28 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 24 Jun, 2016 1 commit
-
-
Rémy Coutable authored
The issue was with the `User#groups` and `User#projects` associations which goes through the `User#group_members` and `User#project_members`. Initially I chose to use a secure approach by storing the requester's user ID in `Member#created_by_id` instead of `Member#user_id` because I was aware that there was a security risk since I didn't know the codebase well enough. Then during the review, we decided to change that and directly store the requester's user ID into `Member#user_id` (for the sake of simplifying the code I believe), meaning that every `group_members` / `project_members` association would include the requesters by default... My bad for not checking that all the `group_members` / `project_members` associations and the ones that go through them (e.g. `Group#users` and `Project#users`) were made safe with the `where(requested_at: nil)` / `where(members: { requested_at: nil })` scopes. Now they are all secure. Signed-off-by: Rémy Coutable <remy@rymai.me>
-