Phase 1: Add user onboarding trigger

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Current status - 2025-07-24

workflowblocked see &18068 (comment 2649283484)

Problem

We need a way to know if a user should be eligible for our onboarding experience. That way we only show the experience to new users who travel through onboarding or that we determine should enter our onboarding experience based off other events in the future.

Solution

Currently with our namespace based onboarding is started/entered into in the last step of onboarding after the group is created.

Since we are no longer tied to a namespace, we can move this onboarding for user based onboarding earlier in the user registration process. This allows us to include users that are invites and other cases to be eligible for onboarding too.

Where to trigger

Therefore, we should try to put this new trigger as early as possible in the user onboarding/registration and place it in Onboarding::StatusCreateService. By doing that it will correctly get triggered by the registration locations in:

1. ee Registrations controller here
2. ee omniauth callbacks controller here

the ending of the tutorial that we currently have will flip this trigger back to false.

What to create as the trigger

We have a few possibilities here. We need to record it at the database level, but we also want to keep it as performant as possible as it will be checked on almost every web request for a user, while still respecting the width of the users table.

Order of preference:

1. Emulate users.onboarding_in_progress setup and create a similar boolean column on the users table. Default to false.
2. Place it in the user_details.onboarding_status jsonb as a boolean attribute. Non existence will protect existing users.
3. Place it as a separate column on user_details table.

The preference is to place it on the users table so we do not cause a separate query on pages that do not load the user_details relation.

Update: after analyzing the idea of widening the users table, rate of change for this column(low) and then the low complexity around invalidating Rails.cache in this case, it was decided to put this on the user_details table(#3).