Haha. Pretty funny.
As the original Glossary author, I'll pass the "stupid design"
buck onto the ACS 4 designers...
At the time that I created the Glossary Package, I was under
the impression that context_id was worth a
damn. I thought that by setting the context_id of
any object under a package to its package instance I would
actually inherit the security hierarchy of privileges from the parent
object and that there would be logical hierarchy. In fact this is
exactly how the original permissions designers explained it to
me. In other words, I envisioned privilege inheritance something
like this:
Site Wide Admin has admin privilige on Main Site
- Main Site
- Glossary Package Instance (with default permissions set)
- glossary objects with
context_id pointing at
package instance
Too bad the f&*%ers were lying to me!
This hierarchy is fundamentally broken. Instead of setting
the context_id of the package instance to that of
the main site (or any subsite it falls under), IIRC the
context_id of a new package instance is null and the
intuitive security hierarchy is gone.
Permissions are "magically" set to some defaults rather
than inherited. In other words kludged. I believe that you should
only have to set site wide admin priviliges at the top most of the
subsite hierarchy (i.e. main site) have everything below it inherit
it, unless explicity reset on a per node basis.
Believe me, I spent plenty of time mulling over the
permissions problem. The fact is that a Glossary Package
instance can have multiple glossary objects. Therefore you may
want to have individuals that only have glossary_admin privilege on a sub-set of glossary objects, but not
admin privilege on the entire package instance.
Got it?
That being said there are some fundamental unsolved
problems in the Glossary Package's design because
acs-subsites has never lived up to its promises. I prefer
the term "naive" to "stupid".
