Re: r21831 - in plone.app.workflow/trunk/plone
|
|
Martin Aspeli-2
|
Enclope,
This code is commented out for a reason. You can't just unilaterally change the policy like this in a point release. Please back out this change. If you want to discuss a policy change, take it up on plone-dev. Martin Encolpe Degoute wrote: > Author: encolpe > Date: Thu Jul 24 04:27:57 2008 > New Revision: 21831 > > Modified: > plone.app.workflow/trunk/plone/app/workflow/configure.zcml > plone.app.workflow/trunk/plone/app/workflow/localroles.py > plone.app.workflow/trunk/plone/app/workflow/tests/base.py > Log: > Manager should be able to add the 'can manage' role on the standard sharing tab > > Modified: plone.app.workflow/trunk/plone/app/workflow/configure.zcml > ============================================================================== > --- plone.app.workflow/trunk/plone/app/workflow/configure.zcml (original) > +++ plone.app.workflow/trunk/plone/app/workflow/configure.zcml Thu Jul 24 04:27:57 2008 > @@ -26,12 +26,12 @@ > factory=".localroles.ReviewerRole" > /> > > - <!-- > <utility > name="Manager" > factory=".localroles.ManagerRole" > /> > > + <!-- > <utility > name="Owner" > factory=".localroles.OwnerRole" > > Modified: plone.app.workflow/trunk/plone/app/workflow/localroles.py > ============================================================================== > --- plone.app.workflow/trunk/plone/app/workflow/localroles.py (original) > +++ plone.app.workflow/trunk/plone/app/workflow/localroles.py Thu Jul 24 04:27:57 2008 > @@ -1,6 +1,7 @@ > from zope.interface import implements > from plone.app.workflow.interfaces import ISharingPageRole > from plone.app.workflow import permissions > +from Products.CMFCore import permissions as core_permissions > > from Products.CMFPlone import PloneMessageFactory as _ > > @@ -32,20 +33,22 @@ > > # Only managers can manage these > > -# class ManagerRole(object): > -# implements(ISharingPageRole) > -# > -# title = u"Manage" > -# required_permission = 'Manage portal' > -# > -# class OwnerRole(object): > -# implements(ISharingPageRole) > -# > -# title = u"Own" > -# required_permission = 'Manage portal' > -# > -# class MemberRole(object): > -# implements(ISharingPageRole) > -# > -# title = u"Member" > -# required_permission = 'Manage portal' > +class ManagerRole(object): > + implements(ISharingPageRole) > + > + title = _(u"title_can_manage", default=u"Can manage") > + required_permission = core_permissions.ManagePortal > + > +# Low level role that should never be dispayed > + > +#class OwnerRole(object): > +# implements(ISharingPageRole) > +# > +# title = _(u"title_can_own", default=u"Can own") > +# required_permission = core_permissions.ManagePortal > + > +#class MemberRole(object): > +# implements(ISharingPageRole) > +# > +# title = _(u"title_can_subscribe", default=u"Can subscribe") > +# required_permission = core_permissions.ManagePortal > > Modified: plone.app.workflow/trunk/plone/app/workflow/tests/base.py > ============================================================================== > --- plone.app.workflow/trunk/plone/app/workflow/tests/base.py (original) > +++ plone.app.workflow/trunk/plone/app/workflow/tests/base.py Thu Jul 24 04:27:57 2008 > @@ -42,6 +42,7 @@ > self.portal.acl_users._doAddUser('delegate_editor', 'secret', ['Member',],[]) > self.portal.acl_users._doAddUser('delegate_contributor', 'secret', ['Member',],[]) > self.portal.acl_users._doAddUser('delegate_reviewer', 'secret', ['Member',],[]) > + self.portal.acl_users._doAddUser('delegate_manager', 'secret', ['Member',],[]) > > self.setRoles(('Manager',)) > self.folder.invokeFactory('News Item', 'newsitem1') > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
Hans-Peter Locher
|
+1
The defaul configuration of the sharing tab shouldn't change every month... mr_savage Martin Aspeli schrieb: > Enclope, > > This code is commented out for a reason. You can't just unilaterally > change the policy like this in a point release. > > Please back out this change. If you want to discuss a policy change, > take it up on plone-dev. > > Martin > > Encolpe Degoute wrote: > >> Author: encolpe >> Date: Thu Jul 24 04:27:57 2008 >> New Revision: 21831 >> >> Modified: >> plone.app.workflow/trunk/plone/app/workflow/configure.zcml >> plone.app.workflow/trunk/plone/app/workflow/localroles.py >> plone.app.workflow/trunk/plone/app/workflow/tests/base.py >> Log: >> Manager should be able to add the 'can manage' role on the standard sharing tab >> >> Modified: plone.app.workflow/trunk/plone/app/workflow/configure.zcml >> ============================================================================== >> --- plone.app.workflow/trunk/plone/app/workflow/configure.zcml (original) >> +++ plone.app.workflow/trunk/plone/app/workflow/configure.zcml Thu Jul 24 04:27:57 2008 >> @@ -26,12 +26,12 @@ >> factory=".localroles.ReviewerRole" >> /> >> >> - <!-- >> <utility >> name="Manager" >> factory=".localroles.ManagerRole" >> /> >> >> + <!-- >> <utility >> name="Owner" >> factory=".localroles.OwnerRole" >> >> Modified: plone.app.workflow/trunk/plone/app/workflow/localroles.py >> ============================================================================== >> --- plone.app.workflow/trunk/plone/app/workflow/localroles.py (original) >> +++ plone.app.workflow/trunk/plone/app/workflow/localroles.py Thu Jul 24 04:27:57 2008 >> @@ -1,6 +1,7 @@ >> from zope.interface import implements >> from plone.app.workflow.interfaces import ISharingPageRole >> from plone.app.workflow import permissions >> +from Products.CMFCore import permissions as core_permissions >> >> from Products.CMFPlone import PloneMessageFactory as _ >> >> @@ -32,20 +33,22 @@ >> >> # Only managers can manage these >> >> -# class ManagerRole(object): >> -# implements(ISharingPageRole) >> -# >> -# title = u"Manage" >> -# required_permission = 'Manage portal' >> -# >> -# class OwnerRole(object): >> -# implements(ISharingPageRole) >> -# >> -# title = u"Own" >> -# required_permission = 'Manage portal' >> -# >> -# class MemberRole(object): >> -# implements(ISharingPageRole) >> -# >> -# title = u"Member" >> -# required_permission = 'Manage portal' >> +class ManagerRole(object): >> + implements(ISharingPageRole) >> + >> + title = _(u"title_can_manage", default=u"Can manage") >> + required_permission = core_permissions.ManagePortal >> + >> +# Low level role that should never be dispayed >> + >> +#class OwnerRole(object): >> +# implements(ISharingPageRole) >> +# >> +# title = _(u"title_can_own", default=u"Can own") >> +# required_permission = core_permissions.ManagePortal >> + >> +#class MemberRole(object): >> +# implements(ISharingPageRole) >> +# >> +# title = _(u"title_can_subscribe", default=u"Can subscribe") >> +# required_permission = core_permissions.ManagePortal >> >> Modified: plone.app.workflow/trunk/plone/app/workflow/tests/base.py >> ============================================================================== >> --- plone.app.workflow/trunk/plone/app/workflow/tests/base.py (original) >> +++ plone.app.workflow/trunk/plone/app/workflow/tests/base.py Thu Jul 24 04:27:57 2008 >> @@ -42,6 +42,7 @@ >> self.portal.acl_users._doAddUser('delegate_editor', 'secret', ['Member',],[]) >> self.portal.acl_users._doAddUser('delegate_contributor', 'secret', ['Member',],[]) >> self.portal.acl_users._doAddUser('delegate_reviewer', 'secret', ['Member',],[]) >> + self.portal.acl_users._doAddUser('delegate_manager', 'secret', ['Member',],[]) >> >> self.setRoles(('Manager',)) >> self.folder.invokeFactory('News Item', 'newsitem1') >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> > > > [hans-peter_locher.vcf] begin:vcard fn:Hans-Peter Locher n:Locher;Hans-Peter org:InQuant GmbH adr;quoted-printable:;;Bahnhofstra=C3=9Fe 11;Ravensburg;;88214;Deutschland email;internet:hans-peter.locher@... tel;work:+49 (0) 751 35 44 112 tel;fax:+49 (0) 751 35 44 115 x-mozilla-html:FALSE url:http://www.inquant.de version:2.1 end:vcard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
Encolpe Degoute-2
|
Martin Aspeli a écrit :
> Enclope, > > This code is commented out for a reason. You can't just unilaterally > change the policy like this in a point release. > > Please back out this change. If you want to discuss a policy change, > take it up on plone-dev. Hello, My point is there's no explanations why these roles are out. If there is a policy it should be explain here. The two last are builtins roles unusable in the sharing view but if we don't have any 'Webmaster' role some configurations are not accessible without using the ZMI to assign the 'Manager' role to an user. For me it is a critical bug unless there is a documentation of the policy. I would want to fix https://dev.plone.org/plone/ticket/6806 that is not reasonably possible if the Manager role is not shown in the sharing view. Regards, -- Encolpe Degoute INGENIWEB (TM) - S.A.S 50000 Euros - RC B 438 725 632 Bureaux de la Colline 1 rue Royal 92210 Saint Cloud web : www.ingeniweb.com - « les Services Web Ingénieux » Tel : 01.78.15.24.08 / Fax : 01 47 57 39 14 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
Wichert Akkerman
|
Previously Encolpe Degoute wrote:
> Martin Aspeli a écrit : > > Enclope, > > > > This code is commented out for a reason. You can't just unilaterally > > change the policy like this in a point release. > > > > Please back out this change. If you want to discuss a policy change, > > take it up on plone-dev. > > Hello, > > My point is there's no explanations why these roles are out. If there is > a policy it should be explain here. I agree with that, and I am still somewhat upset that Alex and Martin made a lot of those decisions without documenting their reasoning publicly. That is only leading to things like http://plone.org/products/plone/roadmap/228 which try to restore the (at least in my opinion) saner behaviour using a documented process. Even so we should not be making behavioural changes in a maintenance release. Wichert. -- Wichert Akkerman <wichert@...> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
Martin Aspeli
|
That's fine, but you still can't unliaterally make this kind of change in a point release and not tell anyone about it. Point taken. I'm sorry about this. Right. This isn't a good way to do things. On the one hand, I think it's worth listening to Alex as our UI architect, especially when he's done user testing (as he had prior to the issue that 228 addresses). I think UI sometimes needs to be "opinionated" to enforce consistency. Sometimes we get a bit blinded by the status quo because we're so used to the way things work. Sometimes we need to make bold decisions. I think Alex's recent series of blog posts is another example of that, and one which I am personally quite excited about, having recently tried to explain Plone to a few non-technical users and being amazed at how much we take for granted that really isn't that obvious. On the other hand, that's no excuse to skip the process or avoid proper discussion. We (and probably Alex in particular, and probably me taking directions from him a bit too easily) tend to get a bit too gung-ho close to releases. Without proper discussion, we just end up having proxy battles with things like PLIP 228. Coming back to the issue at hand, what do you feel would be appropriate documentation for the sharing page thing? I'll spend a bit of time putting in place some more clarity around this. If I can find the time, I'll try to make an add-on product that brings in some TTW configurability of this as well, since this is long overdue. We could then consider merging that for 3.2 or 3.3. Exactly. Martin |
|||||||||||||||
|
Wichert Akkerman
|
Previously Martin Aspeli wrote:
> Wichert Akkerman wrote: > > That is only leading to things like > > http://plone.org/products/plone/roadmap/228 which try to restore the (at > > least in my opinion) saner behaviour using a documented process. > > > > Right. This isn't a good way to do things. > > On the one hand, I think it's worth listening to Alex as our UI architect, > especially when he's done user testing (as he had prior to the issue that > 228 addresses). I think UI sometimes needs to be "opinionated" to enforce > consistency. Sometimes we get a bit blinded by the status quo because we're > so used to the way things work. Sometimes we need to make bold decisions. Plone is growing up and needs some process. That does not need to full-fledged democracy where everyone gets to say; I think we all agree that that does not work. But we do need some way where at the very least important decisions are documented with a rationale and a way for other field experts to influence that decision. We have more UI experts than Alex and we should make sure they are involved as well. For technology that wants to go in core we have a process with proposals, public review and a framework team. Now that we have at least one UI person on the frameowrk team I think it makes total sense to use that same process for UI changes. > think Alex's recent series of blog posts is another example of that, and one > which I am personally quite excited about, having recently tried to explain > Plone to a few non-technical users and being amazed at how much we take for > granted that really isn't that obvious. For me Alex's recent blog posts are all about day-dreaming for better days. What the end result will be is unknown and can be very different. We'll need to go through prototypes and an implementation or two before something usable will emerge I expect. It's very pie-in-the-sky. But whatever it ends up with it needs to go through some kind of process and not be pushed down by one or two people, no matter whose those people are. > On the other hand, that's no excuse to skip the process or avoid proper > discussion. We (and probably Alex in particular, and probably me taking > directions from him a bit too easily) tend to get a bit too gung-ho close to > releases. Without proper discussion, we just end up having proxy battles > with things like PLIP 228. Indeed. I see many people asking for rationales for behaviour, even for things that have not changed for many years. We should do a better job at documentating this. > Coming back to the issue at hand, what do you feel would be appropriate > documentation for the sharing page thing? I'll spend a bit of time putting > in place some more clarity around this. If I can find the time, I'll try to > make an add-on product that brings in some TTW configurability of this as > well, since this is long overdue. We could then consider merging that for > 3.2 or 3.3. I suspect you can write the generic desired behaviour in a two or three brief paragraphs. I'm sure you have seen enough functional specifications to come up with something :) Wichert. -- Wichert Akkerman <wichert@...> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
|
Martin Aspeli-2
|
Wichert Akkerman wrote:
> Indeed. I see many people asking for rationales for behaviour, even for > things that have not changed for many years. We should do a better job > at documentating this. Much agreed. I think package-level documentation works for this, especially when we have many small packages rather than a few huge ones. > I suspect you can write the generic desired behaviour in a two or three > brief paragraphs. I'm sure you have seen enough functional > specifications to come up with something :) Sure - I guess it should go in plone.app.workflow? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
|||||||||||||||
| Free Forum Powered by Nabble | Forum Help |