- 08 Feb, 2017 1 commit
-
-
Reza Mohammadi authored
Fixes #25279
-
- 07 Feb, 2017 1 commit
-
-
Douwe Maan authored
-
- 06 Feb, 2017 2 commits
-
-
Jose Ivan Vargas authored
-
Douwe Maan authored
-
- 25 Jan, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 24 Jan, 2017 1 commit
-
-
Poornima M authored
Adding changelog entry
-
- 08 Jan, 2017 1 commit
-
-
Yorick Peterse authored
This column used to be a 32 bits integer, allowing for only a maximum of 2 147 483 647 rows. Given enough users one can hit this limit pretty quickly, as was the case for GitLab.com. Changing this type to bigint (= 64 bits) would give us more space, but we'd eventually hit the same limit given enough users and projects. A much more sustainable solution is to simply drop the "id" column. There were only 2 lines of code depending on this column being present, and neither truly required it to be present. Instead the code now uses the "project_id" column combined with the "user_id" column. This means that instead of something like this: DELETE FROM project_authorizations WHERE user_id = X AND id = Y; We now run the following when removing rows: DELETE FROM project_authorizations WHERE user_id = X AND project_id = Y; Since both user_id and project_id are indexed this should not slow down the DELETE query. This commit also removes the "dependent: destroy" clause from the "project_authorizations" relation in the User and Project models. Keeping this prevents Rails from being able to remove data as it relies on an "id" column being present. Since the "project_authorizations" table has proper foreign keys set up (with cascading removals) we don't need to depend on any Rails logic.
-
- 03 Jan, 2017 2 commits
-
-
James Lopez authored
Also added relevant specs and refactored to_references in a bunch of places to be more consistent.
-
Drew Blessing authored
It's too easy to mistype an email or password when signing up. The support team is receiving an increasing number of requests because users mistype their email. We can eliminate this problem by requiring users to confirm the email before registering. The same issue can occur for the password field so we should add this, too. We should note that password confirmation is part of the default Devise forms. I don't know why/when GitLab removed it.
-
- 19 Dec, 2016 1 commit
-
-
Yorick Peterse authored
Prior to this commit the refreshing of authorized projects was done in two steps: 1. Remove existing authorizations 2. Insert a new list of all authorizations This can lead to a high amount of dead tuples as every time all rows are being replaced. For example, if a user with 100 authorizations is given access to a new project this would lead to: * 100 rows being removed * 101 new rows being inserted This commit changes the way this system works so it only removes/inserts what is necessary. Using the above example this would lead to only 1 new row being inserted, with the initial 100 being left untouched. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/25257
-
- 18 Dec, 2016 1 commit
-
-
Arsenev Vladislav authored
-
- 16 Dec, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Rydkin Maxim authored
-
- 13 Dec, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 01 Dec, 2016 1 commit
-
-
Andrew Smith authored
-
- 25 Nov, 2016 1 commit
-
-
Yorick Peterse authored
When I proposed using serializable transactions I was hoping we would be able to refresh data of individual users concurrently. Unfortunately upon closer inspection it was revealed this was not the case. This could result in a lot of queries failing due to serialization errors, overloading the database in the process (given enough workers trying to update the target table). To work around this we're now using a Redis lease that is cancelled upon completion. This ensures we can update the data of different users concurrently without overloading the database. The code will try to obtain the lease until it succeeds, waiting at least 1 second between retries. This is necessary as we may otherwise end up _not_ updating the data which is not an option.
-
- 23 Nov, 2016 3 commits
-
-
Yorick Peterse authored
Flushing the events cache worked by updating a recent number of rows in the "events" table. This has the result that on PostgreSQL a lot of dead tuples are produced on a regular basis. This in turn means that PostgreSQL will spend considerable amounts of time vacuuming this table. This in turn can lead to an increase of database load. For GitLab.com we measured the impact of not using events caching and found no measurable increase in response timings. Meanwhile not flushing the events cache lead to the "events" table having no more dead tuples as now rows are only inserted into this table. As a result of this we are hereby removing events caching as it does not appear to help and only increases database load. For more information see the following comment: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Ahmad Sherif authored
So that it matches the same access given in Projects::CreateService#after_create_actions
-
- 18 Nov, 2016 2 commits
-
-
Semyon Pupkov authored
-
Ahmad Sherif authored
Closes #23150
-
- 17 Nov, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Lin Jen-Shin authored
-
- 16 Nov, 2016 3 commits
-
-
Kamil Trzcinski authored
-
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.
-