An error occurred fetching the project authors.
- 15 Dec, 2016 1 commit
-
-
James Lopez authored
-
- 14 Dec, 2016 2 commits
-
-
James Lopez authored
-
James Lopez authored
-
- 01 Dec, 2016 1 commit
-
-
Andrew Smith authored
-
- 30 Nov, 2016 1 commit
-
-
James Lopez authored
Refactored specs and added a post deployment migration to remove the activity users table.
-
- 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 4 commits
-
-
Gabriel Mazetto authored
-
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
-
- 22 Nov, 2016 1 commit
-
-
Gabriel Mazetto authored
-
- 19 Nov, 2016 1 commit
-
-
Alejandro Rodríguez authored
-
- 18 Nov, 2016 2 commits
-
-
Semyon Pupkov authored
-
Ahmad Sherif authored
Closes #23150
-
- 17 Nov, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Alejandro Rodríguez authored
-
- 16 Nov, 2016 2 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>
-
- 17 Oct, 2016 1 commit
-
-
James Lopez authored
It uses a user activity table instead of a column in users. Tested with mySQL and postgreSQL
-
- 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 2 commits
-
-
Robert Speicher authored
Refactor ability.rb into Policies Factors out `ability.rb` into a new abstraction - the "policy" (stored in `app/policies`). A policy is a class named `#{class_name}Policy` (looked up automatically as needed) that implements `rules` as follows: ``` ruby class ThingPolicy < BasePolicy def rules @user # this is a user to determine abilities for, optionally nil in the anonymous case @subject # this is the subject of the ability, guaranteed to be an instance of `Thing` can! :some_ability # grant the :some_ability permission cannot! :some_ability # ensure that :some_ability is not allowed. this overrides any `can!` that is called before or after delegate! @subject.other_thing # merge the abilities (can!) and prohibitions (cannot!) from `@subject.other_thing` can? :some_ability # test whether, so far, :some_ability is allowed end def anonymous_rules # optional. if not implemented `rules` is called where `@user` is nil. otherwise this method is called when `@user` is nil. end end ``` See merge request !5796
-
Felipe Artur authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 24 Aug, 2016 1 commit
-
-
Paco Guzman authored
-
- 20 Aug, 2016 2 commits
-
-
Douwe Maan authored
Restrict pushes / merges to a protected branch to specific people - Closes #674 - Related to #179    - [ ] ee#674 !581 Restrict merges to specific people - [x] Implementation - [x] Model changes - [x] Protected branch `has_many` access levels - [x] Frontend - [x] How to add new users / roles? - [x] Dropdown should include users - [x] Dropdown shouldn't include users / roles that have already been selected - [x] Allow removing users / roles - [x] Removing a user from the project should remove their access (?) - [x] Test/refactor - [x] Extract common from {Merge,Push}AccessLevel models - [x] Clean up code that's removing users/roles that are already selected - [x] AccessLevelController? - [x] Fix build - [x] Add more tests - [x] Non `:push_code` users can't push even if added to an access level - [x] Remove access levels when a user is removed from a project - [x] Rebase off EE master instead of the "no one can push" feature branch - [x] Fix create for roles - [x] Fix update for roles - [x] Fix delete - [x] Fix create for users - [x] Fix update for users - [x] Fix defaults - [x] Verify - [x] API - [x] For a developer user - [x] When they are granted access specifically to - [x] Merge - [x] Push - [x] For a reporter user - [x] When they are granted access specifically to - [x] Merge - [x] Push - [x] Default branch protection - [x] CHANGELOG - [x] Screenshots - [x] Only show `:push_code` users in the dropdown - [x] Send email when user is added/removed from a protected branch - [x] Assign to {mini,end}boss - [x] Fix build - [x] Implement @dbalexandre's review comments - [x] EE should _add_ to CE - [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ee/commit/61edf43d31452a0b972dc880e277c825d59f764f/builds) to pass - [x] Test by hand - [x] Assign to endboss - [x] Create CE MR to backport changes - [x] Implement @Douwe's comments - [x] access_level#humanize - [x] Blank line in _protected_branch.html.haml - [x] move stuff into shared partials? (_protected_branch_ee.html.haml) - [x] Can we move stuff into shared partials? (_create_protected_branch_ee.html.haml) - [x] The CE version has a bunch of extra attributes here, do we need those? - [x] We can't indent this section just in EE (protected_branches/show.html.haml) - [x] In EE, try not to add stuff to existing views. (protected_branches/show.html.haml) - [x] If we're gonna change multiline blocks to single-line blocks, we need to so in CE too. (factory) - [x] Split up `ProtectedBranches#show` - [x] Wait for [build](https://gitlab.com/gitlab-org/gitlab-ee/commit/3943254d5f92c9be520f685044d23bf75282d42a/builds) - [x] Implement Douwe's suggestions - [x] Add uniqueness validation - [x] Wait for @alfredo's UI enhancements - [x] Remove `show` page access controls - [x] Add more feature specs - [ ] Wait for review for @alfredo's work - [ ] Wait for merge See merge request !581
-
Timothy Andrew authored
- A protected branch now `has_many` access levels (as opposed to `has_one`, which CE will continue to have). Each access level represents either a user or a role that is allowed to access the protected branch. - Update `git_access_spec` to test cases where a specific user is given access to a protected branch. - Remove the explicit `push_check` for protected branches. This is because a non-developer user (such as a reporter) should be able to push code if they are added to a protected branch specifically. - Fix specs (git_access_spec) that were implicitly depending on a master push access level being created (previously, a protected branch's default state was "masters can push + masters can merge"). Since the current default is "none", the dependency needs to be explicitly declared. - Update `git_push_service` so default branch protection (for new repos) works as expected.
-
- 17 Aug, 2016 1 commit
-
-
Yorick Peterse authored
Move to project dropdown with infinite scroll for better performance See merge request !5828
-