Skip to main content

Implements a new permission 'Delete portal content'

Project description

collective.deletepermission

The default Plone permission for deleting content does not allow to delete content from a folder without being able to delete the folder itself.

The collective.deletepermission package introduces an additional permission Delete portal content. By seperating the permission Delete portal content (I can delete this content object) from the permission Delete objects (I can delete something IN this folder), we now can allow a Contributor to delete content he created (Owner role) without letting him delete folders and objects belonging to other users - even in a nested environment.

Implementation details

This package monkey patches:

  • manage_delObjects of AT BaseFolder

  • manage_cutObjects__roles__ of AT BaseFolderMixin

  • cb_userHasCopyOrMovePermissionchecks of OFS CopySupport

and overrides the following templates and scripts (skins):

  • folder_rename_form.cpt

  • object_rename.py

to implement a new Delete portal content permission.

The Delete portal content permission is now required on the object you want to delete. On parent objects the Delete objects permission is still required. This gives us some more flexibility and makes it possible for a contributor to delete his own content but nothing else. On the graph below you can see the situation with the default permission settings and if it is deletable by Contributor1.

- Rootfolder of Admin (not deletable)
  '- Document of Contributor1 (deletable)
  '- Subfolder of Admin (not deletable)
    '- Document of Contributor1 (deletable)
    '- Document of Contrubutor2 (not deletable)

In default Plone this would look like this:

- Rootfolder of Admin (not deletable)
  '- Document of Contributor1 (deletable)
  '- Subfolder of Admin (deletable)
    '- Document of Contributor1 (deletable)
    '- Document of Contrubutor2 (deletable)

This is caused by the fact that in default Plone we require the same permission on the parent and the object. If we have two levels where we should be able to delete some files, we always end up with the user being able to delete the container of the second level.

Usage

  • Add collective.deletepermission to your buildout configuration:

[instance]
eggs +=
    collective.deletepermission
  • Install the generic setup import profile.

Compatibility

Runs with Plone 4.1, 4.2 and 4.3.

Changelog

1.1.3 (2014-03-03)

  • Fix protection of manage_delObjects with “Delete objects”. In certain situations, when only having the permission to delete the content (“Delete portal content”) but not the permission to delete from the the parent container (“Delete objects” on the parent) deleting was possible even though it shouldn’t have been. [jone]

1.1.2 (2013-10-17)

  • Copy no longer requires “Delete portal content”. Requiring “Delete portal content” was introduced accidentally for copying because of a patch for cutting. [jone]

1.1.1 (2013-06-04)

  • Only show “Delete” action with “Delete objects” on the container. [jone]

1.1 (2013-05-24)

  • Do not require ‘Delete portal content’ permission when renaming an object. [buchi]

1.0 (2013-01-24)

  • Init release [mathias.leimgruber]

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

collective.deletepermission-1.1.3.zip (41.0 kB view hashes)

Uploaded source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page