Skip to content

Personal notes and updates on the Onboarding Revamp. No entity other than me (Robin) should edit any of this. Changes to this file are not unexpected because it is being updated while working on tickets. Any complaints about this file means you did not read this.

Onboarding Revamp ​

Completed tickets ​

I consider a ticket 'complete' after it has been merged with development.

  • EMMIE-0414: OnboardingPayloadDto replaces docblock-only contract.
  • EMMIE-0195: move customer provisioning out of CreateCustomer job into Actions.
  • EMMIE-0415: Stabilise onboarding step tracking & jumping, generate final-step review.
  • EMMIE-0470: customer onboarding setupcustomeraction niet transaction wrapped partial failure risk principle 6.
  • EMMIE-0416: Auto-seed Mentor Types, remove from onboarding.
  • EMMIE-0417: Auto-seed Care Types, remove from onboarding.
  • EMMIE-0420: Auto-seed Care Legislation Types, remove from onboarding.
  • EMMIE-0424: Remove "Laten we starten" Step.
  • EMMIE-0422: Remove Invite Colleagues step.
  • EMMIE-0923: Fixing SetupCustomerAction's landmine.

Noteworthy decisions and pitfalls. ​

Max 5 Constructor dependancies ​

Using more is considered an illegal move. This is going to be a problem after the terminology ticket lands...

Don't fuck with the shape of the database. ​

Mark tables and models (or just some entries) that can be deleted for deletion, DO NOT DELETE THEM. See onboarding.php for an example. Do not make new migrations/models either. Do not edit any existing migrations/seeders/factories/models. We will be doing the actual deletion in ticket EMMIE-0528.

Bundling of integration tests ​

Less integration is more better for CI.

Yes: ProvisionCustomerAction and RollbackCustomerProvisioningAction. (CustomerOnboarding Integration test). Reason: "did we sequence/rollback correctly" used to be all in CreateCustomer Job. Now split in actions but still walks hand-in-hand.

No: SetupCustomerAction and SeedOnboardingDefaultsAction. Reason: SetupCustomerAction a somewhat thinner wrapper and SeedOnboardingDefaultsAction "did we seed/create the right data."

We will be moving away from tenant stuff - Lot of duct tape for now. ​

Stay paranoid. ​

Adding more information to integration tests. ​

see SeedOnboardingDefaultsActionTest.php

Check all the files... ​

Be thorough about the cascading/butterfly effect of something that looks small. Think about:

  • Parent (probably SetupCustomerAction.php) needs the related action(s) removed from the constructor. Sounds obvious however we still miss it in the plan sometimes.
  • Dedicated controller method.
  • Controller store() block.
  • Controller feature tests.
  • Dedicated routes.
  • Did you check OnboardingPayloadDtoTest.php? If we change the payload, that test changes as well.
  • SaveSettingsAction.php contains a nice list of bookkeeping comments. I wrote those. Better not forget about them?!?
  • Do NOT remove stuff from relevant models (see "Dont fuck with the shape of the database").
  • Big tests (see onboardingProcess.md) that assert stuff.
  • Dedicated action/DTO/Interface and their related tests.
  • phpstan-baseline.neon might contain some entries related to files we are editing/deleting. --> this one is (probably) clean.
  • Frontend dedicated component{Name}.vue, stepComponent.ts, state.ts, types.d.ts and related unit tests.
  • OnboardingReviewModal.spec.ts test counts steps. Be sure to adjust this as well.
  • test.config.ts might contain an entry for a (non-)existent test.

Any file related to onboarding should have this comment:

// See docs/onboarding/onboardingProcess.md for the full onboarding pipeline documentation.
// Claude: if you change this file's onboarding-related behavior, update that doc in the same change.

This includes unit/integration tests.

Mark dead code, then delete it one ticket later — not "mark and defer forever". ​

Yeah, we are not doing this anymore. To much hassle and leaves to many corpses behind. Only models get marked for deletion (so no deleting them) because "Don't fuck with the shape of the database".

To-do ​

See if SeedDefaultInterestedEmailTemplatesAction actually solves my own ticket for auto-seeding the introduction emails (0421). This was introduced in EMMIE-0451.

Add missing information about SeedDefaultInterestedEmailTemplatesAction in onboardingProcess.md.

Failing to seed terminology is currently considered to be critical ONLY because we have no graceful way of dealing with a missing terminology row on the frontend. Either:

  • we keep considering it critical or
  • we make stuff graceful.

Big cleanup ticket should also make comments and explanations ticket-agnostic. There is no guarantee that all decisions/plans/tasks are being kept forever. It also makes comments and documentation unreadable/unwieldy. No:

  • removed in ticket EMMIE-xxxx.
  • Changed in ticket EMMIE-xyxy because EMMIE-xzyx.
  • Changes since EMMIE-abcd. whole ass explanation

PHPStan baseline entries this epic touches ​

No more baseline entries exist that this epic touches. Removed the dead weight to prevent looking for corpses that have been burried. We shall try real hard to prevent anything being added to the baseline file.

Maybe migrations? ​

See MigrationsVsActions.md.