Forum OpenACS Development: Subsite Strange Behavior (Cross-post)
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...
Try to check out the tables, I have doubts on those group admin pages.
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):
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.
As I mentioned previously, I am using the 4.5 beta from CVS as of about a week ago, and I'm using Postgres (7.2). I have examined the SQL logs and the tables and I really believe that there's a problem in (at least) how the subsite application groups are being created--not just in the groups user interface (as Jun observed) where they are displayed. Would it be of benefit to the community if I posted the table dumps or relevant SQL snippets from the logs?
Even if everyone thinks the subsite code is working fine and I'm just a a newbie without a clue that information would be useful to me.
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.
Yes, I'm using Postgres.
If there's any additional information that you would like me to provide you with (either on or off list), I would be happy to get it to you.
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.
It would be great if you could post something to the list when you've had a chance to address this (or point me to an SDM link if I should be looking there...)
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.
The Oracle version seems to work though I've not committed my changes yet. You can create subsites and add members to them. There's no way for a user to join a subsite membership group themselves though. There's a "user-join" script but it's never called anywhere, and I've not tested it. In theory you could add a link to this script to the acs-subsite index page and enable the feature.
The PG version is failing because of what appears to be a broken port of a very complex view in the relations code. I'll be taking a look at this in the next few days.
Both versions of acs-subsite appear to have one serious scalabilty issue. The query that pulls up the list of users which an admin can add as members to a site looks like it will run very slow as the site grows. This needs to be investigated further. On the other hand, basic membership checks and the like should be fine.
I need to make sure that whatever I commit is consistent, i.e. do a little testing, even if I don't find the time to fix the errant view this weekend (I think I'll be able to fix it, too, though).
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.
I know that "putting food on table" comes first, and I appreciate the time you've spent working on this.
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.
I disabled "user_profiles" in PG, as it was disabled in the Oracle version. It's in a state of disarray and I'm not sure I like the basic approach (user profiles are a special kind of membership relationship, which mean they show up in the group admin pages).