Skip to content

A user can be presented with the about your company page in the trial registration flow

Minahil Nichols requested to merge trial-registration-flow-specs into master

What does this MR do and why?

It enables passing trial param passing through the registration flow. This is part of #355786 (closed)

This flow forces the user to go through a new company page - same as standard trial registration flow. The user starts at http://gdk.test:3000/-/trial_registrations/new and continues the same path as the video shown in this MR, except the trial boolean is on throughout the process since they will have gone through the trial_resgitration flow initially.

Branch Merge/Revert Context

Original MR !86541 (merged) was merged but was breaking FOSS.

The related revert !89120 (merged).

Additional added commit for fix f97bd32f

How to set up and validate locally

  1. Setup prerequisites:
    1. Ensure GITLAB_SIMULATE_SAAS=true is in your environment and that you've restarted your services after setting it.
    2. Ensure that your license is up to date so that new users can be registered successfully (do we need steps documented for this?)
    3. Ensure the customers application is setup and working.
    4. Ensure admin approval for user registration is not required: (via the rails console)
      ApplicationSetting.first.update(require_admin_approval_after_user_signup: false)
    5. Ensure that email confirmations are not required: (via the rails console)
      ApplicationSetting.first.update(send_user_confirmation_email: false)
    6. Enable the following feature flags: (via the rails console)
      Feature.enable(:user_other_role_details)
      Feature.enable(:combined_registration)
      Feature.enable(:about_your_company_registration_flow)
    7. Ensure that any other feature flags that might impact the registration flows are disabled. (via the rails console)
  2. Replication steps:
    1. Register a new user by visiting: http://gdk.test:3000/-/trial_registrations/new
    2. You must answer the following questions in this way to see the whole registration flow:
      1. Welcome page:
        1. Who will be using GitLab? My company or team
        2. What would you like to do? Create a new project
      2. About your company page:
        1. GitLab Ultimate trial (optional) Toggled ON
    3. Upon completion of the registration steps, verify that the expected request(s) have gone to the customers application and that they contain the expected new params.

The best way to test this is running tests because there is a feature flag on customers that also needs to be turned on. Below are the instructions to run them.

WEBDRIVER_DELAY=0.1 WEBDRIVER_HEADLESS=false bundle exec rspec ee/spec/features/registrations/saas_user_registration_spec.rb

Since things will happen quickly visually, it might be hard to capture all of it for review, so you can add the following to your spec/support/capybara.rb to slow things down, adjusting the WEBDRIVER_DELAY if it's still too fast.

# Allow for feature specs to be slowed down for UX review, and to
# avoid the really long and painful setup and replication steps.
require 'selenium/webdriver/remote'
class Selenium::WebDriver::Remote::Bridge
  if (delay = ENV['WEBDRIVER_DELAY'].to_s.to_f) > 0
    alias_method :execute_without_delay, :execute
    define_method(:execute) do |*args|
      sleep delay
      execute_without_delay(*args)
    end
  end
end

I've also added some additional comments for more insight on the direct changes. Let me know if that helps!

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Minahil Nichols

Merge request reports

Loading