[MGNLUI-3191] EditElementAction should not be available when the template is set to not be editable Created: 07/Oct/14  Updated: 21/Jan/15  Resolved: 15/Oct/14

Status: Closed
Project: Magnolia UI
Component/s: pages app
Affects Version/s: None
Fix Version/s: 5.3.5

Type: Bug Priority: Major
Reporter: Zdenek Skodik Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Non-editable text-image par in 4.5.png    
Issue Links:
causality
is causing MGNLUI-3260 Components without dialog cannot be d... Closed
is causing PAGES-4 CLONE - Components without dialog can... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Setting editable=false at template definition (or cms.<tag>) hides the editing option at the corresponding green bar of pages' detail subapp, but an editor can edit it via the action bar still available though.

The other actions grouped together with, e.g. the one for moving, should apparently be disabled as well.



 Comments   
Comment by Christopher Zimmermann [ 15/Oct/14 ]

QA:
Move action should be disabled as per ticket description. It does not actually work to move it, but its confusing.
I believe delete action should also be disabled. I am able to delete the "non-editable" component using the action bar.

Comment by Aleksandr Pchelintcev [ 15/Oct/14 ]

After discussion with @Zdenek and @Topher it was decided that move action should be also disabled, whereas delete action - not. The user experience of the delete action for the case of non-editable component is not so great though since there is no clear indication of component selection when the edit bar is hidden.

Comment by Andreas Weder [ 16/Oct/14 ]

Hi all. I've been asked to comment on this issue as well.

We can't go with a solution where there's no indication of selection, but still actions available: in the implementation I've seen, you can click on a component, then choose "delete component" on the action bar, but there's no edit bar or no other indication of selection. That doesn't work.

I see two main options we have:

  1. we disable all operations on the component - edit, move, delete -, don't show them in the Action bar and show no edit bar for the component.
  2. we still allow to select a component, just disable the edit action. Move and delete would still be available.

I'd replicate the behavior from earlier versions to ease migration and retain consistency. I thus suggest we go with option 1, because that's how it currently works in 4.5 (see attached screenshot): setting "editable" to "false" hides the edit bar and thus all actions.

We can then take it from there and introduce a different configuration option to make "move" and "delete" available for non-editable components, if requested - actually, those actions are more related to the surrounding container or area than to the component itself.

For option 2, I would still allow to select a component, show its edit bar, show the "move" icon on it and have both "move" and "delete" action available in the Action Bar. I'd replace the "edit" icon with the "read-only" icon we already use in lists and trees, since then we have an indicator in a place you'd certainly look for it. I would not introduce a new visual, read-only state for edit bars: we already have too many different states for bars and adding an additional one only makes things more confusing.

Generated at Mon Feb 12 09:04:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.