Migrations shouldn't fail RuboCop checks - especially lint checks, such
as the nested method check. To avoid changing code in existing
migrations, add the magic comment to the top of each of them to skip
that file.
Add a new application setting, after_sign_up_text. This is text to be
rendered as Markdown and shown on the 'almost there' page after a user
signs up, but before they've confirmed their account.
Tweak the styles for that page so that centered lists look reasonable.
This improves performance of the duplicate notification settings
migration by removing duplicates in batches instead of using one big
"DELETE FROM" query.
The previous query would locally run over 45 minutes without even
finishing. This new setup finished in a matter of seconds.
Fixes#18289
- To hold registrations from U2F devices, and to authenticate them.
- Previously, `User#two_factor_enabled` was aliased to the
`otp_required_for_login` column on `users`.
- This commit changes things a bit:
- `User#two_factor_enabled` is not a method anymore
- `User#two_factor_enabled?` checks both the
`otp_required_for_login` column, as well as `U2fRegistration`s
- Change all instances of `User#two_factor_enabled` to
`User#two_factor_enabled?`
- Add the `u2f` gem, and implement registration/authentication at the
model level.
Remove project notification settings associated with deleted projects
On GitLab.com, there are 1560 project notification settings with no valid project all created on 2016-04-15 10:38:53 for some reason. This migration should purge
those entries.
b8f38437 should prevent this issue from occurring in the first place.
Closesgitlab-com/support-forum#678
See merge request !4311
On GitLab.com, there are 1560 project notification settings with no valid project
all created on 2016-04-15 10:38:53 for some reason. This migration should purge
those entries.
b8f38437 should prevent this issue from occurring in the first place.
Closesgitlab-com/support-forum#678
Added authentication service for docker registry
This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.
I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?
What do you think @jacobvosmaer @sytses @marin?
cc @marin
See merge request !3787