[MAGNOLIA-4476] Add functionality to disable delete or move buttons on a component - 4.5 Created: 16/Jul/12  Updated: 25/Jun/13  Resolved: 03/May/13

Status: Closed
Project: Magnolia
Component/s: rendering, templating
Affects Version/s: 4.5
Fix Version/s: 4.5.9

Type: New Feature Priority: Major
Reporter: Daniel Knobloch Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MAGNOLIA-5010 Add functionality to disable delete o... Closed
dependency
depends upon MAGNOLIA-4989 Permissions for operations Closed
documentation
to be documented by DOCU-407 Disabling edit/move/delete buttons on... Closed
Template:
Acceptance criteria:
Empty
Release notes required:
Yes
Date of First Response:

 Description   

Hi guys,

in our current Magnolia project we need to restrict the permission to delete an existing paragraph.
Users with a special role shall be allowed to edit an existing paragraph, but not to delete it.

In Magnolia versions prior to 4.5 it was possible to simply hide the "Delete" button by specifying an empty "deleteLabel" property in the <cms:editBar> depending on the current user role.
Looking into the source code of the new <cms:component> tag, we could not find a similar approach to restrict the appearance or the functionality of the "Delete" button.

Any hint would be helpful!

Best regards,
Daniel



 Comments   
Comment by Jan Haderka [ 17/Jul/12 ]

Hi Daniel,
it is indeed not possible currently. Thank you for reporting this issue.

Comment by Roman Kovařík [ 05/Apr/13 ]

The second part of port to master is under MGNLUI-1038.

Comment by Roman Kovařík [ 11/Apr/13 ]

Reimplement as follows:
To the TemplateDefinition add:

  • getMoveable()
  • getDeletable()

To the RenderingContext add:

  • getParentAreaDefinition()

To the ComponentElement add:

  • resolveMoveable()
  • resolveDeletable()
    If the rights are not set in the Template, get the rights from parent AreaDefinition.

Example of the idea of the configuration structure in the Site Definition:

  • default
    • templates
      • prototype
        • areas
          • platform
            • availableComponents
              • stkTeaserPaging
                • permission(resctrictions)
                  • delete
                    • roles[superuser=superuser]
Comment by Roman Kovařík [ 23/Apr/13 ]

Changes after review:

TemplateDefinition:
getMoveable()
getDeletable()
getChangeable() ( getEditable() is alredy taken and means don't show any edit bars)

RenderingContext:
getParentAreaDefinition()

ComponentElement:
resolveMoveable()
resolveDeletable()
resolveChangeable()

ComponentAvailability
getPermissions()

Permissions definitions:
PermissionsDefinition (main definition)
PermissionDefinition (allow/deny)
RightDefinition (move/delete/change)

Screenshot of configuration example attached.

Comment by Jan Haderka [ 24/Apr/13 ]

After sleeping on it ...

I agree with keeping editable for all operations (write, mode, delete). And instead of modify/modifiable} I would suggest to use {write/writable. This would make those permissions identical to permissions we use (underneath) in ACLs - in order to edit/modify a component, you need write permission to it. So in the end we would have set of unambiguous permissions for components - write, delete, move, where write one should be also globally set on the component itself, while the two others could be set only on parent area since (again analogy to how real permissions are set) to change order of components or to delete them one need permission to do so on the parent (area in this case).

Since the meaning of three defined permission is very narrow and clean, we can easily extend that by adding another permission (existing in Permissions for ages, but AFAIK never used) which is execute that would be used mainly by actions.

Comment by Jan Haderka [ 24/Apr/13 ]

Regarding the Permission(s)Definition, RightDefinition/RolesDefinition I think we are running in circles here and trying to reinvent what already exists.
After all this is "just" an ACL - An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects..
Can't we just reuse ACL here? I get this weird feeling that if we manage to use same object it will be beneficial in the future.

Comment by Jan Haderka [ 24/Apr/13 ]

The topic here is expanding/overlapping things captured also by http://wiki.magnolia-cms.com/display/DEV/Concept+Security+and+ACLs

And some more interesting reading on Role Based Access Control

Comment by Roman Kovařík [ 03/May/13 ]

Changes after Review II
Allow/deny were dropped (only allow applies).
Template property changeable was renamed to writable (because of compatibility with action permission write).
Permissions definitions for actions and logic for resolving permissions were moved to core (MAGNOLIA-4989).
New naming (MAGNOLIA-4989):

  • PermissionsDefinition-> OperationPermissionDefinition,
  • ConfiguredPermissionsDefinitions -> ConfiguredOperationPermissionDefinition,
  • RightDefinition -> RolesDefinition.

Template property editable remains untouched and is still compatible with old definitions.

Comment by Jan Haderka [ 03/May/13 ]

Actually some more detailed docu is necessary. Please see linked docu ticket for details.

Comment by Roman Kovařík [ 25/Jun/13 ]

Cloned because 4.5 version MAGNOLIA-4476 contains also fixes for 4.5 page editor.
Master fix for page editor is registered under MGNLUI-1038.

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