Commit graph

8 commits

Author SHA1 Message Date
GitLab Bot
564919dfc6 Add latest changes from gitlab-org/gitlab@master 2021-08-11 09:10:00 +00:00
GitLab Bot
c59765a50a Add latest changes from gitlab-org/gitlab@master 2020-06-24 18:09:03 +00:00
GitLab Bot
18a102a5b9 Add latest changes from gitlab-org/gitlab@master 2019-11-08 03:06:48 +00:00
Lin Jen-Shin
7ce990b161 Move some application setting examples to be shared 2019-03-19 13:01:37 +08:00
Lin Jen-Shin
7067806634 Add a few tests for fake applications 2019-03-19 13:01:37 +08:00
Markus Koller
257fd57134 Allow password authentication to be disabled entirely 2017-11-23 13:16:14 +00:00
Robin Bobbitt
672a68d372 Fixes needed when GitLab sign-in is not enabled
When sign-in is disabled:
 - skip password expiration checks
 - prevent password reset requests
 - don’t show Password tab in User Settings
 - don’t allow login with username/password for Git over HTTP requests
 - render 404 on requests to Profiles::PasswordsController
2017-07-13 10:08:27 -04:00
Stan Hu
575dced5d7 If migrations are pending, make CurrentSettings use existing values and populate missing columns with defaults
master was failing because `ApplicationSetting.create_from_defaults` attempted
to write to a column that did not exist in the database. This occurred in a
`rake db:migrate` task, which was unable to perform the migration that would
have added the missing column in the first place.

In 9.3 RC2, we also had a bug where password sign-ins were disabled because
there were many pending migrations. The problem occurred because
`fake_application_settings` was being returned with an OpenStruct that did not
include the predicate method `signup_enabled?`. As a result, the value would
erroneously return `nil` instead of `true`. This commit uses the values of the
defaults to mimic this behavior.

This commit also refactors some of the logic to be clearer.
2017-06-19 09:54:48 -07:00