Forum .LRN Q&A: General comments create and dotLRN
General comments grants registered users general-comments-create privilege. However, dotLRN communities don't inherit from main site so users were not getting permission to create general comments.
The fix I came up with was a dotlrn-general-comments-config.sql file that makes general-comment-create a child or read because I want user to be able to comment on any file they can read.
Do people have suggestions for other approaches?
--Allows users to use general comments on anything they have read access on.
--This is necessary because most of dotLRN does not inherit from main-site where
--general_comments_create given to registered users.
Where Tilmann and I discussed this issue in relation to bug-tracker.
What we did was say that if you can read, you can also comment. That's pretty fair in the general case, that's the purpose of community. You normally don't want a community with first-order citizens who can read and comment, and second-order members who can read but not comment.
My original suggestion was to create a standard 'feedback' privilege, which belongs to acs-kernel, so it's available for all modules to use. But I'm not so sure anymore. I'm all for keeping the set of privileges really small. Perhaps if we make 'feedback' a child of 'read' by default, so you can choose to pretend 'feedback' doesn't exist if you want, and if you want something more specialized, you can do that.
I definitely feel like 'general_comments_create' is a miscreation of a privilege, and that general-comments should be 'fixed' so it either looks for 'read' or for a new 'feedback' privilege.
But I dislike having it a child of "read". While in general we may feel that our sense of "community" should allow anyone who can read an object to comment on it (if comments are allowed at all), I do not believe the toolkit should impose this paradigm.
I'd much rather do something like have dotLRN have "feedback" set on itself for all registered users when it is mounted (which it can do via the APM post instantiation callback) and have packages then check to see users have this privilege.
We could also have the main site set up the same way.
This would make the default case be that anyone can comment on an item they can read but would allow one to, say, mount a subsite, break inheritance, and then assign "feedback" to a subset of users.
I don't see that providing this level of flexibility is a bad thing.
In any event, I see this as a well-functioning temporary solution, and if it works, I don't see any big deal here.
I haven't looked into this but offhand it doesn't seem like it would be all that hard to do right.
Now ... I just noticed that Open Force added new file storage objects that aren't stored in the CR, something I'd missed earlier. Wonderful. I think we either need to throw out the CR or use it, this every-package-decides-for-itself approach is messy.