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

Currently general_comments_create is a child permission of create and is granted on security_context_root by the general_comments install.

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?

Collapse
Posted by Dave Bauer on
Jeff,

What exactly is your proposal?

Should general_comment_create be one of the few instances where we need an additional permission to the built in ones?

Collapse
Posted by Jeff Davis on
Yes. the general_comments_create permission would still exist, would not be a child of create, and would not be granted on the default_context (I mispoke when I said it was granted on security_context_root).

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.

Collapse
Posted by Don Baccus on
Since this is a permission granted to the parent object it makes no sense to hang it onto the default context.

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

Collapse
Posted by Andrew Grumet on
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?

Collapse
Posted by Jeff Davis on
Andrew, I did not really think about what it should be a child of. I think an :"annotate" parent for things that are sort of meta makes sense (I would add relate and categorize to things you might want to do that are "annotation like").

Does anyone think it should stay a child of create?

Collapse
Posted by Don Baccus on
I guess I was a bit cryptic above :) I thought about suggesting a global permission "comment" ... but I like your word ... "annotate" if we're going to generalize the notion of a global permission to add additional information to an object...

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 :)

Collapse
Posted by Jeff Davis on
I think the annotate parent for these is sensible since often you want to just grant them all together and that makes it easier to do, but we definitely need seperate comment from rate since I would like to permission them seperately.
Collapse
Posted by Don Baccus on
Yes, thinking more about it I agree, we may have stumbled on one of those rare instances where private permissions make sense ...

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.

Collapse
Posted by Don Baccus on
Just to be formal ... I approve the notion of adding a global "annotate" privilege and changing the privilege hierarchy appropriately to track this change. Should be simple, including the upgrade script.
Collapse
Posted by Jade Rubick on
I also approve.
Why is the new annotate privilege not child of the admin privilege but simply a new root privilege?

I was just denied commenting on a blog entry as site-wide-admin on a fresh 5.2 install, while it is allowed for the Unregistered User, this seems a bit awkward.