Description
Once an entity can have a dedicated read-only view (see #3833), there is no picker action that opens a referenced entity for viewing. EntityPicker has only entity_open, which opens the detail view, i.e. the editing view.
The list data components solve the same problem with two separate actions: list_edit (requires the UPDATE permission, disabled when the view is read-only) and list_read (requires only READ, stays enabled). EntityPicker has no counterpart of the second one.
Use case
A read-only view shows an entity whose reference attributes are rendered as entity pickers. Following such a reference is a natural drill-down: the user wants to look at the referenced entity, not to edit it. The same applies to users who are only permitted to read the referenced entity — today the only available action sends them to an editing view.
Expected behavior
EntityPicker should have a read action that opens the picker value in a read-only view, resolving the view the same way list_read does after #3833: the view marked as primary read view, otherwise the view with the <entity>.read id, otherwise the detail view opened in read-only mode. It should require only the READ permission and stay enabled on a read-only view. The existing entity_open action keeps its current behavior.
Worth checking as part of this issue: which picker actions remain reachable once the picker itself is read-only — if they are not, drill-down from a read-only view is impossible today regardless of the action used.
Impact
Drill-down from a read-only view stays read-only along the whole path, and applications no longer have to replace a picker action to achieve it.
Description
Once an entity can have a dedicated read-only view (see #3833), there is no picker action that opens a referenced entity for viewing.
EntityPickerhas onlyentity_open, which opens the detail view, i.e. the editing view.The list data components solve the same problem with two separate actions:
list_edit(requires the UPDATE permission, disabled when the view is read-only) andlist_read(requires only READ, stays enabled).EntityPickerhas no counterpart of the second one.Use case
A read-only view shows an entity whose reference attributes are rendered as entity pickers. Following such a reference is a natural drill-down: the user wants to look at the referenced entity, not to edit it. The same applies to users who are only permitted to read the referenced entity — today the only available action sends them to an editing view.
Expected behavior
EntityPickershould have a read action that opens the picker value in a read-only view, resolving the view the same waylist_readdoes after #3833: the view marked as primary read view, otherwise the view with the<entity>.readid, otherwise the detail view opened in read-only mode. It should require only the READ permission and stay enabled on a read-only view. The existingentity_openaction keeps its current behavior.Worth checking as part of this issue: which picker actions remain reachable once the picker itself is read-only — if they are not, drill-down from a read-only view is impossible today regardless of the action used.
Impact
Drill-down from a read-only view stays read-only along the whole path, and applications no longer have to replace a picker action to achieve it.