Conversation
Greptile OverviewGreptile SummaryThis PR implements prefilled FIELDS widget configurations for standard page layouts during workspace creation. The implementation introduces a new Key changes:
AI-generated code: Technical implementation: Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant WS as Workspace Creation
participant Builder as StandardApplicationBuilder
participant ViewBuilder as ViewBuilder
participant VFGBuilder as ViewFieldGroupBuilder
participant VFBuilder as ViewFieldBuilder
participant WidgetBuilder as PageLayoutWidgetBuilder
participant DB as Database
WS->>Builder: Create workspace metadata
Builder->>ViewBuilder: Build standard views
ViewBuilder->>DB: Create FIELDS_WIDGET views
Note over ViewBuilder,DB: Creates companyRecordPageFields,<br/>personRecordPageFields, etc.
Builder->>VFGBuilder: Build view field groups
VFGBuilder->>DB: Create field groups (general, additional, other)
Note over VFGBuilder,DB: Groups created for each view<br/>with positions 0, 1, 2
Builder->>VFBuilder: Build view fields
VFBuilder->>DB: Create view fields with group assignments
Note over VFBuilder,DB: Fields linked to groups<br/>with viewFieldGroupId
Builder->>WidgetBuilder: Build FIELDS widgets
WidgetBuilder->>DB: Create widgets with viewId configuration
Note over WidgetBuilder,DB: Links FIELDS widget to<br/>dedicated FIELDS_WIDGET view
|
|
🚀 Preview Environment Ready! Your preview environment is available at: http://bore.pub:44970 This environment will automatically shut down when the PR is closed or after 5 hours. |
| @Field(() => String, { nullable: true }) | ||
| @IsOptional() | ||
| @IsUUID() | ||
| viewId: string | null; |
There was a problem hiding this comment.
Why is it optional?
If the user wants to create a new Fields widget, we first create the widget in the database, and then create and link a view? I would rather see the opposite pattern.
There was a problem hiding this comment.
Yes it's probably the opposite indeed, I don't see a good reason to do it the other way around 👍
| "id": "00000000-0000-0000-0000-000000000102", | ||
| }, | ||
| }, | ||
| "id": "00000000-0000-0000-0000-000000000126", |
There was a problem hiding this comment.
doesn't look stable but OK :) (I think @prastoin introduced some example)
Context
Prefill the FIELDS widget configuration in standard page layouts during workspace creation, linking each widget to a dedicated view with positioned fields organized into sections (via view field groups)
We wanted something very declarative (by manually setting position and visibility of each field per standard object).
In this PR I've generated all the compute- utils via AI (😨) for position/visibility, we'll probably want to confirm with the product which ordering/visibility we want for each standard object but I feel like this can be merged as it is since it's behind a feature flag and this will unblock the work on the frontend