| Age | Commit message (Collapse) | Author |
|---|
|
When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.
|
|
This commit fixes the error:
```
1) Admin::UsersController DELETE #user with projects deletes the user and their contributions when hard delete is specified
Failure/Error: Users::DestroyService.new(current_user).execute(delete_user, options.symbolize_keys)
NoMethodError:
undefined method `symbolize_keys' for "{\"hard_delete\"=>\"true\"}":String
# ./app/workers/delete_user_worker.rb:8:in `perform'
# ./lib/gitlab/sidekiq_status/server_middleware.rb:5:in `call'
# ./config/initializers/forbid_sidekiq_in_transactions.rb:35:in `block (2 levels) in <module:NoEnqueueingFromTransactions>'
# ./app/models/user.rb:913:in `delete_async'
# ./app/controllers/admin/users_controller.rb:148:in `destroy'
# ./lib/gitlab/i18n.rb:50:in `with_locale'
# ./lib/gitlab/i18n.rb:56:in `with_user_locale'
# ./app/controllers/application_controller.rb:327:in `set_locale'
# ./spec/controllers/admin/users_controller_spec.rb:28:in `block (3 levels) in <top (required)>'
Finished in 6.81 seconds (files took 13.9 seconds to load)
1 example, 1 failure
```
|
|
[Rails5] Fix `User#manageable_groups`
See merge request gitlab-org/gitlab-ce!18330
|
|
In `arel 7.0` (`7.1.4` version is used for rails5) there were introduced
some changes that break our code in the `User#manageable_groups` method.
The problem is that `arel_table[:id].in(Arel::Nodes::SqlLiteral)` generates
wrong `IN ()` construction. The selection for `IN` is missing:
=> "\"namespaces\".\"id\" IN (0)"
That caused such spec errors for the `rails5` branch:
```
4) User groups with child groups #manageable_groups does not include duplicates if a membership was added for the subgroup
Failure/Error: expect(user.manageable_groups).to contain_exactly(group, subgroup)
expected collection contained: [#<Group id:232 @group29>, #<Group id:234 @group29/group30>]
actual collection contained: []
the missing elements were: [#<Group id:232 @group29>, #<Group id:234 @group29/group30>]
# ./spec/models/user_spec.rb:699:in `block (5 levels) in <top (required)>'
# ./spec/spec_helper.rb:188:in `block (2 levels) in <top (required)>'
# /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:112:in `block in run'
# /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:101:in `loop'
# /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:101:in `run'
# /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
# /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:30:in `block (2 levels) in setup'
```
This commit changes `User#manageable_groups` in the way to drop the usage of
`Arel::Nodes::SqlLiteral` and adds usage of raw SQL query.
This change should be updated when we're migrated to Rails 5.2 because arel
was fixed in `9.0.0` (which is used in Rails 5.2).
|
|
This reverts the addition of the "goldiloader" Gem and all use of it.
While this Gem is very promising it's causing a variety of problems on
GitLab.com due to it eager-loading too much data in places where we
don't expect/can handle this. At least for the time being this means we
have to go back to manually fixing N+1 query problems, but at least
those should not cause a negative impact on availability.
|
|
'fix-n-plus-one-when-getting-notification-settings-for-recipients' into 'master'
Use Goldiloader for handling N+1 queries
See merge request gitlab-org/gitlab-ce!18217
|
|
Goldiloader is great, but has several issues with has_many :through relations:
* https://github.com/salsify/goldiloader/issues/12
* https://github.com/salsify/goldiloader/issues/14
* https://github.com/salsify/goldiloader/issues/18
Rather than try to figure out which applies in each case, we should just do the
drudge work of manually disabling autoloading for all relations of this type. We
can always use regular preloading for specific cases, but this way we avoid
generating invalid queries through Goldiloader's magic.
|
|
Goldiloader (https://github.com/salsify/goldiloader) can eager load
associations automatically. This removes the need for adding "includes"
calls in a variety of different places. This also comes with the added
benefit of not having to eager load data if it's not used.
|
|
|
|
projects to speed up query (#41981)
|
|
|
|
|
|
Closes #37462.
|
|
The merge request counter in the UI was not decreasing when a merge
request was deleting.
This was just due to the cache not being
refreshed on a delete action.
fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/44458
|
|
|
|
|
|
Ensure hooks run when a deploy key without a user pushes
Closes #44317
See merge request gitlab-org/gitlab-ce!18057
|
|
|
|
|
|
|
|
Improve database response time for listing user activity
Closes #40525
See merge request gitlab-org/gitlab-ce!17454
|
|
|
|
Closes #40525.
|
|
|
|
Moved o_auth/saml/ldap modules under gitlab/auth
See merge request gitlab-org/gitlab-ce!17359
|
|
|
|
Simplify filtering of non-human users.
Closes #43304
See merge request gitlab-org/gitlab-ce!17288
|
|
Note that `ghost IS NOT TRUE` is equivalent to `ghost = 'f' OR ghost is
null`:
(true), (false), (NULL)) AS t (flag);
flag | ?column? | ?column?
------+----------+----------
t | f | f
f | t | t
| t | t
(3 rows)
This makes it a little easier to create partial indexes for this (as only
one condition is needed).
Closes #43304.
|
|
This optimises searching for users when using queries consisting out of
one or two characters such as "ab". We optimise such cases by searching
for `LOWER(name)` and `LOWER(username)` instead of using `ILIKE`. Using
`LOWER` produces a _much_ better performing query.
For example, when searching for all users matching the term "a" we'd
produce the following plan:
Limit (cost=637.69..637.74 rows=20 width=805) (actual time=41.983..41.995 rows=20 loops=1)
Buffers: shared hit=8330
-> Sort (cost=637.69..638.61 rows=368 width=805) (actual time=41.982..41.990 rows=20 loops=1)
Sort Key: (CASE WHEN ((name)::text = 'a'::text) THEN 0 WHEN ((username)::text = 'a'::text) THEN 1 WHEN ((email)::text = 'a'::text) THEN 2 ELSE 3 END), name
Sort Method: top-N heapsort Memory: 35kB
Buffers: shared hit=8330
-> Bitmap Heap Scan on users (cost=75.47..627.89 rows=368 width=805) (actual time=9.452..41.305 rows=277 loops=1)
Recheck Cond: (((name)::text ~~* 'a'::text) OR ((username)::text ~~* 'a'::text) OR ((email)::text = 'a'::text))
Rows Removed by Index Recheck: 7601
Heap Blocks: exact=7636
Buffers: shared hit=8327
-> BitmapOr (cost=75.47..75.47 rows=368 width=0) (actual time=8.290..8.290 rows=0 loops=1)
Buffers: shared hit=691
-> Bitmap Index Scan on index_users_on_name_trigram (cost=0.00..38.85 rows=180 width=0) (actual time=4.369..4.369 rows=4071 loops=1)
Index Cond: ((name)::text ~~* 'a'::text)
Buffers: shared hit=360
-> Bitmap Index Scan on index_users_on_username_trigram (cost=0.00..34.41 rows=188 width=0) (actual time=3.896..3.896 rows=4140 loops=1)
Index Cond: ((username)::text ~~* 'a'::text)
Buffers: shared hit=328
-> Bitmap Index Scan on users_email_key (cost=0.00..1.94 rows=1 width=0) (actual time=0.022..0.022 rows=0 loops=1)
Index Cond: ((email)::text = 'a'::text)
Buffers: shared hit=3
Planning time: 3.912 ms
Execution time: 42.171 ms
With the changes in this commit we now produce the following plan
instead:
Limit (cost=13257.48..13257.53 rows=20 width=805) (actual time=1.567..1.579 rows=20 loops=1)
Buffers: shared hit=287
-> Sort (cost=13257.48..13280.93 rows=9379 width=805) (actual time=1.567..1.572 rows=20 loops=1)
Sort Key: (CASE WHEN ((name)::text = 'a'::text) THEN 0 WHEN ((username)::text = 'a'::text) THEN 1 WHEN ((email)::text = 'a'::text) THEN 2 ELSE 3 END), name
Sort Method: top-N heapsort Memory: 35kB
Buffers: shared hit=287
-> Bitmap Heap Scan on users (cost=135.66..13007.91 rows=9379 width=805) (actual time=0.194..1.107 rows=277 loops=1)
Recheck Cond: ((lower((name)::text) = 'a'::text) OR (lower((username)::text) = 'a'::text) OR ((email)::text = 'a'::text))
Heap Blocks: exact=277
Buffers: shared hit=287
-> BitmapOr (cost=135.66..135.66 rows=9379 width=0) (actual time=0.152..0.152 rows=0 loops=1)
Buffers: shared hit=10
-> Bitmap Index Scan on yorick_test_users (cost=0.00..124.75 rows=9377 width=0) (actual time=0.101..0.101 rows=277 loops=1)
Index Cond: (lower((name)::text) = 'a'::text)
Buffers: shared hit=4
-> Bitmap Index Scan on index_on_users_lower_username (cost=0.00..1.94 rows=1 width=0) (actual time=0.035..0.035 rows=1 loops=1)
Index Cond: (lower((username)::text) = 'a'::text)
Buffers: shared hit=3
-> Bitmap Index Scan on users_email_key (cost=0.00..1.94 rows=1 width=0) (actual time=0.014..0.014 rows=0 loops=1)
Index Cond: ((email)::text = 'a'::text)
Buffers: shared hit=3
Planning time: 0.303 ms
Execution time: 1.687 ms
Here we can see the new query is 25 times faster compared to the old
query.
|
|
With Geo, attempting to view an endpoint with a user could result in an
Error 500 since Devise attempts to update the last sign-in IP and other
details.
Closes gitlab-org/gitlab-ee#4972
|
|
As per the discussion with @psimyn, this change does not affect the frontend, so user input will not be validated on the signin screen.
Instead, the value sent to the backend has leading and trailing whitespace stripped before looking up the user with find_by.
Closes #42637
|
|
Add groups to OpenID Connect claims
See merge request gitlab-org/gitlab-ce!16929
|
|
|
|
|
|
|
|
|
|
Using correct column for sorting users by Recent Sign-in
Closes #26468
See merge request gitlab-org/gitlab-ce!13852
|
|
Removing last_sign_in_at in specs
|
|
Fixes #32282.
|
|
|
|
|
|
including/extending it
|
|
|
|
|
|
|
|
Given no search term, the `search` and `search_with_secondary_emails` methods will yield an empty result set
|
|
Closes #41633
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
This change is required because otherwise if a user is created with a
value for `projects_limit` that matches the DB default, it gets
overwritten by `current_application_settings.default_projects_limit`. By
removing the default we once again can allow a user to be created with a
limit of 10 projects without the risk that it'll change to 10000
|
