Comment abuse

welcome

It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Review of the master branch:

• README.txt is missing, see the guidelines for in-project documentation.
• Remove "version" from the info file, it will be added by drupal.org packaging automatically.
• Run coder to check your style, some issues were found (please check the Drupal coding standards).
• Drupal Code Sniffer has found some code style issues (please check the Drupal coding standards). See http://ventral.org/pareview/httpgitdrupalorgsandboxilyineugenegmailcom14....

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Go and review some other project applications, so we can get back to yours sooner.

Duplication?
There is already a module called abuse (http://drupal.org/project/abuse) that seems to have similar functionality. Can you explain why your module should be promoted instead of joining forces with the creators of abuse?
I think that this could also be done quite simple with a rules+flags+views combination, is there a need for it?

it would be nice to have a direct comparison of comment abuse and abuse

add review links

Couple of notes.

'access callback' => TRUE,

It's undesirable. Access callback must check some permission, or custom callback.
If you hardcode callback to TRUE in code, you could not change it in UI.

function comment_abuse_list_page() {
  return drupal_get_form('comment_abuse_list_form');
}
function comment_abuse_options() {
  return drupal_get_form('comment_abuse_options_form');
}

This functions are useless now. You should set 'drupal_get_form' as 'page callback', and name of form in 'page arguments' for appropriate items in hook_menu.

In comment_abuse_get_allowed_comment_links_by_nid() function in SQL query
'WHERE ca.cid is NULL'
better will be (uppercase for all MySQL keywords)
'WHERE ca.cid IS NULL'

In comment_abuse_list_form() when you use pager_query, 50 - count of rows should be configurable, e.g. variable_get(...)

In comment_abuse_list_form_submit() cids collected and concatenated manually, use db_placeholders() instead.

In comment_abuse_link() what sense of static variable $comment_allow?

In JS file use Drupal.behaviors (see for details http://drupal.org/node/304258 ) instead default JQuery DOM ready bind - $(function(){}).

I guess almost all views handlers are useless. They make default things. Also there is a good practice to name handlers in that manner:
[MODULE_NAME]_handler_[HANDLER_TYPE]_[HANDLER_NAME]. HANDLER_TYPE - filter, sort, field, etc.. So relationship handler named wrong.

Also add indices to comment_abuse table on uid and nid fields, i guess it will be usefull.

I'm sorry for the delay, but there are hundreds of applications and only a hand full of reviewers.
You can speed up you application by getting a review bonus, see #1410826: [META] Review bonus

I've reviewed and tested the 7.x version on my own core box. It works quite well, and makes excellent use of the content dashboard. It works great presently; though I have a suggestion for future development (if you intend to develop further): the "Status" column in the GUI is a "0" or "1". I understand that the 0 means unpublished and 1 means published, however it would be an excellent feature to translate that into "published" or "unpublished" (for simplicity's sake).

Beyond that, I find this to be a fantastic addition to any site that uses comments regularly.

manual review:

• comment_abuse.info: empty comment, so remove that line.
• comment_abuse_install(): don't concatenate translatable string like that, use placeholders instead.
• comment_abuse_uninstall(): drupal_uninstall_schema() is not necessary in Drupal 7. Also don't touch the system table, this is all handled by drupal core.
• define('__COMMENT_ABUSE_COMPLAINT_RECEIVED_MESSAGE', 'Your complaint has been received.');: all user facing text should run through t() for translation. Also in other places.
• comment_abuse_init(): why do you need hook_init()? This will add the javascript to pages that don't even have comments on them. Why can't you use hook_comment_view()?
• comment_abuse_content(): why do you take the uid from the path and not from the acting user? This is a security issue as an attacker with the "send complaints on comments" permission can insert data on behalf of another user by just sending a different user id!
• $_SERVER['REMOTE_ADDR']: use ip_address() instead.
• comment_abuse_admin(): why do you need to read from $_POST?
• "variable_get('comment_abuse_complaint_received_message', __COMMENT_ABUSE_COMPLAINT_RECEIVED_MESSAGE)": this is user provided text, so you need to sanitize it to avoid XSS attacks. Please read the documentation about handling text in a secure fashion: http://drupal.org/node/28984

Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

add review link

manual review:

• "'#default_value' => check_plain(...)": form default values are sanitized by the form API automatically for you. Please read handling text in a secure fashion again: http://drupal.org/node/28984
• "$comment->content['links']['comment']['#links']['comment-complaint']": use the power of the render system. If the title should be plain text, then don't set "html" to TRUE. Then you don't have to use check_plain() yourself. And for the attributes: no need to use check_plain() here either, as this will be passed through drupal_attributes(). Take a look at theme_links(), that is the function that will render your links: http://api.drupal.org/api/drupal/includes!theme.inc/function/theme_links/7
• comment_abuse_list_form(): "'#title' => check_plain($comment->subject),": same here, the render system will sanitize that for you. And of course double escaping is bad, so you should avoid that.

Otherwise I think this is nearly ready. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

add review link

manual review:

• comment_abuse.module: @file doc block is empty. Also in the other files. See http://drupal.org/node/1354#files

Otherwise looks good to me. Removing review bonus tag, if there are still changes required you can add it again if you have done another 3 reviews of other projects.

add review links

But the #title is not part of a form element in your case, it is part of link render array. Looks like a false positive in the coder review module.

About the project application workflow: a git administrator other than me will take a final look and either grant you the git vetted user role or bump this issue back to needs work if there are any outstanding issues that I missed.

Thanks for your contribution! Welcome to the community of project contributors on drupal.org.

I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

As you continue to work on your module, keep in mind: Commit messages - providing history and credit and Release naming conventions.

Removing review bonus tag.

Closing due to lack of activity. Feel free to reopen if you are still working on this application (see also the project application workflow).

I'm a robot and this is an automated message from Project Applications Scraper.