Forum OpenACS Development: Site nodes inherit permissions in a strange way

1: Site nodes inherit permissions in a strange way

Posted by Lars Pind on 09/12/02 09:38 AM

On collaboraid.biz, I've created a subsite at /extranet, under which
is a subsite for each of our clients, under which, again, is mounted
forums, bug-tracker, blogger, whatnot.

For example:

/extranet/myclient/forums

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
subsite individually.

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
inheritance hierarchy.

/Lars

2: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/12/02 09:51 AM

Hi Lars,

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]');

3: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Lars Pind on 09/12/02 10:04 AM

Thanks, Jun.

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.

Like this:

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.

/Lars

4: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/12/02 11:03 AM

Hmmm... I have a similar problem.

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?

5: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Barry Books on 09/12/02 12:52 PM

The last time I looked into this (ACS 4.2) the nodes you create inherit permission from the subsite you create them in. The reason for this is the site map code is part of the subsite and when you create a node the code puts the object_id of the subsite into the context id of the node you created.

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

6: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Lars Pind on 09/12/02 01:23 PM

Barry,

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.

/Lars

7: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/12/02 02:34 PM

Lars,

I think that is the most logical thing to do.

Here is small thread about this. Similar people involved.

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004Kz&topic_id=12&topic=OpenACS%204%2e0%20Design

8: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Lars Pind on 09/12/02 02:40 PM

Funny, I had no recollection of that thread :)

/Lars

9: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Don Baccus on 09/12/02 06:06 PM

I don't remember the old thread, but having it inherit based on where you are in the site map when you create it is non-intuitive. Having it inherit from its parent node makes a lot more sense, so Lars, IMO fire at will!

10: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/13/02 08:27 AM

My that is really bad. We have some sort of mind block or something. The good thing is we will finally have something done about this. I guess it is safe to change it since there are only 4 people seems to have noticed and concerned (and forgotten) about this issue in the span of 6 months. Go! Go! Go!

11: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Barry Books on 09/13/02 01:55 PM

I think the intent of the original design was to allow different admins for subsites. For example my wife runs a site called judypaul.com and hosts other sites in the same ACS instance. I added some code so that domain names map to subsites. This allows her to give a subsite 'admin' account to each user. Since they only admin a subsite they do not see the strange behavior noticed above.

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.

12: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/14/02 10:50 AM

I thank Barry for pointing this out. Especially the situation wherein you will have no context_ids.

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.

13: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Torben Brosten on 09/14/02 11:31 AM

Jun, I do not understand the difference between "the nearest parent subsite" and "parent subsite" that seems to be the basis of your suggestion. Assuming foobars are subsites in the following tree:

foo.com/foobar1

foo.com/foobar2/foobar3

foo.com/foodir/subfoo

foo.com/foobar5

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.

14: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Jun Yamog on 09/14/02 06:15 PM

Hi Torben,

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.

15: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Torben Brosten on 09/14/02 11:32 PM

Jun, thank you for the clarification. I think I understand now. You are basically suggesting that new subsites get attributes from the new subsite's position in the directory tree (hierarchical --next highest subsite), instead of from the location of the admin page being accessed (operations context --where the "command" is executed).

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

cheers,

16: Response to Site nodes inherit permissions in a strange way (response to 1)

Posted by Torben Brosten on 09/15/02 01:30 AM

This statement I made is not entirely correct:

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

17: Re: Site nodes inherit permissions in a strange way (response to 1)

Posted by Lars Pind on 12/20/02 02:59 PM

I fixed this on the HEAD. Change applies to acs-subsite/www/admin/site-map/package-new.tcl, and is pretty simple.

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.

/Lars