Ticket #661 (new enhancement)

Opened 4 years ago

Last modified 3 years ago

Contextual local roles management

Reported by: ogrisel <ogrisel@nuxeo.com> Assigned to: trac
Priority: P3 Milestone: CPS 3.5.0
Component: CPSDefault Version: 3.4.0
Severity: normal 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

06/14/05 19:10:44 changed 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:

a. 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.

b. A class-level attribute. This is very Zope2-ish.

09/29/05 04:00:29 changed by janguenot

Do we really wanna change this for 3.4 ???

09/29/05 08:52:24 changed by ogrisel

  • milestone changed from CPS 3.4.0 to CPS 3.5.0.

10/03/05 01:04:40 changed 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.

10/19/05 18:04:09 changed by fguillaume

Links to current code:

01/12/06 15:29:32 changed 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.

02/01/06 12:16:31 changed by ebarroca

  • milestone changed from CPS 3.4.0 to CPS 3.4.1.

05/16/06 19:35:52 changed by sfermigier

  • milestone changed from CPS 3.4.1 to CPS 3.4.2.

05/19/06 16:57:52 changed by sfermigier

  • milestone changed from CPS 3.4.2 to CPS 3.4.3.