Allow account unlock via email
We see a lot of users get confused about what it means when your account gets
locked. Many try to reset their password and are still faced with a lockout.
With this change, users receive an email that allows them to unlock their
account immediately. The previous behavior where the account is auto-unlocked
after a time also still works.
See merge request !2049
* master: (66 commits)
Fix runners admin view
Fix migrations
Rename mention of gitlab-git-http-server to gitlab-workhorse
Bump Redis requirement to 2.8 for Sidekiq 4 requirements
Fix wording on runner setup page
add details on how to change saml button label
Fix tests
Move awards back to gray panel and few improvements to sidebar
Few UI improvements to new sidebar implementation
Fix tests for new issuable sidebar
Update changelog
Implement new sidebar for merge request page
Make edit link on issuable sidebar works
Redesign issue page for new sidebar
Move awards css to separate file
Implement issuable sidebar partial
Update CHANGELOG
Clarify cache behavior
Run builds from projects with enabled CI
Use Gitlab::Git instead of Ci::Git
...
Conflicts:
db/schema.rb
This adds a ability to use multiple different authentication token
fields in other models. From now on it is necessary to add
authentication token field manually in each class that implements this
mixin.
These methods no longer include public groups/projects (that don't
belong to the actual user) as this is handled by the various finder
classes now. This also removes the need for passing extra arguments.
Note that memoizing was removed _explicitly_. For whatever reason doing
so messes up the users controller to a point where it claims a certain
user does _not_ have access to certain groups/projects when it does have
access. Existing code shouldn't be affected as these methods are only
called in ways that they'd run queries anyway (e.g. a combination of
"any?" and "each" which would run 2 queries regardless of memoizing).
This new setup no longer loads any IDs into memory using "pluck",
instead using SQL UNIONs to merge the various datasets together. This
results in greatly improved query performance as well as a reduction of
memory usage.
The old setup was in particular problematic when requesting the
authorized projects _including_ public/internal projects as this would
result in roughly 65000 project IDs being loaded into memory. These IDs
would in turn be passed to other queries.
This allows retrieving of the list of authorized projects using a single
query, without having to load any IDs into Ruby. This in turn also means
we can remove the method User#authorized_projects_id.
This further improves performance of User.find_by_any_email and is
roughly twice as fast as the previous UNION setup.
Thanks again to @dlemstra for suggesting this.
This is significantly faster than using a sub-query, at least when run
on the GitLab.com production database. The benchmarks are a lot slower
now with these changes, most likely due to PostgreSQL choosing a
different (and less efficient) plan based on the amount of data present
in the test database.
Thanks to @dlemstra for suggesting the use of a UNION.
This query used to rely on a JOIN, effectively producing the following
SQL:
SELECT users.*
FROM users
LEFT OUTER JOIN emails ON emails.user_id = users.id
WHERE (users.email = X OR emails.email = X)
LIMIT 1;
The use of a JOIN means having to scan over all Emails and users, join
them together and then filter out the rows that don't match the criteria
(though this step may be taken into account already when joining).
In the new setup this query instead uses a sub-query, producing the
following SQL:
SELECT *
FROM users
WHERE id IN (select user_id FROM emails WHERE email = X)
OR email = X
LIMIT 1;
This query has the benefit that it:
1. Doesn't have to JOIN any rows
2. Only has to operate on a relatively small set of rows from the
"emails" table.
Since most users will only have a handful of Emails associated
(certainly not hundreds or even thousands) the size of the set returned
by the sub-query is small enough that it should not become problematic.
Performance of the old versus new version can be measured using the
following benchmark:
# Save this in ./bench.rb
require 'benchmark/ips'
email = 'yorick@gitlab.com'
def User.find_by_any_email_old(email)
user_table = arel_table
email_table = Email.arel_table
query = user_table.
project(user_table[Arel.star]).
join(email_table, Arel::Nodes::OuterJoin).
on(user_table[:id].eq(email_table[:user_id])).
where(user_table[:email].eq(email).or(email_table[:email].eq(email)))
find_by_sql(query.to_sql).first
end
Benchmark.ips do |bench|
bench.report 'original' do
User.find_by_any_email_old(email)
end
bench.report 'optimized' do
User.find_by_any_email(email)
end
bench.compare!
end
Running this locally using "bundle exec rails r bench.rb" produces the
following output:
Calculating -------------------------------------
original 1.000 i/100ms
optimized 93.000 i/100ms
-------------------------------------------------
original 11.103 (± 0.0%) i/s - 56.000
optimized 948.713 (± 5.3%) i/s - 4.743k
Comparison:
optimized: 948.7 i/s
original: 11.1 i/s - 85.45x slower
In other words, the new setup is 85x faster compared to the old setup,
at least when running this benchmark locally.
For GitLab.com these improvements result in User.find_by_any_email
taking only ~170 ms to run, instead of around 800 ms. While this is
"only" an improvement of about 4.5 times (instead of 85x) it's still
significantly better than before.
Fixes#3242
Allow users to select the Files view as default project view
Also shows the readme at the very bottom, like on the regular Files page.
Replaces !1489.
Closes#2655.
See merge request !1632
The counter_cache decrement function is called when a project star is deleted,
but there was no guarantee multiple workers would not attempt to delete the
same item simultaneously. Use an atomic update to prevent the count from going negative.
Closes#3067
Performance is improved in two steps:
1. On PostgreSQL an expression index is used for checking lower(email)
and lower(username).
2. The check to determine if we're searching for a username or Email is
moved to Ruby. Thanks to @haynes for suggesting and writing the
initial implementation of this.
Moving the check to Ruby makes this method an additional 1.5 times
faster compared to doing the check in the SQL query.
With performance being improved I've now also tweaked the amount of
iterations required by the User.by_login benchmark. This method now runs
between 900 and 1000 iterations per second.
Rémy Coutable
Douglas Barbosa Alexandre
Stan HuandDouglas Barbosa Alexandre
Douwe Maan
Gabriel Mazetto
Robert Speicher
Robert Speicher
Drew Blessing
Grzegorz Bizon
Kamil Trzcinski
Valery Sizov
Valery Sizov
Yorick Peterse
Dmitriy Zaporozhets
Jan-Gerd Tenberge
Peter Göbel
Guilherme Garnier