Ticket #13820 (new PLIP)
Use "Add portal content" permissions for manage_pasteObjects
Reported by: | seanupton | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | Unknown | Version: | |
Keywords: | Cc: | keul |
Description (last modified by seanupton) (diff)
Proposer: Sean Upton
Seconder:
Motivation
- Plone currently limits pasting of copied (and moved) objects to users who have the Modify portal content permission on the target folder.
- The act of adding content by pasting is non-sequitur to whether a user should modify the folder (e.g. Edit form) -- these are only coincidentally related, sometimes.
- This confuses people using the sharing tab to affect roles of users, and may create confusion for product add-on authors who create workflow definitions.
- A user with the Add portal content permission on the target should be able to paste -- such that users who have both Copy or Move permission on source content, and Add portal content to target folder have met sufficient permissions checks.
Assumptions
- Scope: limited to pasting; no assumptions are made on permissions for copy or for deletion on moved items (existing checks and permissions should work as they do now in such cases).
Proposal & Implementation
- Change __ac_permissions__ on folder classes (directly or indirectly via ClassSecurityInfo) for Dexterity, Archetypes, Plone site to use Add portal content permission (cmf.AddPortalContent) instead of the current Modify portal content.
Deliverables
- Respective fixes in Products.Archetypes, plone.dexterity, and Products.CMFPlone for all base folder classes (including PloneSite). See links below to specific revs/lines of code proposed for change.
- Tests in each respective package:
- guarded_getattr() tests to verify that manage_pasteObjects() is accessible in expected security/user context.
- Integration tests (may require use of functional test layer, due to transaction commits).
- Appropriate changelog entries.
- Some documentation for future use in a Plone 5 upgrade guide, TBD.
Risks
- In a possible edge-case this may break backward-compatibility of sites with workflow definitions that grant users ability to modify object, but not add to it.
- This should be communicated to product authors and integrators in future upgrade documentation.
- Testing complexity: copy/paste requires use of a functional test layer; clipboard support will not work without transaction commits on newly added content (test fixtures) -- testing a paste/rename in the same transaction as the item was added will not work properly.
Participants
- Sean Upton
Progress
- TBD
References
- Should this PLIP be accepted, it should replace/supercede #9177 -- a note to such effect should be placed in comments on that ticket.
- See discussion on plone-developers
- Plone overrides default permissions for most copy/paste/rename operations of OFS.CopySupport. Implementations of permissions for manage_pasteObjects() in Plone, Archetypes, and Dexterity currently:
- On PloneSite
- On BaseFolder (Archetypes)
- On plone.dexterity.Container
- Others may exist pending additional examination.
Change History
comment:1 Changed 2 years ago by seanupton
- Type changed from Bug to PLIP
- Milestone changed from 4.x to 5.0
comment:2 Changed 2 years ago by seanupton
- Description modified (diff)
Updated PLIP ticket body with content based on PLIP template.
comment:5 Changed 2 years ago by keul
- Cc keul added
We hare a monkeypatch products we always use in that case.
In our experience there are some additional classes to be fixed (maybe the difference between the plip and our experience is related to Plone 3.3 compatibility). We call a monkeypatch function of those classes:
_update_permissionsPaste(BasePloneFolder) _update_permissionsPaste(BaseFolderMixin) _update_permissionsPaste(BaseBTreeFolder) _update_permissionsPaste(PloneSite)
Note: See
TracTickets for help on using
tickets.