Ticket #661 (new enhancement)

Opened 14 years ago

Last modified 10 years ago

Contextual local roles management

Reported by: ogrisel <ogrisel@…> Owned by: trac
Priority: P2 Milestone: CPS 3.5.7
Component: CPSDefault Version: 3.4.0
Severity: critical Keywords:
Cc:

Description

Apart from the default local roles renaming discussed earlier on cps-devel, CPS probably needs a way to better define which local roles are relevant according to the context.

Currently, this information is spread in several places:

  1. CPSDefault/skins/cps_default/getCPSLocaleRoles whose result is based on :
  2. CPSCore/CPSMembershipTool.getCPSCandidateLocalRoles
  3. CPSSubscriptions/SubscriptionsTool.setLocalRolesArea and related methods

1 & 2 are used to display the list of possible roles to assign with the [folder|forum|cps_chat]_localrole_form.pt templates.

3 is used by the folder_notifications_form template.

So here are a few

Proposals:

  1. Build a new dedicated tool (in CPSDefault) to store the localrole related code of SubscriptionsTool? and use it in the skins templates and scripts

A-bis. Use the CPSMembershipTool of CPSDefault instead of CPSCore's to do this.

  1. Ask the portal_wokflow tool to guess which localroles are relevant according to context's portal_type + wf state (what about stacks ?)

Maybe a mix of A and B is possible.

Change History

comment:1 Changed 14 years ago by lregebro

Some questions:

  1. Will this be modified in any way, so it has to be persistent?
  2. What different things affect what roles should be listed?

For example, when it comes to the CPSSharedCalendar, I see no reason to ever display anything else than the three roles that are especially defined for the calendar. So there are two additional options to the above available:

  1. A non-persistent registry. This can simply be a dictionary defined in some module somewhere, where you then can, in any way you like as long as it is from disk-based Python code add your own portal type and the list of revelant roles. This is rather Zope3-ish.
  1. A class-level attribute. This is very Zope2-ish.

comment:2 Changed 14 years ago by janguenot

Do we really wanna change this for 3.4 ???

comment:3 Changed 14 years ago by ogrisel

  • Milestone changed from CPS 3.4.0 to CPS 3.5.0

comment:4 Changed 14 years ago by fguillaume

  • Milestone changed from CPS 3.5.0 to CPS 3.4.0

I'd like to keep this targetted for 3.4.0, it's an easy change and brings a lot.

comment:6 Changed 13 years ago by gracinet

B is cool but non sufficient: calendar specific roles can't be guessed from calendar object workflows, for instance. The conceptual problem I see is that some roles are very workflow-centric (eg SectionReviewer?), so that it's natural to ask the workflow tool. Some are so much less that the types tool would be more relevent.

comment:7 Changed 13 years ago by ebarroca

  • Milestone changed from CPS 3.4.0 to CPS 3.4.1

comment:8 Changed 13 years ago by sfermigier

  • Milestone changed from CPS 3.4.1 to CPS 3.4.2

comment:9 Changed 13 years ago by sfermigier

  • Milestone changed from CPS 3.4.2 to CPS 3.4.3

comment:10 Changed 10 years ago by gracinet

  • Priority changed from P3 to P2
  • Severity changed from normal to critical
  • Milestone changed from CPS 3.5.0 to CPS 3.5.2

This mess has to be handled for good at some point. Previous attempts that I know of didn't bring anything but added complexity, because nobody dared removing legacy stuff.

Note: See TracTickets for help on using tickets.