An error occurred fetching the project authors.
- 20 Apr, 2017 1 commit
-
-
Valery Sizov authored
-
- 19 Apr, 2017 1 commit
-
-
James Lopez authored
-
- 18 Apr, 2017 1 commit
-
-
Valery Sizov authored
-
- 14 Apr, 2017 5 commits
-
-
Sean McGivern authored
-
Sean McGivern authored
-
Sean McGivern authored
CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/962
-
James Lopez authored
Refactored specs and added a post deployment migration to remove the activity users table.
-
James Lopez authored
It uses a user activity table instead of a column in users. Tested with mySQL and postgreSQL
-
- 11 Apr, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 10 Apr, 2017 1 commit
-
-
Robert Speicher authored
-
- 09 Apr, 2017 1 commit
-
-
blackst0ne authored
-
- 06 Apr, 2017 6 commits
-
-
Timothy Andrew authored
1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep things explicit. Specs testing the behavior of this class are moved into a separate service spec file. 2. Add a `user.reported_abuse_reports` association to make the `migrate_abuse_reports` method more consistent with the other `migrate_` methods.
-
Timothy Andrew authored
Introduction ------------ 1. The foreign key was not explicitly specified on the association. 2. The `AbuseReport` model contains two references to user - `reporter_id` and `user_id` 3. `user.abuse_report` is supposed to return the single abuse report where `user_id` refers to the given user. Bug Description --------------- 1. `user.abuse_report` would return an abuse report where `reporter_id` referred to the current user, if such an abuse report was present. 2. This implies a slightly more serious bug as well: - Assume User A filed an abuse report against User B - We have an abuse report where `reporter_id` is User A and `user_id` is User B - If User A is updated (`user_a.block`, for example), the abuse report would also be updated, such that both `reporter_id` _and_ `user_id` point to User A. Fix --- Explicitly declare the foreign key `user_id` in the `has_one` declaration
-
Alexis Reigel authored
-
Alexis Reigel authored
-
Alexis Reigel authored
-
Markus Koller authored
-
- 30 Mar, 2017 2 commits
-
-
mhasbini authored
-
Fabio Huser authored
-
- 27 Mar, 2017 1 commit
-
-
George Andrinopoulos authored
-
- 24 Mar, 2017 2 commits
-
-
Stan Hu authored
-
Alexander Randa authored
-
- 22 Mar, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 17 Mar, 2017 1 commit
-
-
Kamil Trzciński authored
-
- 10 Mar, 2017 1 commit
-
-
http://jneen.net/ authored
-
- 09 Mar, 2017 5 commits
-
-
http://jneen.net/ authored
-
http://jneen.net/ authored
-
http://jneen.net/ authored
since they can't log in
-
http://jneen.net/ authored
-
http://jneen.net/ authored
to make sure we mean the global permissions
-
- 06 Mar, 2017 2 commits
-
-
Robert Speicher authored
-
Tiago Botelho authored
-
- 05 Mar, 2017 1 commit
-
-
Kamil Trzcinski authored
-
- 03 Mar, 2017 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 28 Feb, 2017 3 commits
-
-
http://jneen.net/ authored
-
http://jneen.net/ authored
Since we will likely be needing this for other features, for example the Gitlab ServiceDesk support bot.
-
Douwe Maan authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 24 Feb, 2017 3 commits
-
-
Timothy Andrew authored
- Add a `destroy_user` ability. This didn't exist before, and was implicit in other abilities (only admins could access the admin area, so only they could destroy all users; a user can only access their own account page, and so can destroy only themselves). - Grant this ability to admins, and when the current user is trying to destroy themselves. Disallow destroying ghost users in all cases. - Modify the `Users::DestroyService` to check this ability. Also check it in views to decide whether or not to show the "Delete User" button. - Add a short summary of the Ghost User to the bio.
-
Timothy Andrew authored
- Have `Uniquify` take a block instead of a Proc/function. This is more idiomatic than passing around a function in Ruby. - Block a user before moving their issues to the ghost user. This avoids a data race where an issue is created after the issues are migrated to the ghost user, and before the destroy takes place. - No need to migrate issues (to the ghost user) in a transaction, because we're using `update_all` - Other minor changes
-
Timothy Andrew authored
1. Refactoring and specs in the `Uniquify` class. 2. Don't use the `AdvisoryLocking` class. Similar functionality is provided (backed by Redis) in the `ExclusiveLease` class.
-