Forum OpenACS Development: Response to Permissions UI Issues

I strenuously disagree...

I don't think you do, because the 'this' I was refering to is the non atomic nature of ACS objects which is present throughout the tookit. As I mentioned, I agree with you that CMS requires work.

[CMS contains (and will contain) pages which accept object_id's and perform actions upon them.] 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.

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?

'Duh'..? I wasn't tutoring I was explaining -- my point of view. I've added back the missing sentence to restate the point, which is that a page designed to work with one type of object may be used to work with another type, and you may not want that.

What if your new object inherited from user or group or apm_package (not so strange, actually...)?

I don't see this changing anything, frankly.

Neither do I, which is my point. I am trying to highlight a class of problem, you were focussing on the example, first CMS, now users.

Obviously reading personal information should require something other than a general "read" permission on the object.

You mean, like "user_read"? Or "secret_read"?

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.

So the approach you're advocating is to take it one by one. Some packages will create foo_read privileges, some won't. Package designers will have to examine every use of any base object they derive from, and simillarly, will have to forsee any re-use made of their object types.

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.

That seems like a good idea to me. Packages go too far at the moment by creating object specific privileges like cal_item_read and calendar_read. If you can't trust the rest of the code in your own package. So yes, a package scope for privileges. Page authors would check for 'read' permission, in the background the check would include the package_key.

Sometimes you do want objects to be non atomic..! I'm thinking of calendar items here. This would need to be an option when applying a privilege.

Whether you go to all this trouble is up to you. Your original annoyance was with all the blah_dy_blah_dy_read privileges. I was just offering the opinion that the folks who wrote the packages at ArsDigita didn't just pull this off the top of their head to annoy you, maybe they had a reason (and the rest of the time they were copying by example, because this is subtle and tricky and there are no guidelines).