Package: collective.deletepermission
collective.deletepermissionThe default Plone permission for deleting content does not allow to delete
content from a folder without being able to delete the folder itself.Thecollective.deletepermissionpackage introduces an additional permissionDelete portal content. By seperating the permissionDelete portal content(I can delete this content object)  from the permissionDelete objects(I can delete something IN this folder), we now can allow aContributorto delete content he created (Ownerrole) without letting
him delete folders and objects belonging to other users - even in a nested
environment.Implementation detailsThis package monkey patches:manage_delObjectsof AT BaseFolder and Dexterity Containermanage_cutObjects__roles__of AT BaseFolderMixin and Dexterity Containermanage_pasteObjects__roles__of AT BaseFolderMixin and Dexterity Containercb_userHasCopyOrMovePermissionchecksof OFS CopySupportand overrides the following templates and scripts (skins):folder_rename_form.cptobject_rename.pyto implement a newDelete portal contentpermission.TheDelete portal contentpermission is now required on the object you want
to delete.
On parent objects theDelete objectspermission 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.UsageAddcollective.deletepermissionto your buildout configuration:[instance]
eggs +=
    collective.deletepermissionInstall the generic setup import profile.LinksGithub:https://github.com/4teamwork/collective.deletepermissionIssues:https://github.com/4teamwork/collective.deletepermission/issuesPypi:http://pypi.python.org/pypi/collective.deletepermissionContinuous integration:https://jenkins.4teamwork.ch/search?q=collective.deletepermissionCopyrightThis package is copyright by4teamwork.collective.deletepermissionis licensed under GNU General Public License,
version 2.Changelog1.5.0 (2019-09-09)Add Plone 5.1 support. [mbaechtold]Drop Plone 4.1 support. [jone]1.4.0 (2016-09-22)Let Site Administrators delete foreign content on site root. [jone]1.3.0 (2016-09-02)Also patch manage_pasteObjects security deceleration the same way as manage_cutObjects.
This way it’s possible to paste objects in a container, without Modify portal content
permission on the container itself.
[mathias.leimgruber]1.2.1 (2015-08-12)Remove dependency to ftw.upgrade.
[jone]1.2.0 (2015-02-17)Support dexterity objects.
[erral, libargutxi]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]