Ticket #9263 (closed PLIP: fixed)

Opened 7 years ago

Last modified 6 years ago

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:1 Changed 7 years ago by lucmult

  • Cc lucmult@… added

comment:2 Changed 7 years ago by optilude

  • Owner set to optilude

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:5 Changed 7 years ago by esteele

  • Cc esteele added

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:7 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

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

(In [28559]) Implement PLIP refs #9263.

comment:16 Changed 7 years ago by optilude

(In [28561]) PLIP build + notes. Refs #9263

comment:17 Changed 7 years ago by optilude

This is now ready for review

comment:18 Changed 7 years ago by erikrose

(In [29746]) Did a review of the Sharing-tab-role GenericSetup PLIP. Refs #9263.

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

(In [30220]) Updated my review for final vote. Refs #9263.

comment:24 Changed 6 years ago by matthewwilkes

(In [30236]) Adding short review of sharing roles plip (refs #9263) as it doesn't work for me and the Generic Setup exporter is flawed. Sorry, this means FWT vote -1 on merging for now.

comment:25 Changed 6 years ago by matthewwilkes

(In [30237]) Sorry Martin, didn't spot "portlets" lurking in that traceback. The import problem isn't your fault, it's somewhere in the vastness of portlet exportimport. Sigh. The other problem stands, I'm afraid. This refs #9263.

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

(In [30471]) Removing PLIP branch. Closes #9263.

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:

  1. We need a test for it. :-)
  1. 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.

comment:35 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.