[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

>

>