Ticket #923 (closed defect: fixed)

Opened 14 years ago

Last modified 13 years ago

Local role blocking is propagated to children

Reported by: tziade Owned by: trac
Priority: P2 Milestone: CPS 3.3.7
Component: CPSDefault Version: TRUNK
Severity: normal Keywords:
Cc:

Description (last modified by atchertchian) (diff)

If you block a local role, it will appear blocked in all children. This is not true though, as unblocking the child will not have any effect.

The child should be able to block itself independantly from its parent.

The fix is easy in the UI for the button, but how can we represent such a state ?

Change History

comment:1 Changed 14 years ago by tziade

Possible patch (AT?)

@@ -28,16 +28,24 @@
 
 # Get local roles settings from the membership tool
 mtool = getToolByName(context, 'portal_membership')
 dict_roles = mtool.getMergedLocalRolesWithPath(context)
+
+url_tool = getToolByName(context, 'portal_url')
+local_url = url_tool.getRelativeContentURL(context)
+
 local_roles_blocked = 0

 # Filter special roles, and only take local roles
 for item, role_infos in dict_roles.items():
     for role_info in role_infos:
         roles = role_info['roles']
-        if item == "group:role:Anonymous" and "-" in roles:
+        if (item == "group:role:Anonymous" and "-" in roles
+            and role_info['url'] == local_url):
             local_roles_blocked = 1
         # filter with roles in context
         role_info['roles'] = [r for r in roles if r in cps_roles]

comment:2 Changed 14 years ago by fguillaume

I think it's ok yes.

comment:3 Changed 14 years ago by atchertchian

  • Milestone changed from CPS 3.3.6 to CPS 3.4.0

Changing milestone, bugfix is ok but introduces new problems in UI.

comment:4 Changed 14 years ago by atchertchian

  • Description modified (diff)
  • Summary changed from Local role blocking is propagated to childs to Local role blocking is propagated to children

Problems introduced: UI does not make the difference between roles that are blocked (roles above blocking) and roles that are not (roles below blocking), because this use case (mutliple blocking) was not taken into account. I would prefer to have these methods in unrestricted code somewhere in some tool, rather than in skin scripts, and covered by unit tests, before taking into account more complicated use cases like this one.

comment:5 Changed 14 years ago by tziade

  • Status changed from new to closed
  • Resolution set to fixed

see [28509]

comment:6 Changed 14 years ago by atchertchian

Also fixed in [28546] because previous changeset introduced regressions. Fixing this bug led to remove possibility to view inherited blocked roles because it would have been overkill to make the difference between roles blocked by current blocking, and roles blocked by another blocking above: unblocking roles temporarily gives information about affected users/roles. When #449 is fixed (mergedLocalRolesWithPath should know about blocking roles), this information will not be so accessible anyway, right?

comment:7 Changed 13 years ago by gracinet

I just put back the "show blocked roles" as it was needed for a customer. It displays the roles that would apply if there was no blocking, ie the merged roles of the parent [47552] and i18n in [47554], [47556]

Note: See TracTickets for help on using tickets.