When true, this entity is being deleted as part of an IS-A parent chain initiated by a child entity. The child deletes itself first (FK constraint), then cascades deletion to its parent.
When set to true, the delete operation will BYPASS Validate() and the actual process of deleting the record from the database but WILL invoke any associated actions (AI Actions, Entity Actions, etc...).
OptionalSkipWhen true, the delete skips writing its Record Change (audit) row even when the entity
has TrackRecordChanges on. Set by high-volume MACHINE writers (an integration sync
applying tens of thousands of records), never by interactive deletes — the suppression is
a property of the WRITER, not of the entity, so a human deleting the same record is still
audited.
NOT honoured over the wire. This field exists on the InputType only because the
schema-sync gate requires DeleteOptionsInput to carry every EntityDeleteOptions field;
DeleteOptionsInput.SanitizeFromWire forces it back to false on every request. See
that method for why.
Optional on the wire, on purpose. This field did not exist in 5.51.x, and every other
field here is required, so making it required too turned a 6.1 upgrade into a hard failure
for every client that spells out options___ on a delete (Field "DeleteOptionsInput.SkipRecordChanges" of required type "Boolean!" was not provided). A
5.51 client that omits it and a 6.1 client that sends false mean the same thing, and the
server forces it to false regardless, so null/absent defaults to false here.
StaticSanitizeStrips wire-unreachable capabilities from client-supplied delete options.
SkipRecordChanges suppresses an audit row, which is a strictly higher privilege than
"may delete" — and the only authorization a delete mutation performs is entity:delete.
Honouring the flag from the wire would let ANY caller permitted to delete override an
administrator's entity-level TrackRecordChanges decision, per call. The field is on this
InputType because the schema-sync gate mirrors every EntityDeleteOptions field onto it,
not because a client was ever meant to set it.
This also restores parity with the save path, which has no SaveOptionsInput at all: its
twin (EntitySaveOptions.SkipRecordChanges / SkipGeoCoding) is inexpressible over
GraphQL. Suppression stays what it was designed to be — an IN-PROCESS capability that
IntegrationEngine sets on its own saves, never crossing a resolver.
Downgrades rather than throws, deliberately: the thing being protected is the audit row, so the right outcome is delete proceeds, audit is written, attempt is logged. Throwing would yield no delete AND no audit row.
Call this at EVERY wire entry point that accepts a DeleteOptionsInput — currently
ResolverBase.DeleteRecord (which every generated DeleteX mutation routes through) and
FileCategoryResolver.DeleteFileCategory (which builds its own delete and does not).
OptionaluserEmail: string
GraphQL InputType for entity delete operations.
SYNC REQUIREMENTS - Changes here require updates to:
TESTING: Schema sync tests in GraphQLDataProvider will fail if these files drift out of sync. Run: cd packages/GraphQLDataProvider && npm run test
See