[MGNLUI-2945] Action availability with writePermissionRequired does not work on root level Created: 28/May/14  Updated: 05/Dec/14  Resolved: 18/Aug/14

Status: Closed
Project: Magnolia UI
Component/s: content app
Affects Version/s: 5.2.4
Fix Version/s: 5.3.3

Type: Bug Priority: Major
Reporter: Frank Sommer Assignee: Eric Hechinger
Resolution: Fixed Votes: 1
Labels: availability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File read-only-actions.png    
Issue Links:
Relates
relates to MGNLPN-153 AccessDeniedException when creating n... Closed
relates to MGNLUI-3032 Consolidate the UI against NPEs Closed
relation
is related to MGNLCAT-134 Reconfigure availability of de/activa... Closed
is related to MGNLCTS-58 Reconfigure availability of de/activa... Closed
is related to MGNLGS-85 Reconfigure availability of de/activa... Closed
is related to MGNLRSSAGG-177 Reconfigure availability of de/activa... Closed
is related to MGNLTAGS-45 Reconfigure availability of de/activa... Closed
is related to MGNLUI-3053 Reconfigure availability of de/activa... Closed
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   

If you restrict the access to actions with the writePermissionRequired flag, it will work except on root level (no item is selected). The 'Add ...' and 'Import' actions are always clickable.



 Comments   
Comment by Mikaël Geljić [ 10/Jul/14 ]

Now is a good time to tackle that, hopefully it should be less of a hassle in 5.3. For 5.2 we'll have to check implications and consider it carefully.

Comment by Eric Hechinger [ 18/Aug/14 ]

I removed the fixed version 5.2.9, as this would be quite impossible to solve for this version.
With 5.2.x, the root item is handled as a null object. This behavior has changed with 5.3 and causes a lot of code & logic changes...

Comment by Mikaël Geljić [ 22/Aug/14 ]

Review done. In particular, each rule was kept as dry as possible, i.e. only the root (default item) availability rule is aware of the default itemId.

However there was a couple shortcomings to work around still:

  • Some shorthand rules are 'incompatible' by nature: can't combine root=true with nodeTypes (e.g. mgnl:content), because JCR root is never gonna be of mgnl:content node-type. For this, we would actually need to support both AND/OR operands when evaluating rules together.
  • Due to legacy reasons, many action bar 'root' sections have availability configured with root=true but also nodes=false, although JCR root is also a node.

Current workaround is that whenever default item is selected and root availability is true, we dismiss nodes/nodeTypes rules because we want root availability to prevail upon these.

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