Forum OpenACS Q&A: Re: Is this a case for subsites?

Collapse
Posted by Janine Ohmer on
To expand on this, I have a question about how subsites work. I've been experimenting with them and I'm not sure if I've found a bug or a feature. :)

I made a subsite, then from it's admin pages I made a group type and group. Now when I go to it's Permsissions page, there is a row of check boxes, with no name listed, above the System Administrators line.

I have a second subsite, so I went over to see what it was doing. It also sees the group type and group, but does not have this mystery permission.

I've looked at the code and can see that this is a nameless acs_object, but have not yet figured out how it came to be or why it has no name. My group and group types are both named.

This code was checked out on the oacs-5-2 tag a couple of days ago, so it doesn't correspond to any release.

Any suggestions? Do I need to go back to the 5.2 tarball?

Collapse
Posted by Janine Ohmer on
I figured out the problem, but not how to fix it.

In acs-subsite/www/admin/groups/new.tcl, the name of the new group is collected from the user in groups.group_name. This value ends up stored in acs_object through some form builder mojo in groups::new (acs-subsite/tcl/group-procs.tc) that I don't fully understand. After that it gets run through convert_to_i18n, but the same mojo does not happen there, and I can't seem to get at the value myself to pass it on to convert_to_i18n. The end result is that my nice group name gets converted to an i18n key with a blank message associated with it.

I'll file a bug. Fortunately, for my purposes I can comment out the call to convert_to_i18n, since I don't need it.