Forum OpenACS Development: Site nodes inherit permissions in a strange way
is a subsite for each of our clients, under which, again, is mounted
forums, bug-tracker, blogger, whatnot.
The weird thing is that the forums here will inherit permissions
from the /extranet site node, and not from /myclient, which is what
I'd expect. So I need to set permissions for each application in my
I want to fix this, but before I do, I wanted to check that this
isn't the intended behavior, and that I won't be breaking the
assumptions of a bunch of code out there.
Besides, it would be handy with an interface for managing the
I have a similar system already up and running since 4.5 beta. I have this problem too. I have posted this issue on the bboard and the consensus was from what I remeber is to have the ability where to inherit from. The default is to inherit from the "Main Site". So a UI to have a choice which context_id to use was where the dicussion ended up.
I use this SQL to fix up the permission that I need.
update acs_objects set context_id = '[object_id of new subsite]' where object_id = '[object_id of file storage]' or object_id = '[object_id of bboard]' or object_id = '[object_id of tt-lite]';
My setup is
/clientsite /bboard /file-storage /tt-lite
I then add the user to the "clientsite parties" from groups table. Using select membership_rel__new('[group_id]','[user_id]');
Can you find the thread?
The fact is, though, that it does not inherit from the main site. It inherits from the subsite below Main Site, but above the subsite that I'm mounting the application to.
Main site - subsite 1 - subsite 2 - forums
Forums inherits from subsite 1, not Main site, not subsite 2!
Hm. Trying it out now on a fresh OpenACS install, everything inherits from Main Site, which is at least consistent. Something's probably been fixed in the last week.
Basically for each new subsite I make, it becomes a part of subsite1 (the first client). I never bothered correcting, its in heavy production state. So I just remove the Composition after each new client subsite.
Could it be related to the bug that I found regarding the group of a site is not created until you visit the group page? Weird. Although in your case I think its more of a context_id problem.
Maybe an ubber hacker can track this down... ever heard about Don Wickstrom?
For example if you go to /admin/site-map and drill down past a subsite and create a node that node will inherit from the mainsite node. If you go to /admin and select a subsite, go to it's sitemap and create a node that node will inherit from the subsite.
I guess this makes sense when you think about it, but I don't think it's documented. I changed mine to always inherit from the parent. I like that better but if you do not mount a package before creating a child node it causes problems. It would be nice if the interface supported picking a context_id
Thanks, you're absolutely right. If I visit /subsite1/subsite2/admin/site-map to create the subsites, then they do inherit from that subsite.
That's even worse than I thought.
Okay, then, if I don't hear any protests, I'm going to change this, so that it inherits from the site node immediately above it. That's the only thing that I think I'd be able to explain to users, and it's the most logical and reasonable solution I can think of.
I think that is the most logical thing to do.
Here is small thread about this. Similar people involved.
On another site I changed the code to inherit from the parent node. In general I think this works better but there is a problem if there is no parent object at the time the node is created. This happens if you create the site map structure first then go back and add the objects. With my quick hack you end up with a tree with no context_id's set. This is even worse than the current behavior.
I can think of three possible solutions to this problem. One if there is no parent use the subsite object_id. Two if you add a parent with existing children fix up the context id's. Three do nothing.
Of the three I'd choose the first since it preserves the existing functionality. Option 2 could change permission on existing nodes.
One other change that would make things better I think is to make the site map page site node aware. Then instead of expanding into a sub site it could send you to the site node site map admin page. This would make it impossible to add nodes into a subsite from multiple places which I think is the real problem.
Why not we just inherit from the nearest parent subsite? Whether you create you application on the Main subsite or in the sub subsite admin site node page. This would of course make subsite more important and may have the drawback of having atleast the root node to be a subsite.
I think its logical since if you mount a bboard and mount a news package under the bboard. The news package will care less about the custom perms of bboard that it inherited. I normally set my perms on the subsite node anyway. I never do it on any other packages. Also our current best practice is to make the tree wide not deep. Lets just get the context_id from the nearest subsite irregardless where you are in the UI.
Although inheriting the context id from the parent seems be good too as its the way the people would expect it since file systems behaves this way. Also you may want to set the perms so sub nodes will inherit it from them rather than create another subsite just to make custom perms via the UI.
I think we should just get the context id from the nearest subsite irregardless where you are in the UI. This should preserve the current behaviour, easier to do and gives us more time to think about this issue. Sorry Lars if you have made the changes already. But I think we need to step back again and think about it more. Also the suggested fix should be enough for our use right now.
Do you mean that subfoo inherits from foobar2 or foobar5 instead of foo.com in this example? If so, what would the rule for selection be?
As an alternative (Lars, ignore if you've completed the changes) perhaps the subsite creation process could display a list of all available subsites, and the admin selects a subsite to be parent by clicking on the link? This would allow much flexibility in how subsites are organized in the directory tree.
I am sorry for the unclear explanation. Based from your example foobar1, foobar2, foobar2, foodir, subfoo and foobar5 will all get the context id of foo.com. Which is the way the current system works. But any site nodes under subfoo will get the context id of subfoo if you are at foo.com/foodir/subfoo/admin/site-map (current behaviour). But if you are at foo.com/admin/site-map any nodes under subfoo will get the context id of foo.com. (I believe this is what Barry has pointed, I haven't tried it personally). My suggestion is that both pages at foo.com/foodir/subfoo/admin/site-map or foo.com/admin/site-map will behave the same way, where in all nodes under subfoo will get its context id.
To rephrase my suggestion. Site nodes will inherit the context id of the nearest parent subsite, irregardless of where the UI is being used. This behaviour is very similar to the current one. We must then futher discuss if we are indeed to make the change of inheriting from the parent side node.
The hierarchical approach has advantages in structured behavior for programming and content purposes, yet...
The current operations-context approach has greater flexibility which can be important when dealing with a complex hierarchy (more than one parent attributes... such as each client under its own branch, and varying in subsite attributes according to "use" templates)
Lars, Jun et al:
Could the UI be arranged so that the parent subsite be chosen via an html select tag that presents currently available subsites? This defers the choice to admins without consideration to operations-context of the admin page or being dependent on a hierarchical structure, while retaining the benefits of computer generated choices for less chance of user input error.
In any case, I appreciate your explanation, Jun, as I had previously misunderstood the current implementation to be hierarchical. =0
"This defers the choice to admins without consideration to operations-context of the admin page"
If I remember accurately, the subsites don't/shouldn't have access to data external to the current subsite environment, therefore the choices of subsites (to make as parent to the new subsite) would be limited to those within the realm of currently operating subsite (operations-context) --any "children" subsites of the current subsite and the currently operating subsite.
This clarification keeps the subsite admin capabilities within the requirements of the subsite package. Permissions and subsite inheritance flexibility are retained.
I committed to the HEAD, because we're very close to a release now, and this is not 100% a bug fix, since there was some discussion about the proper fix.