toddgee [toddgee]

I am changing status.

Hello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review your code, pointing out what needs to be changed.

As per http://drupal.org/cvs-application/requirements, the motivation message should be expanded to contain more details about the features of the proposed module, and it should include also a comparison with the existing solutions.

The status active is not used on this queue; the correct status is needs review, as the module needs to be reviewed by somebody.

I'm not on the review team, but this feedback might be helpful:

just from a cursory glance just reading the motivation message, it seems that views could do what that module does. It might help the reviews to provide a comparison with what views can do, and how your module is different.

this module is it uses camelCase on variable names, for example line 63 in .module (see http://drupal.org/coding-standards
Functions and variables
Functions and variables should be named using lowercase, and words should be separated with an underscore. Functions should in addition have the grouping/module name as a prefix, to avoid name collisions between modules.)

in this module queries are not using the db_query() variable substitution method, for example line 77 in .module (see http://drupal.org/writing-secure-code
Instead, use proper argument substitution with db_query:

db_query("SELECT foo FROM {table} t WHERE t.name = '%s' ", $_GET['user']);

and the license wording in the .info file and README seems a bit odd.
http://drupal.org/cvs-application/requirements says "Your work must be licensed under the same license as Drupal, which is GPL version 2 or later (read why). Also, we do not allow committing third-party libraries to CVS, even if they are GPL (read why)." and i've seen some comments on other cvs applications like:
http://drupal.org/node/757644#comment-2848800 but I'm really not sure about this point.

I dont know if the same people who are on the cvs application review team are the same ones working like mad on d7 critical issues, but there seems to be a few people in a similar boat as you. :(

Also,
coding standards page links to: http://drupal.org/node/1354 which says
"All documentation and comments always form proper sentences and use proper grammar and punctuation."
several comments in this module are missing punctuation, some are missing capitals at the beginning of sentences, and some use appreviations (like config instead of configuration). I'm not sure how picky people are about this.

I've seen some references to wanting lines to wrap at 80 characters (like in comments). README has lines longer than 80 chars.

http://drupal.org/node/1354
also mentions using the @todo convention

Also, the .css file can probably have (it's one line) reformatted to match http://drupal.org/node/302199
CSS coding standards.

http://drupal.org/node/302199 also says .css files should have @file ... but on irc most people were surprised and many core .css files dont have @file, and someone said that api.d.o (or something) doesn't read the .css @files.

js coding standards: http://drupal.org/node/172169
I noticed for example the .js file in the module needs indents of 2 spaces. and a space before most {
might be some other things.
doesn't have any inline comments in the js code.

Not trying to be a pain, just figured maybe the review team would eventually says some of this stuff, and this might give you an advantage for when someone *does* look at your application.

@YesCT: Reviews are open to everybody; you are welcome to make review, and help with them.

Are there any updates on this?

There have not been replies in the past week. I am marking this application as won't fix.

Please read the following links as this is very important information about CVS applications.

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for these applications. Please read Migrating from CVS Applications to (Git) Full Project Applications and Applying for permission to opt into security advisory coverage on how this affects and benefits you and the application process. In short, every user has now the permissions necessary to create new projects, but they need to apply for opt into security advisory coverage. Without applying, the projects will have a warning on projects that says:

This project is not covered by Drupal’s security advisory policy.