[PAGES-362] DeleteElementAction fails if user has read-only permissions on root node Created: 30/Jul/20  Updated: 09/Nov/20  Resolved: 20/Oct/20

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: 6.2.2, 6.2.3
Fix Version/s: 6.2.4

Type: Bug Priority: Neutral
Reporter: Richard Gange Assignee: Jorge Franco
Resolution: Fixed Votes: 1
Labels: 623, actions, maintenance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File delete-error.txt     PNG File travel-demo-editor-1.png    
Issue Links:
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:
Sprint: Maintenance 29

 Description   

If you give a user read-only to / and read-write to /travel then that user cannot delete components in the travel site because the action needs to set the page editor status.

Recreate issue

  • In the Security app, edit the role travel-demo-editor.
  • Set the ACLs for website:
  • Log out.
  • Log back in as user eric.
  • Attempt to delete component from the travel site.
  • Observe the error. delete-error.txt

Expected
The user should be able delete a component with this ACL configuration. It's a logical configuration for system admins. The fact the delete action needs to modify the root node should be handled another way. Perhaps in system context or with a reorder of operations.

Workaround
Use read-write on / and use deny on the sites you want to disallow.



 Comments   
Comment by Aleksandr Pchelintcev [ 15/Oct/20 ]
        valueContext.getSingle()
                .ifPresent(Exceptions.wrap().consumer(node -> {
                    Node parent = node.getParent();
                    node.remove();
                    node.getSession().save();
                    ....
                }));

The action attempts to access the session via node after it has been removed. The underlying wrapper actually considers it gone (the liveness check fails) and re-creates it (because it is a wrapper that is supposed to re-attach the node to session):

            if (!node.getSession().isLive()) {
              ...
            } else {
                node = getContentDecorator().exists(node) ? node : createNewItem(wrapped.getSession());
            }

Possible solution:

  • first save a session reference in action and then remove a node
Generated at Mon Feb 12 06:18:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.