I initially posted this on the Testing forum, but I believe it
deserves a larger audience than that, so I'm repeating it here.

I'm using the 4.5 beta release from CVS as of about 1 week ago.

This problem is observed when I create two subfolders of the main
site, say foo1 and foo2, and then mount an instance of Subsite at each
folder (using the "New Application" option).

When the first instance is mounted, OACS appropriately creates an
application group for the subsite and an apm_package instance of
acs-subsite.  However, when the second instance is mounted (foo2),
OACS does all of the above PLUS creates a composition relation between
the foo1 and foo2 application groups.

This seems incorrect to me.  These subsites are at the same "level."

Why should one be "composed" of the other just because one was mounted
before the other?  (Note: I specified the "New Application" mounting
method both times)

Additonally, I notice that if I visit the group admin pages for the
site and subsites I can only "see" the following groups defined:

At Main Site Group Admin: No Groups Defined

At Foo1 Group Admin: Main Site Parties, Foo2 Subsite Parties

At Foo2 Group Admin: No Groups Defined

I would have thought that ALL groups would have been visible from the
Main Site admin pages.

It looks to me like maybe the subsite code is assigning the "reverse"
of the relations that it should be but I hope that someone who is up
on this will comment...

Thanks Jun.  I think you are right that the group admin pages are lacking, but in this case I have verified that the fault really is in what's being done to the underlying tables.

For now, I'm going to abandon any reliance on the application_group stuff and scope my subsite by adding a package_id column to my data to distinguish which subsite it "belongs" to.  It will be less flexible than using application_groups but a) I can understand it, and b) I'm not enough of an expert to fix the Subsite code.

This solution was recommended in this old AD thread (at the very bottom):

http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000KO5&topic%5fid=175&topic=ACS%20Design


It also points out the limitations of the package_id approach.  Since there's no mention of application_groups, I'm assuming that this discussion came along before that notion was introduced.  Especially because the application_group scheme (if properly implemented) could elegantly solve some of the context_id/permissions problems that are discussed there.

Sorry ... I've been really busy with client work and haven't had time to take a look at your subsites issues.  I know a lot of other folks are really busy at the moment, too ... unfortunately the toolkit's gotten to the point where a fair number of people are using it to build sites for customers.

I should've held off on starting this release process for another six months, then people would be afraid to use it and volunteering for openacs instead! :)

(I'm just joking!  Honest!)

I hope to find time this weekend to take a look, myself.  My first check will be to make sure that the Oracle and PG version work the same way.  I'm assuming you use PG?

If I'm right (you're using PG) and the Oracle and PG versions show differing behavior, then we have a porting bug.  If the Oracle and PG versions show the same behavior then it sounds as though there are some design flaws.

Not too many folks are using acs-subsite AFAICT.  It's a very useful feature and we need to make it work right, certainly, but ... relatively few sites need full subsiting.  I think once people start playing with acs-subsite (when it works better, anyway!) they'll start thinking up novel ways of using it but thus far it's not been heavily used.

My first plan of attack will be to look at Oracle and PG behavior to see if they match, then, thanks ... if I need more info I'll post here.

OK ... I've dug into this and I've hit the jackpot ... Oracle and PG *both* fail, but in different ways and for different reasons ...

1. The Oracle version inserts the new group but it doesn't show up in the "group element map" view and views built on it, which means you can't see it from the UI (this may explain Jun's impression that the UI is broken and that you need to check the underlying tables themselves).

2. Dave's diagnosed the PG version correctly ... there's a tree query that looks like it might've gotten inverted when it was ported to PG.  This is easy to do using our tree keys, though there are now some easy ways to find parent nodes.  I need to look at the original Oracle query, too, I think it might be more complex than is required but until I fix #1 I'll leave that.

I won't be fixing these problems immediately but will try to do so in the next couple of days.

I've made my first round of fixes which causes the group hierarchies to be built correctly.  The Oracle version worked for subsites mounted below the main site (because the "find the parent" query, though incorrect, was at least incorrect in a way that always returned the main site node).  The PG version was mostly just backwards.

There was also a cart-before-the-horse problem in the subsite mounting code that caused the corrected queries for both RDBMSs to fail.  This had been masked in the Oracle version by the bug that caused it to always return the main site node.

Now that the application groups and the composition relationships are being built correctly I see that the site map page in PG is incorrect, and adding users doesn't seem to work.  I haven't checked the Oracle version yet.

I've been very busy this week with client work so haven't had time to get back to it.  My plan is to spend part of tomorrow (Sunday) plugging away at Phase II Phixing...

I've been holding off on committing until I have something that works more or less coherently.

Don, I know you aren't finished with this, but I'm wondering if you would be willing to post the changes you've made so far.  Even if it's incomplete, any improvement at all would me move ahead a great deal.

Dave ... if you're up to some hairy query hacking and want to take a look, "rc_parties_in_required_segs" in "acs-kernel/sql/postgresql/rel-constraints-create.sql" appears to be the view that's giving incorrect results.

Let me know if you're going to dig into this so we can coordinate our efforts.

If you don't have time or feel a bit overwhelmed by the view and the views it depends on that's fine, just thought I'd give you (or anyone else who's interested) a pointer to the problem.

Our posts crossed...

WRT the query: rc_parties_in_required_segs.

I'll try to "pull my own weight" on this by having a look at it.  However, I've had a lot of trouble so far just inferring what the system is _supposed_ to do well enough to know when it's working/not working...  I'll try to determine the query's purpose from the context but if you feel like mailing me a one or two sentence description that might make it easier for me.

Thanks again for your work on this.