0c545bcdeb
# Introduction Closes https://github.com/twentyhq/core-team-issues/issues/2669 Part of the `isSystemSideEffect` engine-ownership effort. Until now, a custom object's default **INDEX** table view (`All {objectLabelPlural}`) and its view fields were built imperatively in `ObjectMetadataService` with random `v4()` identifiers, while `twenty-standard` authored its own copies with hardcoded literals. The two never converged, an object rename could drift the view, and nothing marked these rows as engine-owned. This PR makes the metadata side-effect engine the **single owner** of the INDEX view and its view fields, on name-free deterministic identifiers, for custom and standard objects alike. ## Core design - **Name-free deterministic identity.** The INDEX view identifier derives from `object identifier + ViewKey.INDEX` (`getSystemViewUniversalIdentifier`); each view-field identifier derives from `view identifier + field identifier` (`getViewFieldUniversalIdentifier`). An object rename (with a pinned object identifier) keeps the same view, losslessly. - **`isSystemSideEffect: true` is provenance.** Every INDEX view / view field the engine emits is flagged system-owned, so manifest deletion inference never drops it. The flag follows the view: a view field inherits its parent view's flag. - **The engine is the sole owner of the INDEX view.** It always emits it; a caller providing one with the same derived identifier is a genuine conflict surfaced by the engine's reserved-identifier collision, not silently deferred. ## Changes ### Shared (`twenty-shared`) - `getIndexViewUniversalIdentifier` → `getSystemViewUniversalIdentifier`, now taking a `viewKey` (generalizes to any singleton engine-owned view). - Standard field identifiers extracted into a new `STANDARD_OBJECT_FIELDS` constant, so both an object's `fields` and its INDEX view read the same field identifiers. - `buildStandardObjectIndexView` derives the standard INDEX view + view-field identifiers from `STANDARD_OBJECT_FIELDS`, replacing the hardcoded literals in `standard-object.constant.ts`. ### Metadata side-effect engine (custom objects) - **`objectSystemFieldsAndIndexViewOnCreate`** (replaces `objectSystemFieldsOnCreate`): on object creation, provisions the 7 reserved system fields **and** the INDEX view with one view field per displayable system field, all `isSystemSideEffect: true`. - **`fieldIndexViewFieldOnCreate`** (new): on field creation, provisions the field's INDEX view field. Object created in the same batch → visible, positioned before the system view fields; pre-existing object → hidden, appended (preserving the historical `createOneField` behavior). Both branches resolve the INDEX view by its derived identifier (single map access, never a scan). - **`fieldSystemViewFieldsOnDelete`** (new): on field deletion, cascade-deletes every engine-owned view field displaying it. - **`objectSystemSideEffectsOnDelete`** (extended): now also cascade-deletes the object's engine-owned views and their view fields (in addition to system fields, indexes, searchFieldMetadata). Every lookup walks a foreign-key aggregator down from the deleted object, so the work is proportional to what the object owns, never to workspace size. - Object-create and field-create positions are derived from the same caller-input field list, so the INDEX view layout is contiguous with no handler-ordering dependency. - `view` / `viewField` added to the side-effect companion metadata names for `fieldMetadata` and `objectMetadata`. ### Reserved-identifier invariant A caller can never define an entity whose identifier collides with one a system side effect produces: caller inputs are forced `isSystemSideEffect: false` at every entry point (API and app-manifest transpilers), and the engine raises `RESERVED_SYSTEM_UNIVERSAL_IDENTIFIER`, aborting the operation, when a system emission lands on a caller-claimed identifier. Covered by a new engine-level test. ### Caller-side provisioning removed The imperative INDEX view + view-field provisioning is removed from `ObjectMetadataService.createOneObject`. The record-page `FIELDS_WIDGET` view is intentionally left caller-side and deferred to the follow-up (see below). ### `twenty-standard` convergence Standard INDEX views and their view fields converge on the same derived-identifier + `isSystemSideEffect: true` scheme as the engine. `twenty-standard` syncs through the from/to migration path (which never runs the side-effect engine), so it authors this INDEX surface itself, matching what the engine produces for custom objects. ## Rollout Two `2.26.0` workspace commands, running after the `2.25` messageCampaign commands: - `upgrade:2-26:reconcile-index-view-universal-identifier` re-owns the INDEX views of the **twenty-standard and workspace-custom applications** and all their view fields to the derived identifiers with `isSystemSideEffect: true`, in a single per-workspace transaction. Each view field identifier is keyed on the application of the **displayed field** (an app or user column on a standard INDEX view converges too). Soft-deleted views and view fields are skipped: one can coexist with an active successor on the same derivation inputs and both would derive the same identifier. Children reference the view by primary key, so the re-own is lossless. - `upgrade:2-26:demote-and-backfill-application-index-view` handles **manifest-installed applications**, which never had their INDEX view auto-provisioned: every caller-authored INDEX view of another application is demoted to `key: null` (a plain additional view under its manifest identifier), then every application object gets the engine-owned INDEX view and its full view-field layout backfilled through the migration pipeline's legacy path (no side-effect expansion), views committed before view fields across applications since a view field belongs to the application owning its field. Idempotent and retry-safe: engine-owned INDEX views are neither demoted nor re-backfilled, and view creation and view-field creation are gated independently, so a retry after a partial failure still backfills the missing view fields of an already-committed view. Both support `--dry-run` and invalidate the full flat-maps closure (parents aggregate the re-owned identifiers, children resolve them as universal foreign keys, and page-layout widget universal configurations resolve view PKs at cache-build time). The `2.25` `upgrade:2-25:add-message-campaign-name-field` command is adapted to resolve the campaign INDEX view by its INDEX key on the object instead of by universal identifier: it now runs before the reconcile, on workspaces still holding legacy identifiers. ## ⚠️ Breaking change This PR **mutates 187 previously hardcoded universal identifiers** — the standard objects' INDEX views and their view fields (the literals removed from `standard-object.constant.ts`), now derived. - **Handled by the `2.26` commands above** for all existing workspaces. - **The INDEX key is now engine-reserved.** The flat view validator rejects caller-created INDEX views (API and manifest inputs are forced `isSystemSideEffect: false`) and enforces a single non-deleted INDEX view per object; `view.key` is no longer a comparable/updatable property, so no writer can promote or demote a view after creation. `ViewManifest.key` is deprecated and ignored (manifest views are always additional views, so old apps keep syncing and demoted views are not promoted back); the REST/GraphQL create path now rejects `key: INDEX`. In-repo example apps (`hello-world`, `document-generator`) no longer declare it. - **12 declared-but-never-seeded standard INDEX view field identifiers deleted** (the former `preservedViewFields` on `timelineActivity`, `workflowRun` and `workspaceMember`): after the reconcile, no workspace row references them. - **`computeFlatViewFieldsToCreate` now derives view field identifiers** instead of drawing `v4()` ones, which also changes what the committed `1-23` record-page backfill produces going forward (deliberate, documented in-code). - **Record-page views and view fields are not affected** (identifiers unchanged). - **In-repo apps: `twenty-last-contact` updated.** It was the only app declaring explicit INDEX view fields (10 columns across `allPeople` / `allCompanies` / `allOpportunities`) through manifest `viewFields`. Those target identifiers are now engine-owned and derived, so the manifest inputs no longer resolve and install failed with `View not found`. The app now declares only its fields; the engine's `fieldIndexViewFieldOnCreate` provisions the matching INDEX view field automatically. No other app under `packages/twenty-apps` references any of the 187 mutated identifiers, and apps that target standard views point at record-page views (e.g. `real-estate` → `opportunityRecordPageFields`) or their own objects (`twenty-partners`), all unchanged. ### Loss of granularity for app maintainers The engine now owns the INDEX view field of every field a caller adds to an object, so app maintainers lose direct control over those columns. Previously an app could target the engine-owned INDEX view with an explicit manifest `viewField` and set its `position` and `isVisible`. Now `fieldIndexViewFieldOnCreate` appends a **hidden** view field in caller-input order on field creation, so: - Columns an app previously showed at a **dedicated position** and **visible** (e.g. `twenty-last-contact`'s last-contact columns) become **hidden** and **appended in input order** after install. - There is currently **no manifest way to override** the engine-provisioned INDEX view field's position, visibility, or size. This is a deliberate regression accepted for the sake of single-ownership, and app maintainers should expect their INDEX columns to move/hide after upgrading. A follow-up override API will let maintainers reclaim per-field control over the engine-provisioned INDEX view field. ## Testing - Unit specs for each handler: object create (system fields + INDEX view/view fields, override, position offset), field create (same-batch vs existing-object, non-displayable noop, no-INDEX-view noop), field delete, object delete (fields/indexes/searchFieldMetadata/views/view fields cascade, reverse-relation view field on another object). - Engine-level test for the reserved-identifier collision. - `twenty-standard` guard test that its INDEX views/view fields stay on the derived scheme and stay system-owned. - Integration test: full engine provisioning of the INDEX view/view fields on object creation, same view id preserved across an object rename, and cascade delete on object deletion. ## Follow-up The full record-page stack (record-page view, its view fields, view field groups, page layout / tab / widget) is still built imperatively and moves into the engine in https://github.com/twentyhq/core-team-issues/issues/2721.
301 lines
9.2 KiB
TypeScript
301 lines
9.2 KiB
TypeScript
import { createOneSelectFieldMetadataForIntegrationTests } from 'test/integration/metadata/suites/field-metadata/utils/create-one-select-field-metadata-for-integration-tests.util';
|
|
import { createOneObjectMetadata } from 'test/integration/metadata/suites/object-metadata/utils/create-one-object-metadata.util';
|
|
import { deleteOneObjectMetadata } from 'test/integration/metadata/suites/object-metadata/utils/delete-one-object-metadata.util';
|
|
import { updateOneObjectMetadata } from 'test/integration/metadata/suites/object-metadata/utils/update-one-object-metadata.util';
|
|
import { destroyOneView } from 'test/integration/metadata/suites/view/utils/destroy-one-view.util';
|
|
import { makeRestAPIRequest } from 'test/integration/rest/utils/make-rest-api-request.util';
|
|
import {
|
|
assertRestApiErrorNotFoundResponse,
|
|
assertRestApiSuccessfulResponse,
|
|
} from 'test/integration/rest/utils/rest-test-assertions.util';
|
|
import { createTestViewWithRestApi } from 'test/integration/rest/utils/view-rest-api.util';
|
|
import { generateRecordName } from 'test/integration/utils/generate-record-name';
|
|
import { assertViewStructure } from 'test/integration/utils/view-test.util';
|
|
import { ViewOpenRecordIn, ViewType } from 'twenty-shared/types';
|
|
|
|
describe('View REST API', () => {
|
|
let testObjectMetadataId: string;
|
|
let testSelectFieldMetadataId: string;
|
|
let testViewId: string | undefined;
|
|
|
|
beforeAll(async () => {
|
|
const {
|
|
data: {
|
|
createOneObject: { id: objectMetadataId },
|
|
},
|
|
} = await createOneObjectMetadata({
|
|
input: {
|
|
nameSingular: 'testViewObject',
|
|
namePlural: 'testViewObjects',
|
|
labelSingular: 'Test View Object',
|
|
labelPlural: 'Test View Objects',
|
|
icon: 'IconView',
|
|
},
|
|
});
|
|
|
|
testObjectMetadataId = objectMetadataId;
|
|
|
|
const { selectFieldMetadataId } =
|
|
await createOneSelectFieldMetadataForIntegrationTests({
|
|
input: {
|
|
objectMetadataId,
|
|
},
|
|
});
|
|
|
|
testSelectFieldMetadataId = selectFieldMetadataId;
|
|
});
|
|
|
|
afterAll(async () => {
|
|
await updateOneObjectMetadata({
|
|
expectToFail: false,
|
|
input: {
|
|
idToUpdate: testObjectMetadataId,
|
|
updatePayload: {
|
|
isActive: false,
|
|
},
|
|
},
|
|
});
|
|
await deleteOneObjectMetadata({
|
|
input: { idToDelete: testObjectMetadataId },
|
|
});
|
|
});
|
|
|
|
afterEach(async () => {
|
|
if (!testViewId) return;
|
|
|
|
await destroyOneView({
|
|
viewId: testViewId,
|
|
expectToFail: false,
|
|
});
|
|
testViewId = undefined;
|
|
});
|
|
|
|
describe('GET /metadata/views', () => {
|
|
it('should return all views for workspace', async () => {
|
|
const response = await makeRestAPIRequest({
|
|
method: 'get',
|
|
path: '/metadata/views',
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiSuccessfulResponse(response);
|
|
expect(Array.isArray(response.body)).toBe(true);
|
|
});
|
|
|
|
it('should return views filtered by objectMetadataId', async () => {
|
|
const response = await makeRestAPIRequest({
|
|
method: 'get',
|
|
path: `/metadata/views?objectMetadataId=${testObjectMetadataId}`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiSuccessfulResponse(response);
|
|
expect(Array.isArray(response.body)).toBe(true);
|
|
|
|
if (response.body.length > 0) {
|
|
assertViewStructure(response.body[0]);
|
|
}
|
|
});
|
|
});
|
|
|
|
describe('POST /metadata/views', () => {
|
|
it('should create a new view', async () => {
|
|
const viewName = generateRecordName('Test View');
|
|
const view = await createTestViewWithRestApi({
|
|
name: viewName,
|
|
icon: 'IconTable',
|
|
type: ViewType.TABLE,
|
|
key: null,
|
|
position: 0,
|
|
isCompact: false,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
|
|
testViewId = view.id;
|
|
|
|
assertViewStructure(view, {
|
|
name: viewName,
|
|
objectMetadataId: testObjectMetadataId,
|
|
icon: 'IconTable',
|
|
type: ViewType.TABLE,
|
|
key: null,
|
|
position: 0,
|
|
isCompact: false,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
});
|
|
});
|
|
|
|
it('should create a kanban view', async () => {
|
|
const viewName = generateRecordName('Test Kanban View');
|
|
const kanbanView = await createTestViewWithRestApi({
|
|
name: viewName,
|
|
icon: 'IconKanban',
|
|
type: ViewType.KANBAN,
|
|
key: null,
|
|
position: 1,
|
|
isCompact: true,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
mainGroupByFieldMetadataId: testSelectFieldMetadataId,
|
|
});
|
|
|
|
testViewId = kanbanView.id;
|
|
|
|
assertViewStructure(kanbanView, {
|
|
name: viewName,
|
|
type: ViewType.KANBAN,
|
|
isCompact: true,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
});
|
|
});
|
|
|
|
describe('GET /metadata/views/:id', () => {
|
|
it('should return a view by id', async () => {
|
|
const viewName = generateRecordName('Test View for Get');
|
|
const view = await createTestViewWithRestApi({
|
|
name: viewName,
|
|
icon: 'IconTable',
|
|
type: ViewType.TABLE,
|
|
key: null,
|
|
position: 0,
|
|
isCompact: false,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
|
|
testViewId = view.id;
|
|
|
|
const response = await makeRestAPIRequest({
|
|
method: 'get',
|
|
path: `/metadata/views/${view.id}`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiSuccessfulResponse(response);
|
|
assertViewStructure(response.body, {
|
|
id: view.id,
|
|
name: viewName,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
});
|
|
|
|
it('should return empty object for non-existent view', async () => {
|
|
const response = await makeRestAPIRequest({
|
|
method: 'get',
|
|
path: `/metadata/views/20202020-b7a4-4f8e-9c1d-2e3f4a5b6c7d`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiErrorNotFoundResponse(response);
|
|
});
|
|
});
|
|
|
|
describe('PATCH /metadata/views/:id', () => {
|
|
it('should update an existing view', async () => {
|
|
const viewName = generateRecordName('Test View for Update');
|
|
const view = await createTestViewWithRestApi({
|
|
name: viewName,
|
|
icon: 'IconTable',
|
|
type: ViewType.TABLE,
|
|
key: null,
|
|
position: 0,
|
|
isCompact: false,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
|
|
testViewId = view.id;
|
|
|
|
const updatedName = generateRecordName('Updated View');
|
|
const updateData = {
|
|
name: updatedName,
|
|
type: ViewType.KANBAN,
|
|
isCompact: true,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
mainGroupByFieldMetadataId: testSelectFieldMetadataId,
|
|
};
|
|
|
|
const response = await makeRestAPIRequest({
|
|
method: 'patch',
|
|
path: `/metadata/views/${view.id}`,
|
|
body: updateData,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiSuccessfulResponse(response);
|
|
assertViewStructure(response.body, {
|
|
id: view.id,
|
|
name: updatedName,
|
|
type: ViewType.KANBAN,
|
|
isCompact: true,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
});
|
|
|
|
it('should return 404 error when updating non-existent view', async () => {
|
|
const updateData = {
|
|
name: 'Updated View',
|
|
type: ViewType.KANBAN,
|
|
};
|
|
|
|
const response = await makeRestAPIRequest({
|
|
method: 'patch',
|
|
path: `/metadata/views/20202020-b7a4-4f8e-9c1d-2e3f4a5b6c7d`,
|
|
body: updateData,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiErrorNotFoundResponse(response);
|
|
});
|
|
});
|
|
|
|
describe('DELETE /metadata/views/:id', () => {
|
|
it('should delete an existing view', async () => {
|
|
const viewName = generateRecordName('Test View for Delete');
|
|
const view = await createTestViewWithRestApi({
|
|
name: viewName,
|
|
icon: 'IconTable',
|
|
type: ViewType.TABLE,
|
|
key: null,
|
|
position: 0,
|
|
isCompact: false,
|
|
openRecordIn: ViewOpenRecordIn.SIDE_PANEL,
|
|
objectMetadataId: testObjectMetadataId,
|
|
});
|
|
|
|
testViewId = view.id;
|
|
|
|
const deleteResponse = await makeRestAPIRequest({
|
|
method: 'delete',
|
|
path: `/metadata/views/${view.id}`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiSuccessfulResponse(deleteResponse);
|
|
expect(deleteResponse.body.success).toBe(true);
|
|
|
|
const getResponse = await makeRestAPIRequest({
|
|
method: 'get',
|
|
path: `/metadata/views/${view.id}`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiErrorNotFoundResponse(getResponse);
|
|
});
|
|
|
|
it('should return 404 error when deleting non-existent view', async () => {
|
|
const response = await makeRestAPIRequest({
|
|
method: 'delete',
|
|
path: `/metadata/views/20202020-b7a4-4f8e-9c1d-2e3f4a5b6c7d`,
|
|
bearer: APPLE_JANE_ADMIN_ACCESS_TOKEN,
|
|
});
|
|
|
|
assertRestApiErrorNotFoundResponse(response);
|
|
});
|
|
});
|
|
});
|