mirror of
https://github.com/twentyhq/twenty.git
synced 2026-09-21 04:56:22 -04:00
Thomas Trompette
89a2b55642
Removes `IS_RECORD_CREATION_FORM_ENABLED` and the legacy quick-create path behind it, so the record creation form introduced in #25203 is the only creation path. Third of four phases is still ahead: required toggle, then validation rules. ## What changes **The flag is gone**: shared enum entry, dev-seeder entry, the admin-panel flag metadata entry added by #25927 while this PR was open, regenerated schemas. **The legacy path is gone with it**, not just bypassed: - `useCreateNewIndexRecord` no longer branches: every quick-create entry point requests the form. The instant-create-then-edit-inline flow no longer exists in the code. - `useRecordCreationForm` lost `shouldOpenRecordCreationForm` and its gates; it only binds the object to the context's `requestRecordCreation`. - `RecordCreationFormContext` is now a required context (`createRequiredContext`). The silent fallback — no provider mounted → create directly — is gone; the provider is mounted unconditionally in `WorkspaceAppProviders`, and a consumer outside it now throws instead of quietly reverting to the old behaviour. - `useRecordCreationFormSettle` drops its null-tolerance for the same reason. - `RecordCreationFormProvider` is now also mounted in the `PageDecorator` and `RecordTableDecorator` storybook decorators, since the required context otherwise throws in stories that render quick-create entry points. An object whose form resolves zero fields — a role restricting every field, or a missing RECORD_FORM layout — now opens the form empty with just a Create button, instead of silently instant-creating. Degenerate but honest; every provisioned workspace has layouts, so it is a corner state, not a path. ## The e2e spec is rewritten `create-record.spec.ts` asserted the old path: click "Create new Person" → inline first-name focus → record fields widget. It now drives the real flow: fill first name, last name and email in the side-panel creation form, submit via `record-creation-form-create-button`, then edit the remaining fields on the created record exactly as before. Two robustness fixes made while rewriting, both pre-existing traps: field lookups in the fields widget now use `{ exact: true }` (the hidden aria description spans — "Contact's Intro" — are substring-matched by `getByText` and break `nth(1)` addressing), and the post-create wait allows for the create roundtrip. This mattered because the e2e suite only runs on labeled PRs and on main pushes — unlabeled, this PR would have landed the break on main. **The `e2e-test` check is red on this PR, and that red is pre-existing.** Main's own push run fails the exact same three specs — most recently [run 35095855759](https://github.com/twentyhq/twenty/actions/runs/35095855759), fifteen minutes before this PR's run: `create-record` (at `:57`, the old spec on untouched main code), `create-kanban-view` and `workflow-creation` — every spec that relies on the shared `.auth/user.json` storage state. Root cause: `signup_invite_email.spec.ts` inherits that storage state and calls `settingsPage.logout()`, which since the cookie-session migration (#23642, hardened in #25079) revokes the shared session server-side — every later storage-state spec lands on the login screen. The suite had not run on main since August 22, so the break was invisible. The fix (replace the logout with a local cookie clear in that spec) is deliberately not bundled here; the `settingsPage.logout()` call is still there on today's main. On this PR's run the three specs fail on their FIRST click — `create-record` at line 59 on `Create new Person`, before any rewritten form step — which is the login-screen signature, not a defect in the rewrite. ## The `api-breaking-changes` check is red, by construction `graphql-inspector` reports `Enum value IS_RECORD_CREATION_FORM_ENABLED was removed from enum FeatureFlagKey` against main's metadata schema. That is the change, not a defect of it: every feature flag removal trips this check, it is not a required check, and #25916 ("Remove the email group flag") merged red on the exact same line one day ago. ## Existing feature flag rows Workspaces with an `IS_RECORD_CREATION_FORM_ENABLED` row keep it; nothing reads it, unknown keys are filtered on the read path, and prior flag removals left rows behind the same way. ## Testing - `twenty-front`, `twenty-server`, `twenty-shared` and `twenty-client-sdk` typecheck clean on the merged head; oxlint on the changed files and oxfmt over each touched package are clean; the 9 record-form specs pass. - The rewritten e2e spec **passes end to end against a local stack running this branch** (three consecutive runs): form fill with focus assertions, create, side-panel field edits, and the final GraphQL verification of every value including the form-filled email. - Schemas regenerated against a server on this branch; the diff is the enum value dropping out of four generated files. - Main merged in twice. Conflicts were the generated `FeatureFlagKey` union in `twenty-client-sdk` (resolved to main's list minus the removed key) and the `PageDecorator` import block, where main swapped the snack-bar context for `ToastProvider` next to the provider import this PR adds.