Forum OpenACS Development: Making Categories subsite aware

Collapse
1: Making Categories subsite aware
Posted by Stan Kaufman on 07/08/06 01:06 AM
The Categories package isn't currently subsite aware; it is impossible to create a category tree that is restricted to only a single subsite. A good use case where having subsite-specific Categories would help (and the one that led me to this) is the use of Categories as the organizing mechanism for xowiki pages. It is clear that subsites would want to create and maintain their own topics for pages and not have other subsites modifying them or even seeing them. I can imagine that other packages that use Categories would see similar benefits.

So it seems that a category tree should have 3 potential scopes:

  • site-wide: any subsite (including the main site) could access
  • subsite-main site only
  • subsite only

The latter two are really the same, since the main site is just a special case subsite. But the distinction is there.

It appears that Categories was designed to be subsite aware, since the category_tree table has a column site_wide_p. However, other than checking permissions, this value isn't used by the package.

Since category_trees are acs_objects, it seems a good use of context_id to store the subsite_id for every category_tree created (if needed by a client package like xowiki).

To handle the case of packages that don't care about making subsite-specific categories, Categories should default to the main site subsite_id.

I've posted a bug about this (also it covers a few other small problems I found) as well as a patch created via a cvs diff against oacs-5-2. I think that the patch fixes everything, but I'd like it reviewed and tested -- particularly in installs which use Categories for other purposes besides xowiki.

If this looks OK to people, I'll commit it. Thanks.

Collapse
2: Re: Making Categories subsite aware (response to 1)
Posted by Tracy Adams on 07/08/06 05:19 AM
A use case from Boston Museum of Science:

a) The dotlrn-ecommerce system has a bunch of reasons to use categories, including:

--- some packages like expenses and scholarships
--- the ability to use extensible categories to categorize the courses offered

When we originally built the system, the site-wide categories pages worked fine as collectively, these category trees all involved dotlrn-ecommerce

b) We are expanding the Museum of Science is expanding their system to manage all their public forums, with the additional capability of categorizing threads. Each forum has a category tree.

As different people maintain "a" and "b", seeing all category trees in one place poses some confusion.

I'm not sure "subsite-aware" is precisely ideal (if you really mean you have to segregate by different subsite package)....The user databases, general site map, etc. are the same so these are not different subsites.

Ideas that would work for them would be to have category administration pages that would show all the categories trees for a given package and/or all the category trees for a given package and anything lower than that in the site map. (then, as specific case of this would be category trees for a specific subsite package and/or below).

>Since category_trees are acs_objects, it seems a good use of context_id to store the subsite_id for every category_tree created (if needed by a client package like xowiki).

So more specifically, my suggestion would be to have the context_id to store the PACKAGE_ID for every category_tree created - so then you'd have the flexibility to show category trees by ANY package, including subsite.

Collapse
3: Re: Making Categories subsite aware (response to 1)
Posted by Torben Brosten on 07/08/06 08:21 AM
I agree with Tracy. Though not yet implemented, the suite of ecommerce-G2 packages would really benefit by having categories' context_id set to a package_id also.
Collapse
4: Re: Making Categories subsite aware (response to 1)
Posted by Gustaf Neumann on 07/08/06 02:00 PM
Providing a context_id is a great idea.
Collapse
5: Re: Making Categories subsite aware (response to 1)
Posted by Stan Kaufman on 07/08/06 04:21 PM
Adding even finer granularity to Categories' context is an excellent idea. So when creating a category_tree, one could define it to be:

  • site-wide: visible to all subsites and applications ie all packages (subsites are packages themselves, but conceptually users see them as containers of packages/applications)
  • subsite: visible to all applications installed within a subsite (ie below a given subsite in the site map -- whether the main site or any other subsite)
  • application: visible to only a particular package

I think implementing this beyond what is already done will be fairly trivial -- just modify /lib/tree-form.tcl to provide an appropriate UI listing these various options for user selection. Also changing "subsite_id" to "context_id" throughout the package so as to make clearer that any package_id can be used for the context. I'll give this a bash in the next few days.

Collapse
6: Re: Making Categories subsite aware (response to 1)
Posted by Stan Kaufman on 07/08/06 05:23 PM
BTW the use case for a subsite-wide level of visibility -- as opposed to an application level such as what you're describing for ecommerce -- is this: a subsite created for management of a large clinical trial (one of many different projects each of which has its own subsite) deals with "enrollment issues", "data collection issues", etc etc. These categories pertain to discussions that would occur in forums, events in calendars, and descriptions in xowiki pages. These categories do not pertain to other subsites in the same site organized for other projects/purposes, such as a subsite used by senior management of the clinical research organization for personnel issues, etc; nor do they match categories used in the public-facing stuff in the main site.

If only site-wide and application-level visibility is supported, then the category trees would need to be duplicated for each of the applications -- forums, calendars, xowikis, etc within the subsite -- which is error-prone and unnecessary. The subsite-wide level allows all these applications to share the categories without having them leak out to other subsites or the main site.

Probably this was clear, but I thought I'd make it explicit.

Collapse
7: Re: Making Categories subsite aware (response to 1)
Posted by Tracy Adams on 07/08/06 05:27 PM
Yes, I think I deduced that.

I think using package_id instead of subsite_id would cover both as the subsite use case would be a subset of the package_id use case...

Collapse
8: Re: Re: Making Categories subsite aware (response to 7)
Posted by Don Baccus on 07/09/06 01:19 AM
Yes, context id should be set to the package id. As you say, that makes the subsite case a special case within the more general solution.
Collapse
9: Re: Making Categories subsite aware (response to 1)
Posted by Stan Kaufman on 07/11/06 01:32 AM
I've posted a patch (against oacs-5-2) that accomplishes what we've discussed, I believe:

  • Client packages can pass in a package_id (subsite or a mounted application) that sets how Categories operates -- with a default to the main site subsite_id if a package doesn't want to use this capability.
  • The add/edit UI enables setting site_wide_p as well as the context_id from a widget that includes the relevant subsite plus any installed applications at that subsite.
  • The main index (/cadmin/index.tcl) lists the scope of category trees (site-wide, subsite, application -- and which subsites and applications).
  • The available category trees that can be mapped by a client package are determined by these settings -- a package can see these trees:

    • site-wide trees
    • subsite trees where that package is mounted
    • trees only for that package

    All other trees are now invisible to client packages.

There are a few funky things about this:

  • Trees set to site_wide_p = 't' can also have a context_id set to some package_id (either a subsite or an application), but the context_id is ignored by Categories; site_wide_p supercedes the context_id. This works out OK, but conceptually it's muddy; there isn't a clean, mutually-exclusive set of states for trees using this mechanism of (site_wide_p + context_id). I don't see any reason to try to re-do the whole schema, however; this is kind of a work-around, but it works, so that presumably is good enough, eh?
  • The context bar links aren't entirely sensible. Since Categories is a singleton, when a user navigates there from an application mounted in a subsite, there is a link back to that application, but not to the subsite itself. Seems that there are several options for the context bar:

    • Leave it as it is.
    • Make it: Main Site >> Subsite Name >> Categories >> Package Name >> Category Management (etc)
    • Make it: Main Site >> Categories >> Subsite Name >> Package Name >> Category Management (etc)

Anyway, this code appears to work correctly here, but it needs to be dropped into other uses of Categories, so please do so and post any problems. If it works/looks OK, then someone (OCT?) should let me know and I'll commit this.