Feature: The editor locks the fields a synchronisation owns 

Description 

The profile editor now reads the managedFields map of EXT:academic_persons, which already locks the fields a synchronisation or an import owns in the backend record form. It applies the map to the same records: a profile, contract or contact with an import identifier, of the default language, whose profile is not excluded with Skip synchronisation.

On such a record a managed field is shown read-only with the marker Synchronised, on the profile page and in the contract and contact forms. A contract or contact with a managed field offers no delete, and no edit once every field the owner could edit is managed. Hiding, showing and sorting it stay available, because the synchronisation never changes them. The endpoints refuse a delete or an edit the row does not offer with the existing error codes document_action_not_allowed and contract_contact_action_not_allowed. In a translated site language a managed field whose value all languages share stays locked, a translated one is editable, as in the backend, and a synchronised row still offers no delete.

A select or a checkbox that is read-only, managed or configured readonly , is now rendered disabled. Neither control has a read-only state, so it could be changed before although the change was not stored.

Impact 

Nothing changes for an installation that names no managed field: the shipped lists are empty. A name in the map that matches no field makes the editor fail with the exception 1790536034, as it makes the backend person record forms fail, rather than leave the field editable without a word.

A value submitted for a locked field is now ignored and the other fields of the request are stored. This holds for a managed field and for one configured readonly , frontendreadonly or disabled , on the profile, contract and contact endpoints. They answered such a value with 422 before, and because the editor sends every field of an open contract or contact when it saves, a contract or contact with a locked field could not be saved from the browser at all. A field the section does not know is still refused with 422. The switches for the synchronisation and for the profile visibility keep refusing a locked value, since that value is their whole request.

The prototypes carry three new keys, and an override has to carry them like every other slot key: managed in the three field rows of Partials/Profile/Field/PrototypeWrapper.html, and managed, editable and deletable in the contact-row of Partials/Profile/Documents/ContractContacts.html. The editor refuses to fill a prototype that lacks a key it writes, so an override without them fails the way one without its prototype does, see Important: The profile editor is Fluid, driven by five custom elements. An override of Partials/Profile/Documents/Actions.html, Partials/Profile/Field/Preview.html or Partials/Profile/Field/Group.html keeps working and only shows no marker. The shipped Partials/Profile/Documents/Contract.html hands every row its own action list from rowActions. An override that still hands the list of the section to every row shows the delete button on a synchronised contract, and the server refuses the delete.