CreateRecordReactionField

FinalYes

Validation class for fields to be allowed for record creation in the "create record" reaction.

The rule decides both which fields the form offers and which ones the reaction writes.

Internal

Table of Contents

Methods

hasItems()  : bool
holdsBitmask()  : bool
isAllowedForCreation()  : bool
isComparedAgainstItems()  : bool
isMappable()  : bool
isWritableBy()  : bool
Whether a backend user may write the field, decided the way DataHandler decides it: a field declaring "exclude" needs the permission for it to be granted, and one shown to admins only is theirs alone.

Methods

hasItems()

public static hasItems(string $type) : bool
Parameters
$type : string
Return values
bool

holdsBitmask()

public static holdsBitmask(string $type) : bool
Parameters
$type : string
Return values
bool

isAllowedForCreation()

public static isAllowedForCreation(TcaSchema $schema, string $field) : bool
Parameters
$schema : TcaSchema
$field : string
Return values
bool

isComparedAgainstItems()

public static isComparedAgainstItems(string $type) : bool
Parameters
$type : string
Return values
bool

isWritableBy()

Whether a backend user may write the field, decided the way DataHandler decides it: a field declaring "exclude" needs the permission for it to be granted, and one shown to admins only is theirs alone.

public static isWritableBy(FieldTypeInterface $fieldInfo, string $table, string $field, BackendUserAuthentication $backendUser) : bool

The same rule answers two questions with two different users. The field map offers what the integrator editing the reaction may edit, and the reaction writes what the user it impersonates may write, which is not the same user! DataHandler makes the second call itself, but drops the field without logging anything, so a caller would read the created record as carrying a value it never got.

Parameters
$fieldInfo : FieldTypeInterface
$table : string
$field : string
$backendUser : BackendUserAuthentication
Return values
bool
On this page

Search results