Define permission allowing Community Members to delete ONLY their own comments

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 6.0.5 GA, 6.0.12 EE, 6.1.0 CE RC1
• Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1, 6.0.X EE
• Component/s: Collaboration, Collaboration > Blogs, Collaboration > Wiki
• Labels:
  • QA-R
• Branch Version/s:
  6.0.x
• Backported to Branch:
  Committed
• Similar Issues: Show 5 results ; ;

  LPS-24697	Comment Permissions - a user cannot edit / delete his own comments and cannot edit / delete the comments of other users if given the permission to do so
  LPS-15632	Doc Library: Community members do not have the ability to update or delete their own comments
  LPS-25286	Improvement for page comment portlet permissions
  LPS-13647	Communities Architecture - Pre-Defined Community Types
  LPS-2938	There is no way to give permissions to edit / delete comments in 'Web Content Display'

Hi,
I have found that I cannot define a permissions so that Community Members can delete only their own comments on Blogs and Wikis.

I defined the following permission for the Community Member role for blogs:
Community Member > Blogs > Update Discussion
Community Member > Blogs > Delete Discussion

However, this allows the community member to delete/edit the comments of all other community members. Is there a permission I can define to only give community members the ability to edit/delete their own comments?

[Luyang Tan]

FAILED Manual Testing using the following steps:
1. create a site called 'aaa',click action,manage page,
add a page called 'aa'.
2.create two users,user1 and user2,make them all the member of the site.
3. click role,click action near member's site role,assign
blog entry→update discussion and delete discussion permission ,then save it.
4.go to 'aaa',add blog portlet,add a blog.
5.sign out test,sign in user1.add a comment at the blog.
6.sign out user1,sign in user2,you can see user2 can delete and edit user1's comment.

Reproduced on:
Tomcat 6.0.32 + MySQL 5. Firefox 6. 6.0.12 EE.
Tomcat 7.0.21 + MySQL 5. Firefox 6. 6.1.x Revision 89720.

Failed on:
Tomcat 7.0.21 + MySQL 5. Firefox 6. 6.0.x Revision 89993.
community member can still delete or edit other member's comment.

Fixed on:
Tomcat 7.0.21 + MySQL 5. Firefox 6. 6.1.x Revision 89953.
community member couldn't delete or edit other member's comment.

[Julio Camarero]

Hi Luyang,

in order to test this improvement, you shouldn't change the default permissions for the Site Member. If you give permissions to update and delete discussion to site members, they will be able to update and delete all the comments.

Instead, you should leave the permissions for site members as they are.
By default, users won't be able to edit their own commments.

However, if you add the following property to your portal-ext.properties and restart.
discussion.comments.always.editable.by.owner=true

then every user should be allow to update and delete only their own comments.

Could you please check again? Sorry for not adding enough explanation in the ticket before.

[Luyang Tan]

Passed Manual Testing using the following steps:
1. add the following property to portal-ext.properties and start liferay.
discussion.comments.always.editable.by.owner=true
2. create a site called 'aaa',click action,manage page,
add a page called 'aa'.
3. create two users,user1 and user2,make them all the member of the site.
4.go to 'aaa',add blog portlet,add a blog.
5.sign out test,sign in user1.add a comment at the blog.
6.sign out user1,sign in user2,add a comment at the blog.

Reproduced on:
Tomcat 6.0.26 + MySQL 5. Firefox 7. 6.0.5 GA.
Tomcat 6.0.32 + MySQL 5. Firefox 7. 6.0.12 EE.
Tomcat 7.0.21 + MySQL 5. Firefox 7. 6.0.x Revision 89850.
Tomcat 7.0.21 + MySQL 5. Firefox 7. 6.1.x Revision 89695.
user2 can not edit or delete both user1 and user2

Fixed on:
Tomcat 7.0.21 + MySQL 5. Firefox 7. 6.0.x Revision 89993.
Tomcat 7.0.21 + MySQL 5. Firefox 7. 6.1.x Revision 90300.
user2 can edit or delete user2,but can not edit or delete user1.

[Vicki Tsang]

This is being bulk closed in preparation for the new workflow.