Ticket #9263 (closed PLIP: fixed)
GenericSetup syntax for importing Sharing page roles
Reported by: | optilude | Owned by: | optilude |
---|---|---|---|
Priority: | major | Milestone: | 4.0 |
Component: | General | Version: | |
Keywords: | Cc: | lucmult@…, esteele, plip-advisories@… |
Description
I'd like to propose that we merge collective.sharingroles into plone.app.workflow. This provides for a way to add custom roles to columns on the Sharing page using a GenericSetup import handler.
The implementation is already working and tested, so it should be pretty easy to bring into Plone core. Arguably, we could just ship with collective.sharingroles, but it seems silly to have this maintained in a separate package if we're talking about having it in Plone core, and since no-one actually imports from collective.sharingroles, there's no problem so long as we keep the file name the same.
Change History
comment:3 Changed 7 years ago by alecm
Come on Martin, this isn't a PLIP. That said:
+1 provided it's merged into plone.app.workflow
comment:4 follow-up: ↓ 19 Changed 7 years ago by pupq
+1
It would also be VERY helpful if the sharing tab showed the real role names rather than just the "verb-y" role names ("Can edit", etc)
Seeing just those verb names confuses all the integrators who are struggling to understand the difference between roles and permissions, and makes it hard to loop back to the user/group administration, where they assign roles by names (and everywhere else that integrators see role names).
A good compromise would be Real Role Name (Verb Name), ie "Editor (Can edit)".
This is more painful for people than many may realize. It was a real step backward in people understanding roles/permissions.
comment:6 Changed 7 years ago by erikrose
- Owner optilude deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:8 Changed 7 years ago by optilude
- Owner set to optilude
- Status changed from new to assigned
I'll do this if accepted
comment:9 Changed 7 years ago by davisagli
My FWT vote: +1. Also +1 for Joel's suggestion to show the real role names.
comment:10 Changed 7 years ago by MatthewWilkes
FWT Vote: +1 - Yes please!
comment:11 Changed 7 years ago by rossp
FWT Vote +1. Same as with #9259, though. I wish that this was written as a proper PLIP. I'm voting on this pretty much by pedigree and I hate to do that.
comment:12 Changed 7 years ago by raphael
FWT vote: +1
comment:13 Changed 7 years ago by calvinhp
FWT Vote: +1 ditto rossp
comment:14 Changed 7 years ago by esteele
Approved by FWT vote.
comment:15 Changed 7 years ago by optilude
comment:16 Changed 7 years ago by optilude
comment:17 Changed 7 years ago by optilude
This is now ready for review
comment:18 Changed 7 years ago by erikrose
comment:19 in reply to: ↑ 4 Changed 7 years ago by ldr
I agree that labels in the user/group administration should match those of the sharing tab, but the names need to be translatable.
Replying to pupq:
+1
It would also be VERY helpful if the sharing tab showed the real role names rather than just the "verb-y" role names ("Can edit", etc)
Seeing just those verb names confuses all the integrators who are struggling to understand the difference between roles and permissions, and makes it hard to loop back to the user/group administration, where they assign roles by names (and everywhere else that integrators see role names).
A good compromise would be Real Role Name (Verb Name), ie "Editor (Can edit)".
This is more painful for people than many may realize. It was a real step backward in people understanding roles/permissions.
comment:20 Changed 7 years ago by esteele
Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.
comment:21 Changed 7 years ago by optilude
On the "Can review" stuff: +1 to making it "Can review (Reviewer role)" or similar. I'm happy to make that template change, but I'd rather do it after merge as it's not really a part of this PLIP.
On the i18n stuff: We don't actually use the i18n namespace at all. I've removed that from the documentation. What actually happens is that we use the Plone message factory:
PMF = MessageFactory('plone') ... title = unicode(node.getAttribute('title')) ... self.title = PMF(title)
From speaking to Hanno, we don't currently have a good/standard solution for handling i18n:domain and initialising message factories accordingly. However, the i18n:domain and i18n:translate stuff helps i18ndude extract messages for translation. Perhaps not ideal, but solving this is outside the scope of this PLIP.
Therefore, I think this PLIP is ready to be merged.
comment:22 Changed 7 years ago by hannosch
The way Martin approached the i18n syntax here really is fine.
No GenericSetup handler actually looks at any of the i18n markup (*). The i18n markup is purely for i18ndude to be able to automatically extract the messages. As a result all messages in GS files end up in the plone domain and none of them can have explicit ids.
Improving this would be a PLIP of its own. Right now we have a consistent state for all GS handlers. We should make sure we stay consistent here. So someone who feels strongly about it, might start that PLIP with all it nice little problems (it's persistent data we'd touch here, so it needs migration, some of this is in GS and CMF itself and needs to be handled there, in some places we directly use ids of OFS containers as UI-facing elements, but these can only be ascii strings, ...).
(*) well, yes, except one part of the actions.xml and types.xml stuff - but that's two of 40 steps or so.
comment:23 Changed 6 years ago by erikrose
comment:24 Changed 6 years ago by matthewwilkes
comment:25 Changed 6 years ago by matthewwilkes
comment:26 Changed 6 years ago by optilude
Matthew,
This handler is not intended to export the stock roles (which are global utilities). I don't see that this is a problem. If you'd exported them and then re-imported them, you'd end up with local utilities overriding the global ones. If the global ones were changed in Plone, people who'd imported the local ones would not see those changes.
I don't think it makes sense to attempt to export the stock roles. Maybe this is a documentation issue, but it's not a problem with the PLIP's intended functionality.
Your import error is unrelated, as you noticed.
Can I have my +1 back? :)
Martin
comment:27 Changed 6 years ago by rossp
FWT vote: +1 for merge
comment:28 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes -1 Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:29 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9607.
comment:30 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed
comment:31 Changed 6 years ago by dukebody
I've tried to add remove="True" support to this feature. In plone.app.workflow/exportimport.py:
Index: exportimport.py =================================================================== --- exportimport.py (revision 32656) +++ exportimport.py (working copy) @@ -75,6 +75,13 @@ component = PersistentSharingPageRole(title=title, required_permission=required) + if node.hasAttribute('remove'): + if self.context.queryUtility(component, ISharingPageRole, name) is not None: + if name in self.context.objectIds(): + self.context._delObject(name, suppress_events=True) + self.context.unregisterUtility(component, ISharingPageRole, name) + return + self.context.registerUtility(component, ISharingPageRole, name, info=self.info_tag) def _extractRole(self, reg):
This makes
<?xml version="1.0"?> <sharing> <role remove="True" id="Overlord" title="Can fly" permission="Manage portal" i18n:attributes="title" /> </sharing>
remove "Can fly" from the sharing page.
I have no previous experience at all hacking GS import handlers so feel free to criticise.
comment:32 Changed 6 years ago by optilude
This looks good. Two suggestions:
- We need a test for it. :-)
- We should check for "true" explicitly. Here's an (untested) variation:
Index: exportimport.py =================================================================== --- exportimport.py (revision 32656) +++ exportimport.py (working copy) @@ -75,6 +75,13 @@ component = PersistentSharingPageRole(title=title, required_permission=required) + if node.hasAttribute('remove') and node.getAttribute('remove').lower() == 'true': + if self.context.queryUtility(component, ISharingPageRole, name) is not None: + if name in self.context.objectIds(): + self.context._delObject(name, suppress_events=True) + self.context.unregisterUtility(component, ISharingPageRole, name) + return + self.context.registerUtility(component, ISharingPageRole, name, info=self.info_tag) def _extractRole(self, reg):
My only other concern is that in this scenario, you have to have the exact same title and required_permission to be able to unregister. I think we should relax that requirement, so that you can just do:
<?xml version="1.0"?> <sharing> <role remove="True" id="Overlord" /> </sharing>
You'll need to refactor a bit, though: just look up the 'old' utility as you do, and pass that to unregisterUtility(), instead of creating the "new" utility and using that as the argument to unregisterUtility().
comment:33 Changed 6 years ago by hannosch
"2. We should check for "true" explicitly."
Why? As soon as the remove attribute is there, that should be enough. Otherwise you should support "true", "True" and "1". I think most of the handlers just care about the attribute being present. The value doesn't make a difference. Think of it as remove="remove" aka. checked="checked" :)
comment:34 Changed 6 years ago by dukebody
I've opened another ticket to track this feature request: #9979.