[D7] Helpfulness Module

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxKoinseb2243485git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

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

Closing due to lack of activity. If you are still working on this application, you should fix all known problems and then set the status to "Needs review". (See also the project application workflow).

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

@Koinseb, thankyou for your contribution.

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. None.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and fragmentation. Did not find any similar module that gives all these features, specifically integration with MOLLOM too.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt/README.md

Yes: Follows the guidelines for in-project documentation and the README Template.

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

No. If "no", list security issues identified.

1. (*) helpfulness_form: This is vulnerable to XSS exploits. If I enter <script>alert('XSS');</script> in the admin settings form, tested for helpfulness_yes_description and helpfulness_no_description elements, every time If I visit this Helpfulness form, get a nasty javascript popup. You need to sanitize this before rendering, make sure to read https://www.drupal.org/node/28984 again.
   
   
   
   
   

   In given code helpfulness_yes_description and helpfulness_no_description variables coming form user provided input and you are directly rendering without sanitize that's why these popup coming. Also check the same for other places too in your code.

   $description = '<div class="helpfulness_yes_description">' . variable_get('helpfulness_yes_description', '') . '</div >';
     $description .= '<div class="helpfulness_no_description" > ' . variable_get('helpfulness_no_description', '') . '</div >';
   
     $form['helpfulness_comments'] = array(
       '#type'        => 'textarea',
       '#title'       => $title,
       '#description' => $description,
     );
   

Coding style & Drupal API usage

1. (+) You are adding helpfulness.css through .info file. Due to this, it will added on all the pages rather use #attached to add the CSS file to the form render array or page render array where these actually required.
2. Better to keep helpfulness_admin_form() in separate .inc file.
3. (+) Extra <br /> is coming in settings form that need to be fix.
   
   
   
   
   
4. (+) Instead of using date, better to use format_date().
5. (+) helpfulness_get_report_form(): Why are you changing site timezone date_default_timezone_set("America/Detroit"); and why it require in your case please add your comment on this, if it is mandatory then better to use drupal_get_user_timezone
   first and then change or should use REQUEST_TIME. I don't think it is required in your case.
6. Use Drupal.behaviors, not jQuery(document).ready() in your js file.
7. Readme file, there are some special characters found Administration » Reports » Helpfulness Feedback messages.
8. (+) helpfulness_get_confirm_form_description(): Use t() for concatenation and also check the same for other places too. Also try to wrap single line text using single t(). you can use placeholders to maintain dynamic values.
   

   $description = 'You are about to DELETE the ' . $count . ' feedback item';
     
     $description .= ' you had selected.<br /><br />';
     
     $option['uid'] = $feedback['uid'] . ' (' . $username . ')';
   

9. helpfulness_form_submit(): Instead of using substr() better to use drupal_substr().

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

Please don't remove the security tag, we keep that for statistics and to show examples of security problems.

As I am not a git administrator, so I would recommend you, please help to review other project applications to get a review bonus. This will put you on the high priority list, then git administrators will take a look at your project right away :-)

Thanks Again!

Closing due to lack of activity. If you are still working on this application, you should fix all known problems and then set the status to "Needs review". (See also the project application workflow).

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

Fixed the git clone URL in the issue summary for non-maintainer users.

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

Automated Review

preview.sh has reported a number of errors:

helpfulness.js: line 6, col 2, Error - Use the function form of "use strict". (strict)

and a dozen other code formatting errors in the helpfulness.js file

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

Yes: Follows the guidelines for 3rd party assets/code.

README.txt/README.md

Yes: Follows the guidelines for in-project documentation and/or the README Template.

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

None, good to see that you've addressed those issues from the previous review.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

Hey Koinseb,

- Remove your Drupal variables on an uninstall hookof your module.

- The .gitignore file committed in the module is unnecessary.

- Not a blocker but including your js and css files in a separate js and css folder provides a cleaner structure for your module.

- Include 'use strict' in your JS file.

- On the helpfulness_form_submit function, the items helpfulness_rating and helpfulness_comments are two items which are not required to be filled in. It's a good practice to always check if an element is set in the array before using it, specially multidimensional arrays. This avoid PHP warnings showing up.

Regards
Vin

Automated Review

Formatting issues in js/helpfulness.js

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

Yes: Follows the guidelines for 3rd party assets/code.

README.txt/README.md

Yes: Follows the guidelines for in-project documentation and/or the README Template.

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. Everything looks fine for me

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

Automated Review

[Best practice issues identified by pareview.sh / drupalcs / coder.] - As stated above there are some issues with the formatting of your javaScript which can be found here: http://pareview.sh/pareview/httpgitdrupalorgsandboxkoinseb2243485git

Note that perfect adherence to Drupal Coding Standard is NOT a reason to block an application, except for total disregard of them. However, modules should follow them as closely as possible.

Manual Review

Individual user account

[Yes: Follows] the guidelines for individual user accounts.

No duplication

[Yes: Does not cause] module duplication and/or fragmentation.

Master Branch

[Yes: Follows] the guidelines for master branch.

Licensing

[Yes: Follows] the licensing requirements.

3rd party assets/code

[Yes: Follows] the guidelines for 3rd party assets/code.

README.txt/README.md

[Yes: Follows] the guidelines for in-project documentation and/or the README Template.

Code long/complex enough for review

[Yes: Follows] the guidelines for project length and complexity.

Secure code

[Yes: Meets the security requirements. ]

Coding style & Drupal API usage

[List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. None

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

+1 RTBC, Changing status to RTBC.

Thanks for your contribution, Heymo!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

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.

Thanks to the dedicated reviewer(s) as well.