Forum .LRN Q&A: General comments create and dotLRN

Posted by Caroline Meeks on 12/09/02 09:16 PM

I am adding general comments to file-storage in dotLRN for SloanSpace. I ran into a issue with permissions.

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.

begin
acs_privilege.add_child('read','general_comments_create');
end;
/
show errors

2: Re: General comments create and dotLRN (response to 1)

Posted by Lars Pind on 12/10/02 09:39 AM

See the bug here:

http://openacs.org/bugtracker/openacs/bug?bug%5fnumber=10

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.

/Lars

3: Re: General comments create and dotLRN (response to 1)

Posted by Don Baccus on 12/10/02 09:01 PM

I agree with the notion of a "feedback" or "comment" privilege at the acs-kernel level (I've been arguing for a much smaller set of perms in general for a long time and am not about to change my mind now!)

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.

4: Re: General comments create and dotLRN (response to 1)

Posted by Lars Pind on 12/11/02 01:30 PM

If there's a simply way to simply grant everybody in dotLRN general_comments_create, the way they currently have read/write/other permissions, I agree that would probably be nicer.

In any event, I see this as a well-functioning temporary solution, and if it works, I don't see any big deal here.

5: Re: General comments create and dotLRN (response to 1)

Posted by Don Baccus on 12/14/02 10:27 PM

The key word here is *temporary*. Temporary hacks have a tendency to linger on perpetually.

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.