This is another method to handle the same problem: http://drupal.org/node/79693
This bug its, at this moment, in Drupal 4.7 and 5.1. But I'm patching for 4.7.
__________________________

In this case, I don't add any feature. Only correcting the bug itself.

The bug is, that, if a user that is not allowed to post a comment without approval, in some cases, HE CAN edit their comments without ANY approval by the admin.

Adding a "edit approval queue" is a feature itself (and very interesting) will be the better solution for this problem, but I believe that this feature must be in future versions of drupal.

_________________________________

My code don't allow users to edit their posts, if they doesn't have the "post comments without approval". Because if they can't post comments without approval, then, they aren't allowed to edit their posts without approval too.

This patch applies only to the comment.module, and only to the "comment_access" function.

Here is the original function at Drupal 4.7.6 comment.module:

function comment_access($op, $comment) {
   global $user;

   if ($op == 'edit') {
     return ($user->uid && $user->uid == $comment->uid && comment_num_replies($comment->cid) == 0) || user_access('administer comments');
   }
 }

And the modified version:


function comment_access($op, $comment) {
   global $user;

   if ($op == 'edit') {
     return ($user->uid && $user->uid == $comment->uid && user_access('post comments without approval') && comment_num_replies($comment->cid) == 0) || user_access('administer comments');
   }
 }

Note that, I've only added a "&& user_access('post comments without approval') " to the return line. This is the unique modification needed to correct this bug.

_________

PD: The code is untested yet. If someone test it under Drupal 4.7.6, reply to this issue.

CommentFileSizeAuthor
#1 comment.module_71.patch512 bytesdeavidsedice

Comments

deavidsedice’s picture

Version: 4.7.x-dev » 5.x-dev
StatusFileSize
new512 bytes

I've found today that Drupal 5.1 has the same problem. I've created a patch to fix it.

drumm’s picture

Status: Needs review » Needs work

I would expect the ability to edit comments, but they would go back into the moderation queue. A message explaining why the comment just disappeared or warning that the comment will disappear would need to be shown.

errement’s picture

Version: 5.x-dev » 6.6

Having same issue with Drupal 6.6. What do you recommend?

weimeng’s picture

Title: Users not allowed to "comment without approval" CAN edit their comments without approval of any kind. » Users that can't "comment without approval" can bypass it by editing their comments after initial approval
Version: 6.6 » 6.x-dev
Assigned: deavidsedice » Unassigned
Status: Needs work » Active

Changing issue title to better reflect what's going on here, resetting status to active and changing version to 6.x HEAD. Might want to move into 7.x if appropriate.

A user can potentially post an innoculous comment which the site admin will approve, then subsequently edit the comment to anything else he wishes, including malicious or unappropriate content.

sivaji_ganesh_jojodae’s picture

Status: Active » Closed (duplicate)
weimeng’s picture

Status: Closed (duplicate) » Active

That issue describes a different problem.

This is more of a security/design issue caused by the fact that there is no "Edit comments without approval" permission.

weimeng’s picture

Version: 6.x-dev » 7.x-dev

Setting to 7.x for more attention.

I'm aware it might be too late or not important enough an issue, please change the version as necessary.

aaronbauman’s picture

Priority: Normal » Minor

Is this really a bug?
Yes, the permission "edit own comments" opens the flood gates, but buyer beware right?
The comment permissions behave the same way as the "edit own" node permissions, and administrators always need to be careful with how they grant them.

Adding a possibly cumbersome layer of revision moderation to the relatively simple comment system does not seem like the answer. IMO this is a feature better addressed by contrib.

IMO it boils down to an interface issue that can be solved with a better description of the permission itself, or using D7's "restrict access" key in comment module's hook_permissions.

marcingy’s picture

Version: 7.x-dev » 8.x-dev
Category: bug » feature
Priority: Minor » Normal

Marking as a feature request, this is really adding a new permission or a new combination of permissions. And I agree should core really be doing this?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Wonder if this is still relevant for D10?

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Nearly another two years and there is no discussion or support for this idea.

The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.

If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.