I Have a sharing issue I do not understand. I have a buildout I use for a while. Now I have upgraded to Plone 4.3.18 and upgraded the eggs, and reinstalled everything. And the sharing issue appears.
I create with dexterity contenttypes a workspace in a directory and I grand an user rights on the workspace to use with localdiazo and rootnav. The issue is that the user is granted these rights site-wide – from the rootlevel of the site instead of the root of the workspace only where the rights are granted by admin.
I have checked some eggs I can think of that maybe can cause this issue like plone.app.ldap, collective.delegatesiteadmin and collective.impersonate. But the setup with only these eggs works fine.
I get this issue with this buildout both on fresh Plone 4.3.17 and 4.3.18 installs. Have an other Plone 4.3.17 site with a similar buildout and setup that does not has this issue (yet).
What is it that can cause this issue? How can it be solved?
Very difficult to say. In principle, sharing is implemented by so called "local roles". "local roles" are typically inherited down the content hierarchy but not up. Thus, sharing at a deeper down point (your "workspace") should not affect something higher up (and especially not the site).
There are two possibilities:
The sharing has a bug: the local role was placed at the wrong object (the site instead of the "workspace") or the global roles (rather then a local role) have been changed.
The "local role" interpretation is buggy.
If you append `/manage_access" to the url to your "workspace", then this results in a page containing a link to manage the local roles at this object. There, you can verify whether the correct local role is set.
When I remember right, the an acl_users plugin is responsible for an extension of the local role interpretation (the default interpretation does not inherit local roles upward -- and in fact, I do not think that any extension does).
When I append “/manage_access" to the url of the "workspace" and show the permissions and the roles in the context of the object I see that the user I granted rights to has the role of Authenticated Member. In the context the user has the role of Authenticated Editor Member Site Administrator as I specified in the sharing tab of the object. But I get this result with this user from the toplevel of the site downwards. Not only in the workspace.
I have looked in to acl_users and see nothing that appear strange to me. Compared it with an other site that does not has this issue and it looks the same.
It looks like it can be narrowed down to Dexterity Contentype. When I grand the rights on an other object like a directory (not dexterity ) I do not have this issue. It appears on the Dexterity Contentype called workspace. I created this workspace with @@dexterity-types.
Obviously, this should not be the case.
You likely need some form of debugging to find out why this happens.
I would do this in an interactive Python session (--> bin/{instance|client1} debug). The local role management is implemented by AccessControl.rolemanager.RoleManager, inherited by all Zope content objects. Its get:local_roles allows you to find out which local roles are defined at the corresponding content object. You should see your sharing local role setting at your "workspace" and not at the site. If this is not the case, then something went wrong in the sharing setting.
If the local role setting related to your sharing is correct, then the local role interpretation is buggy. To find out what goes wrong, you would login your user (--> AccessControl.SecurityManagement.newSecurityManager) and debug its getRolesInContext method. It would do something wrong for the site object.
@juron Do you by any chance have a customised theme package on this site, and/or did you customise the main_template.pt using an override like z3c.jbot?
An 'enhancement' was made to the base href handling in Plone around 4.3.14-15 to make it more compatible with modern frontend principles, but as a side effect quite a few small issues emerged from it, which were fixed later as we and others ran into them.
If I remember correctly I had similar local role assignment problems where the sharing tab uses a bit of javascript but misses the data-base-url as the context on which it does the ajax requests.
Make sure that your body tag has the following two attributes as is in the latest plonetheme.sunburst 1.4.X main-template.pt (weird it's not on master, but alas)
In a nutshell: the diazo theme is not keeping "data-base-url" attribute in the "body", and the javascript "/skins/plone_ecmascript/kss-bbb.js" is doing a request to "/@@updateSharingInfo"
in the root Plone url, and not in the object itself. So you diazo theme needs to have "data-base-url" in the tag.
Ah yes, your are right. That was also missing when we upgraded, we had missed the change in main_template.pt but you also need to transport the attributes to a diazo theme if it's active.
We modified the merge statement in the diazo theme to also merge the new attributes, like:
<!-- merge classes from Plone body with theme body -->
<merge attributes="class data-base-url data-portal-url" css:theme="body" css:content="body" />
Can you check that the attributes are present in the unstyled html output (content) before the Diazo rules are applied? You can add ?diazo.off=1 to the url if you’re running the site (locally) in debug mode to see the unstyled site.
Or also a local development trick: add the local ip to the list of addresses that should disable Diazo. Then 127.0.0.1 is unstyled but localhost gives you the themed Diazo version
Have moved the attributes up in the rules.xml file of the diazo theme - right under < rules > and above < !--Head-- >. Now it works. Thank you so much.