fix(inbox,integration-ever-works): inbox longtext columns in the entity; a removed long label removes its tag (#11096 review)
Answers the three open Greptile findings on the develop → stage cascade #11096 (head = develop): two fixed here, one answered on the thread.
1. InboxEmail column types on MySQL (1791000003200-AlterInboxEmailJsonColumnsLongText.ts:39) — fixed
The migrations make the 7 JSON columns (1791000003200) and the two body columns (1791000002800) longtext on MySQL, while the entity declared all nine text — so DB_SYNCHRONIZE=true built (or narrowed) them to 64 KB. The entity now declares longtext on MySQL and text elsewhere (inboxEmailLongTextType(), from isMySQL() of @gauzy/config, as the registry plugin does); the inbox plugin declares @gauzy/config (workspace package, no lockfile change).
2. A removed long label left a stale tag (ever-works-tasks.service.ts:429) — fixed
Tags are pushed as labels cut to the label limit, but the inbound merge compared Ever Works' removed label with the full Gauzy tag name, so the tag stayed (and the snapshot then recorded it as gone, so later events could not remove it either). The merge compares names in their pushed form (labelKey), for the task's tags and for the snapshot. This also covers ordinary (not adopted) links, whose pushes record the cut labels.
3. EverWorksConnection.organization onDelete (ever-works-connection.entity.ts:30) — not changed here
TypeORM keeps the base entity's relation options when a subclass redeclares an inherited relation (MetadataArgsStorage.filterByTargetAndWithoutDuplicateRelationProperties copies only the subclass's type onto the base's args), so an override in EverWorksConnection cannot turn the inherited CASCADE into SET NULL — tried, and the metadata spec proved it. The real fix (the entity declaring its own organization/organizationId on TenantBaseEntity) changes the class hierarchy and is a follow-up for the integration owner. Impact today: none on migrated databases (stage/prod run migration 1791000003100, SET NULL), only DB_SYNCHRONIZE=true schemas with the integration flag on.
Verification (local, jest)
inbox-email.entity.spec.ts(new) +inbox-email-json-longtext.migration.spec.ts: pass.ever-works-tasks.service.spec.ts(2 new cases: a long tag is removed when Ever Works removes its cut label — fails on develop, passes here; a long tag whose cut label is still held stays one tag) +ever-works-connection.db.spec.ts: 2 suites, 141/141.
No migration, no data change; both plugins stay behind their flags (unset on stage). Per the owner's rule for Gauzy API/UI: develop → stage only.
🤖 Generated with Claude Code