[geeklog-devel] GSoC - Comments - Edit - Permissions

[Blaine Lang]

Michael,

Why not use the topic perms as the test if a member can edit/delete the 
comments?
 - User posting the comments can edit/delete for a configurable 
timelimit and not after that.
 - if SEC_inGroup('Root') or SEC_inGroup('Topic_Group_Edit') or 
SEC_inGroup(Topic_Owner) then edit/delete

I would think that we would not need a comment admin and a topic admin.
If comments are not in a topic,then they are part of a plugin which we 
call a PLG_checkCommentAdminRights() where the plugin author can have 
basic perm tests or more complex as need.

Even for stories - maybe use a wrapper function that could later be 
appended if the topicAdmin perm is not sufficient.

Then you don't need to store gorup perms per comment - just 
comment_owner_uid

Blaine

Michael Jervis wrote:
> Jared and I are discussing permissions to edit comments in Geeklog for
> the GSoC work he's doing.
>
> Firstly, I beleive the requirement is for users to be able to edit
> their own comments, and for administrators to be able to edit users
> comments subject to security permissions.
>
> So, I've said the following:
>
>   
>>> Geeklog uses unix style permissions. Everything with permissions on it
>>> has an owner and a group. Then there are permissions for owner, group
>>> and anonymous users.
>>>
>>> A comment should be saved with the owner_id being the id of the user
>>> who created it, if authenticated. I don't think we already have one,
>>> but a group of comment moderators or something might be needed.
>>> Comments would then be saved with perm_owner allowing edits and
>>> perm_group allowing edits. Then administrators can be given edit
>>> permissions to comments by assigning them the comment moderator group,
>>> and users can edit their own comments. Anonymous should just have read
>>> permissions of course.
>>>       
>
> Jared's response:
>
>   
>> Does this mean add these rows to the comment table and save this default
>> data each time a comment is submitted?
>>     
>
> I think the answer to this is yes, comments will now need to have the
> standard permissions columns which will have to be set when a comment
> is saved by a user automatically.
>
>   
>> Are there instances where individual
>> comment permissions would change?
>>     
>
> But, would we want the administrator to be able to change the
> permissions mask as they can with stories? So, if a user edits a
> comment, a moderator edits a piece out and the user edits it back in,
> the administrator can change it such that the user can no longer edit
> it? (Perm_owner read only)
>
> And I would assume we'd default existing comments on mature sites to
> owner_id of the user who posted the comment, or root if it was
> anonymous, and perm_owner to read only as with perm_group and
> perm_anon?
>
>   
>> Currently I have something like this this
>> with the comment moderator group having rights to the feature 'comment.edit'
>> :
>>
>> if ( $_USER['uid'] == $A['uid'] && $_CONF['comment_edit'] == 1
>>      && (time() - $A['nice_date']) < $_CONF['comment_edittime']) {
>>     $edit_option = true;
>> } else if (SEC_hasRights( 'comment.edit' ) ) {
>>     $edit_option = true;
>> } else {
>>     $edit_option = false;
>> }
>>     
>
> Having seen this from Jared, I'm half re-canting my earlier comment:
>
>   
>>> Then administrators can be given edit
>>> permissions to comments by assigning them the comment moderator group,
>>>       
>
> I guess the group would actually be the group of the user who posted
> the comment (logged in users most likely) and the group permission
> would be read only. And Jared is right, Administrators/Moderators
> would need the comment.edit permission to edit a users comment, which
> would include the editing of the permissions mask to prevent the owner
> re-editing the comment (assuming that owner wasn't a comment.edit user
> too of course).
>
> Does that make sense and cover all the use-cases people can see? Where
> are the obvious glaring gaps I've left in as a deliberate mistake? ;-)
>
> Cheers,
>
> Mike
>
>