Forum OpenACS Development: Response to Permissions UI Issues
</i></blockquote>
I strenuously disagree. The current behavior of the CMS is neither feature nor bug, but rather historical artifact (it began standalone and still takes the POV, if you will, that it and only it generates content).
<p>Users shouldn't muck with content object created by, say, the SDM in the CMS. Random mucking around in the CMS will likely break behavior in the package actually creating the content. Such packages will likely have assumptions about the structure of the content tree it is maintaining.
<p>The CMS and CR are too closely coupled, and that should be fixed. It was OK when the CMS was a standalone application. I view this close coupling as an indication that the integration of the CMS was done hastily and is incomplete. Just as I view the fact that the CMS maintains its own login code (requiring a screen name) rather than depend on the standard ACS user login/management code as a symptom of hasty and incomplete integration.
<blockquote><i>
An object_id is a revision_id is an image_id is a wp_image_attachment_id. The same ID number appears in many tables which belong to many packages.
</i></blockquote>
Duh. You don't think I know that? This isn't a case of my not understanding how things work. This is a case of my *disagreeing* with how things work. So let's skip the tutorial snippets, OK?
<blockquote><i> What if your new object inherited from user or group or apm_package (not so strange, actually...)?</i></blockquote>
I don't see this changing anything, frankly.
<p>For starters, I'm not suggesting that we remove the capability for packages to add their own permissions or hierarchies (I'm starting to sound like a broken record but at some point hopefully you'll understand this). I'm simply suggesting that the administration of permissons would be a lot simpler if we had a reasonable set of system-wide permissions available for use by packages.
<p>I fail to see how having 100 different flavors of "read" permission for 100 different packages can be considered a user friendly approach.
<p>One such permission might deal with personal data deemed private that should only be viewable by a subset of users. Obviously reading personal information should require something other than a general "read" permission on the object. This really should be true for type "user" itself regardless of issues introduced by derivation, frankly.
<p>If one requires a separate permission to view private information, then granting "read" to an object derived from "users" won't expose that information.
<p>This may not be the specific case you had in mind but I suspect I can come up with a solution to any specific example you care to come up with that doesn't require each and every package in the world to have its own custom "read", "write" and "admin" privilege.
<p>If we *do* need this fine level of granularity perhaps some method of scoping permissions to a particular package is needed. That's what's being done - very clumsily - by the unenforced naming convention that's now being used in a very ad hoc manner. The fact that the current convention is both ad hoc and unenforced makes it both error-prone and butt-ugly.
