Add phone_verification_code_enabled switch to application_settings
What does this MR do and why?
See this issue for context #361718
Draft MR that will use this : https://jihulab.com/gitlab-cn/gitlab/-/merge_requests/512/
background
JH SAAS need pass compliance test in China which need ask user provide their phone number during signup process, so that each user can be easily linked to his or her phone number. This is called phone verification code
. For JH self-managed, we don't need phone verification code
.
What Changed
signup
will ask user to verify cellphone number due to compliance in China, during the verification process, reCAPTCHA will show up to ensure user is not robot, then verification code will send to mobile phone via SMS. after that, user will continue the signup process.
sign in
If one user login too many times using same credential in different devise, reCAPTCHA will show up to verify user is not robot.
Problems
above two scenarios break some feature tests and QA tests.
for upstream feature tests, singup process changed so test like ee/spec/features/ trial_registrations/signup_spec.rb
failed due to no phone number found on webpage if we run in JH repo.
for upstream QA tests, it failed in first step on staging/production SaaS, register user, because we cannot bypass reCAPTCHA when we want to signup. According to security compliance, we cannot use some tricks or backdoor to disable it by use some params in URL.
for now, JH write our own tests to cover this feature, however we need find a one way to make upstream test, include feature test and QA test green in JH repo, which test gitlab locally(whitebox test) and remotely(blackbox test).
Solution
Franking speaking, currently there is only one feature, phone_verification_code_enabled
, break the normal workflow. And I believe there are not so many features like phone_verification_code_enabled
.
At first I am thinking to use feature flag as switcher to turn off phone_verification_code_enabled
during the upstream test run, however I found application setting will be better, since feature flag will be removed, and application setting can changed by REST API, which is more user friendly for staging/production env. That's why we have this MR.
/cc @prajnamas
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.