Ticket #923 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Local role blocking is propagated to children

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

Description (Last modified by atchertchian)

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

09/14/05 11:25:17 changed 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]

09/14/05 12:46:28 changed by fguillaume

I think it's ok yes.

09/14/05 13:04:24 changed 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.

09/14/05 14:23:16 changed by atchertchian

  • description changed.
  • 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.

10/21/05 18:02:58 changed by tziade

  • status changed from new to closed.
  • resolution set to fixed.

see [28509]

10/23/05 04:04:19 changed 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?

07/28/06 19:53:22 changed 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]