For each protected form, we should be able to expose a configuration option (checkbox) that allows to individually configure whether subsequent edits of a post should be checked, too.

This allows to avoid the potential problem that the reputation of content moderators is affected when editing a post.

For example, this scenario might apply for wiki_node_form, but not to article_node_form. For posts like comments, it really depends various other site configuration factors whether anonymous/authenticated users are able to edit their posts after creating them. It would be insane to try to catch and account for all of these possibilities. Instead, we can make it a unique option:

[  ] Re-check post upon editing

It could be enabled by default. Perhaps we also need a new form info property, in case we want to account for the fact that not all entities may be editable. In general though, and that cuts pretty much already, only forms specifying an 'entity' can lead to editable records.

Hm. Or is all of this already covered by the existing 'bypass access' form info property?

CommentFileSizeAuthor
#1 mollom-HEAD.recheck.1.patch1.95 KBsun
#1 mollom-recheck.1.png10.21 KBsun
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Status: Active » Needs review
FileSize
10.21 KB
1.95 KB

At the very least, we should start with displaying the bypass permissions, so site administrators are actually aware of that currently hidden feature:

mollom-recheck.1.png

Dries’s picture

- I think such a re-check setting would be a good idea. It is not the most important feature to work on.

- Show the 'by-pass permissions' is a good idea too but I don't think there is a dependency on the re-check feature. It might better belong in a separate issue. Either way, I'm not really fond of the current UI/approach to display those settings: this information looks too much like a form element whereas it is more like help text. Because it looks like a form element, it looks weird to display that information at the top of the page. It probably shouldn't look like a form element.

- It would be great if that code could be simplified. It seems to be doing a lot of work just to discover a title and a fragment. That seems to suggest we're missing an easier to use API ...

Status: Needs review » Needs work

The last submitted patch, mollom-HEAD.recheck.1.patch, failed testing.

sun’s picture

Status: Needs work » Postponed

I've extracted the output of bypass permissions into #917544: Administrators are not aware of additional bypass permissions + using a different approach there.

Therefore, postponing this issue for now.

mayerwin’s picture

On my wiki, I get tons of content edit spam that bypass Mollom this way...
The feature described by sun would be very appreciated!

Wim Leers’s picture

Subscribing.

A site of mine has a wiki content type (actually the core book module combined with an enabled "edit any book content" permission for anonymous users) that desperately needs this.

pmorel’s picture

Subscribing.

discursives’s picture

I need this for a wiki use case, too. Would be nice if there was a more Granular approach to which permissions trigger the bypass in general, and specifically this one is important, too.

smscotten’s picture

Status: Postponed » Active

Very interested in this myself.

At the very least I'd like to be able to disable the bypass that gives spammers laissez-faire rights to fill my site with new obscene posts. Sure, if they have the right to edit other people's posts without checks there's still a vulnerability without the ability to re-check edited posts, but it would at least stop SOME of the spam.

For a wiki or wiki-ish site, the automatic, unconfigurable disabling of Mollom protection makes Mollom pointless. It's not that Mollom isn't useful—it would be awesome if we could enable it and just set bypass permissions by role ourselves (which obviously we can already do—we just can't undo the choices that disable Mollom).

Un-postponing because I think this issue's time has come, but mostly because it was set to postponed after resolving a side issue without addressing the feature request.

Personally, I'd like to see this on 6.x, but if the feature is added for 7.x but not 6.x I'll upgrade.

smscotten’s picture

Anyone interested in protecting forms even from users with "edit" permission, just comment out line 2561 (in d6) or 2337 (in d7) of mollom.module:

d6:

  if ($type->module == 'node') {
    // $form_info['bypass access'][] = 'edit any ' . $type->type . ' content';
    $form_info['bypass access'][] = 'delete any ' . $type->type . ' content';
  }

d7:

  if (in_array($type->type, node_permissions_get_configured_types())) {
    // $form_info['bypass access'][] = 'edit any ' . $type->type . ' content';
    $form_info['bypass access'][] = 'delete any ' . $type->type . ' content';
  }

Those line numbers may of course change, but this simple edit will un-cripple mollom on wiki-ish sites. You may want to comment both the 'edit' exemption and the 'delete' exemption out, but for my purposes delete permission should only be given to trusted users anyway.

This unfortunately doesn't allow adding mollom to edit forms, but it does allow mollom to be used on node creation forms when anonymous users have "edit any" permission.

neilt17’s picture

You do not need to (and should not) edit the Mollom module code to alter the bypass permissions. In your own module you can implement the function "mymodule_mollom_form_info_alter" (where "mymodule" is the name of your module) and make the permissions as granular as you like. For example to remove the default "edit any" and "delete any" bypasses, you could do this in your own module:

function mymodule_mollom_form_info_alter(&$form_info, $form_id) {
  if ($form_info['module'] == 'node') {
    foreach ($form_info['bypass access'] as $key => $perm) {
      if (strpos($perm, 'edit any ') === 0 || strpos($perm, 'delete any ') === 0) {
        unset($form_info['bypass access'][$key]);
      }
    }
  }
}

The Mollom module calls the function drupal_alter to allow you to do this.