Forum OpenACS Improvement Proposals (TIPs): Tip #74 (Approved) Fix general_comments_create permission.

For our current work we need to be able to enable and disable commentability per item which means we need to revoke the permission on security_context_root and also since we can't revoke create to turn off commentability we have to make general comments create not a child of create.

It seems to me that any site using comments sensibly would need to do this hence the TIP.

Comments?

I don't see how you can permission comment create on an object which inherits create from the subsite without a seperate permission and I see a real need to be able to turn commentability on and off.

Commenting on content seems fundamentally a different
thing than creating new content ... so is rating
content ...

Right, I had to stare at the privilege tree for a minute to get this, but you're supporting the notion that general_comments_create shouldn't be a child of create.

What should general_comments_create be a child of, if anything? A new "annotate" privilege that is also a parent of ratings_create?

But why a child general_comments_create or general_ratings_create in that case? We want to get rid of needless child perms as much as we can. I guess in this case one could argue that we want greater granularity but then, given the global nature of the two packages (if we ever do a decent job of integration of these services with all content-producing packages) why not just have "comment" and "rate" as separate global permissions?

And perhaps "categorize", too?

It's fine of course for these packages to create the new perms, I'm just suggesting they be considered global.

Which is actually more or less what Jeff's proposing, I'm just rambling out loud :)

Here's the difference from the garbage cases that litter the tool kit: we have tons of "foo_read" privileges which are in no way a subset of the global "read" privilege. Really just a space and time wasting synonym.

But in this case ... "annotate" is a global concept for a family of related but separate actions, which include "comment", "rate", and "categorize" (at this point in time, any others?). These three actions have different semantics (unlike "foo_read") so logically should exist as separate permissions.

But they're closely related so it makes sense to give them a taxonomic parent.

Does this make sense? If so, that's what I'd like to see us do ... add a global "annotate" to the core set of perms and have gc/gr/categorize add their private perms appropriately so we can have finer-grained control when appropriate.

Thus far I don't see anyone saying these should be children of "create" ... [content] creation and [content] annotation are (IMO) fundamentally different in their semantics and I don't see anyone arguing against that idea.