Feature: A validator flag that locks the frontend editor only
Description
The
readonly
and
disabled
flags of a field in
Configuration/ lock it in the editing
frontend and in the TYPO3 backend record editor at the same time. Installations
that synchronize a field from a directory service usually want profile owners
kept away from it while backend editors can still correct it, and had to reset
the backend lock field by field through TCEFORM.
The new flag
frontendreadonly
locks a field in the editing frontend
only. The example keeps the name fields away from profile owners and lets
backend editors correct them:
validations:
profile:
firstName:
- required
- frontendreadonly
middleName:
- frontendreadonly
lastName:
- required
- frontendreadonly
# contract, emailAddress, phoneNumber, physicalAddress and
# profileInformation repeated as shipped
A
validations
map of a site package replaces the shipped one as a
whole, so every shipped set that should stay has to be repeated. A field that
is listed gets exactly the flags listed for it: without
required
, the
backend no longer requires it either.
- The editing frontend shows the field read-only and ignores a submitted
value, exactly as for
readonly. - The backend record editor keeps the field editable. A
requiredbeside it still makes the field required there, while the editing frontend does not ask the owner for a value they cannot change. - Listed together with
readonlyordisabled, the field stays locked in the backend as well.
The flag is matched case-insensitively, like every other flag, and works in every validation set.
Impact
Nothing changes for an installation that does not list the flag. A TCEFORM
reset of
read that only served to unlock the backend can be
replaced by
frontendreadonly
in place of
readonly
.
The settings are cached. Flush the TYPO3 caches after changing
Settings..
Affected Installations
Installations that lock fields of the profile editing frontend of
fgtclb/academic-persons-edit
through their own
Configuration/.