After having taken a serious look at the permission system and how we might use it in dotLRN, I think I might have a couple of thoughts to contribute.
1. The UI for permissions is fairly inexistent. That's a problem. No doubt about that. But that's not a design problem, that's just a missing chunk of code. We need to write it. That's all there is to say about that :)
2. I actually think the current design is quite good. I see very little that isn't doable in the current system (one caveat is my point number 3). I think there is certainly an issue of formalizing HOW one is SUPPOSED to use the permission system. It makes a lot of sense to have hierarchical permissions and to ALWAYS root them at admin, read, write, or create (the top-level ones). A properly working context_id mechanism with security_inherit_p used correctly is in fact pretty good: it's the leaf-level code that should decide whether to allow inherited permissions from above, thus setting the proper context_id for a good security inheritance architecture, and the appropriate security_inherit_p depending on whether you want to inherit or not in a particular case.
3. in dotLRN, we have hit an interesting situation. By default, the site node system is supposed to mount new packages and set the context_id to be either the parent node, or if an object is attached to the parent node, that very object (which is, AFAICT, always a package instance). Now, dotLRN uses a lot of existing packages, like bboard, which automatically set their data's default context_id to be their local package_id: a new forum gets created with context_id set to the bboard's package ID. That is a perfectly correct default behavior, and dotLRN simply needs to deal with that. So, a course in dotLRN is a subsite with packages instantiated and mounted underneath it. Thus, we want the package instances mounted at a particular course mount point to inherit permissions from the course itself. But does it make sense for a dotLRN course to be an extension of package_id so that it can be directly mounted at a site node? I'm not so certain... Then does it make sense to instantiate a package that inherits from something totally different, like maybe a dotLRN course (which is a type extension of acs_group)? I think this can be resolved, but I'm throwing it out there to see what people think.
In general, I think improvements definitely need to be made w/ respect to UI and optimization, but I'm not seeing any clear problems with the design. Maybe I'm missing something?
