This module creates a bridge between the standard Drupal comments module and the DiscussIt moderation platform.
It adds another status of "Withdrawn" to the standard comment states of Published and Un-Published, to better support the way DiscussIt messages can be re-instated if need be.
New comments posted on a Drupal site are automatically passed onto the DiscussIt platform via the DiscussIt API. Changes in message state are then communicated back to Drupal via the XMLRPC service.
The module creates a new user (moderator) and a new role (comment moderator). This user is used to secure the calls to the XMLRPC methods.
To test it out a DiscussIt account and a copy of the DIscussIt Live Moderator application are required. Both can be got for free at http://www.discussit.com
| Comment | File | Size | Author |
|---|---|---|---|
| #38 | drupalcs-result.txt | 3.96 KB | klausi |
| #36 | drupalcs-result.txt | 16.05 KB | klausi |
| #27 | pareview_result.txt | 20.15 KB | doitDave |
Comments
Comment #1
jordojuice commentedStatus change as per http://drupal.org/node/1158830#comment-4479054
Comment #2
charlie73 commentedModule updated in light of http://drupal.org/node/1158830#comment-4479054
Comment #3
jordojuice commentedNice! You're moving along in the queue, but it may take a bit longer due to the gaps in time between updates. I was wondering if you abandoned this issue! But obviously not. I'm not going to assign this to myself but I'll try to check it out again when I get a chance and keep this thing moving.
In the mean time, some other things. As I mentioned, (and although I haven't checked it out again thoroughly) your module appears to contain a library from a third party, correct? It remains that you may be required to provide instructions on how to obtain and install the library if it cannot be hosted on drupal.org (which is often the case). I think this is dependent upon the licensing. Projects hosted on drupal.org are required to be licensed under GPLv3.
Secondly, I will do a search myself later, but are there any modules that you know of with similar functionality? If so, how does your module differ?
And as always, good luck! And thanks for taking the initiative to contribute.
Comment #4
charlie73 commentedSorry for slow response. To my knowledge there are no other desktop moderation clients for moderating Drupal comments, hence why we are so keen to fill the gap.
Within the module we use a third party library to provide the OAuth interface to our API, the license at the top of the files says :-
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
So presumably this should be ok to include since it does specifically say "any later version"?
Comment #5
jordojuice commentedIndeed, it does comply. But, even in that case it may be recommended that you use a dependency on a module like http://drupal.org/project/oauth_common instead of including the library in your module folder. This is the common Drupal way to do things, as it ensures that the library is not duplicated on sites that use several OAuth modules, with each module that relies on OAuth containing the library.
Comment #6
charlie73 commentedOk thanks I'll looking into using that instead.
Comment #7
charlie73 commentedWe've had a good long play with this, but we are really struggling :-( There doesn't appear to be a release version of an OAuth module for Drupal 7.x as yet. Can we not go live with our existing version an then modify it when a release version comes out?
We are planning of moving to OAuth 2 in the not to distant future so this would probably be an ideal time to then make the transition.
Comment #8
jordojuice commentedI understand they are porting the module now. They do have a development version out, and I would strongly suggest you work with that. If anything it would be better to contribute to that module to help the port to D7.
The reason you don't want to include the library in your own module is because of issues like http://drupal.org/node/776104 and http://drupal.org/node/929786. Obviously there are several modules that use the same library, so we would prefer that they find a central library to use for exactly these reasons.
> Can we not go live with our existing version an then modify it when a release version comes out?
This might be an option. I appreciate that you guys tried this avenue. I'll continue with the code review, but we will see how the git administrators feel once thins issue is marked RTBC.
Comment #9
jordojuice commentedHere are a few more things to do:
It's common practice to place administrative forms in an include called mymodule.admin.inc or front end pages in mymodule.pages.inc. You can use the 'file' attribute in your hook_menu() attributes.
Drupal coding standards (http://drupal.org/coding-standards) dictate that variables should be all lower case and underscores, no camelCase.
All functions need to be documented, documentation is very good where functions are documented.
Drupal variables that are set by your module must be deleted in hook_uninstall() in your .install file.
Hook implementations need to be documented as
Implements hook_name().I.e. hook_menu()All functions must be namespaced in this sense
function mymodule_function_name()no abbreviations or acronyms. Even private functions.hook_help() is there and output is formatted properly.
overall, I think the code looks good! It makes good use of the Drupal API where possible, using t() and url() and parts of the user API. You should be well on your way after these small changes.
Comment #10
pete.discussit commentedHi there, I've been working on the module while Charlie's busy with other things.
I've just commited an updated version to the repository in which I think I've dealt with all the issues mentioned in your previous post.
I look forward to hearing from you.
Pete Bennett
Comment #11
jordojuice commentedComment #12
charlie73 commentedAny news?
Comment #13
gregglesThe API directory contains 3rd party code which is not allowed in Drupal's git repository because it is easily available elsewhere. Please remove that code and add instructions during the installation process for how to download it.
The alternative is as jordojuice mentioned earlier to get the oauth module working for Drupal 7 so you can rely on it.
Please remove the $Id: from the files like discussit_live_moderator.css and discussit_live_moderator.info
The permission "access administration pages" is probably the wrong one to use for the menu callback because that permission implies a passive role in viewing information. It should really be "administer site configuration" which is an active role of changing configuration.
I see the module uses curl - have you considered drupal_http_request? That will make it work on more sites where curl is not available. If you have to use curl you should add a hook_requirements and a note about it in README.txt
Your discussit_live_moderator_admin_validate can probably be moved to for a slight performance improvement and better logical organization.
Instead of
require_once('discussit_live_moderator.admin.inc' );you can include it as a 'file' parameter to the menu declarations.The direct use of $_POST in discussit_live_moderator_dicomment_admin is a little concern, but I guess that's how core does it.
Most of these things are suggestions. I'm inclined to grant you access but just want to get some feedback about the 3rd party code issue first.
I know jordojuice's description doesn't exactly match mine. Here's the page where I draw my policy http://drupal.org/node/422996
Comment #14
pete.discussit commentedThanks for your response.
We're currently working on new features for the module and have removed all the 3rd party libraries. We'll go through all the other points you've mentioned here before we commit the next version for review.
Pete B.
Comment #15
pete.discussit commentedI wonder if you could give me some advice re. drupal_http_request:
We're connecting to our API using OAuth2 over SSL and drupal_http_request seems to be handling our requests OK but not terminating the stream. This is the error I get:
Warning: fread(): SSL: Connection reset by peer in drupal_http_request() (line 905 of /usr/local/zend/apache2/htdocs/drupal78/includes/common.inc).
Any ideas?
Thanks.
Comment #16
gregglesThat is quite odd. I suggest trying it on a different host on a different network just to see if it's a network issue first.
If that doesn't help then using curl is fine, just add the hook_requirements and note in README.txt about it.
Comment #17
pete.discussit commentedRemoved 3rd party libs, added hook_requirements for CURL, removed "$Id:"s, changed permissions. Changed functionality.
Comment #18
doitDave commentedHi, automatic review results with klausi's script:
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:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Manual addition:
Seems like you checked in the .gitignore file by accident?
HTH, Dave
Comment #19
pete.discussit commentedThanks doitDave!
I've run the module through coder and gone through the list of issues you supplied.
I hope I've done enough.
Cheers,
Pete B.
Comment #20
doitDave commentedHi pete,
As developers we both know that this is unachievable by design. ;) Ok, back from irony, all the automated checks are very helpful but not perfect. In my personal review flow, I regard them as a necessary filter that applies before in-depth manual checks and I guess most other active reviewers handle it in a similar way. It is, IMO, always a good and speeding up idea, to also match one's one application manually with the many Drupal coding standards documents. In addition, your own local installation of klausi's pareview script can really make finding issues a lot easier.
So let's go - are you sure you committed and pushed your recent changes completely?
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:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Manual note: I see that you have created a git TAG instead of a branch. Maybe that is related. Please check with http://drupal.org/node/1127732 again and let me know once you are ready for the next attempt. :)
Comment #21
pete.discussit commentedI've gone through most of the points raised but I am still confused about the (\n) thing.
Also I've tried to move to a new branch but I get the following response:
Comment #22
doitDave commentedYes that is all a little bit tricky. As for me, it took me about three attempts before I no longer overlooked the colon that prefixed the now emptied branch (
git push origin :master). (See http://drupal.org/node/1127732). Sure you didn't miss it? ;)Comment #23
pete.discussit commentedOk. It's in there now.
Comment #24
doitDave commentedNo, sorry, your master branch is still not empty: http://drupalcode.org/sandbox/charlie73/1133136.git/tree/refs/heads/master
Comment #25
pete.discussit commentedOk it's empty now.
Comment #26
gregglesIt's not empty - you can see the contents at http://drupalcode.org/sandbox/charlie73/1133136.git/tree/refs/heads/master
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.
Comment #27
doitDave commentedI have also attached another review as of the most recent versions of the reviewing tools. Maybe you want to check again.
Comment #28
pete.discussit commentedThanks Dave.
I've pushed the latest version for review at http://drupalcode.org/sandbox/charlie73/1133136.git/commit/2fce4068c3943...
And I've cleared the master branch.
Comment #29
pete.discussit commentedThanks Dave.
I've pushed the latest version for review at http://drupalcode.org/sandbox/charlie73/1133136.git/commit/2fce4068c3943...
And I've cleared the master branch.
Comment #30
pete.discussit commentedComment #31
doitDave commentedPete, I know this is fussy with git. And, congrats, the master branch is empty now. But still you will not be able to create releases on d.o, as you do not meet the naming conventions. For deploying and maintaining projects here it is really, really important to be familiar not just with git but also with the additional conventions here on d.o. Please check with the git docs again, at least with this: http://drupal.org/node/1015226 as there is no way around it. (You will understand why, once you start to promote your project.)
Aside this, there remain some minor complaints from drupalcs, but that's not much at all.
Unfortunately the queue is very full again, so I have to postpone a next deeper insight until your next fixes. Feel free to help a bit with the queue in the meantime to accelerate the process.
Comment #32
pete.discussit commentedThanks for all your help. I'll familiarise myself properly with the naming conventions before I do any more commits.
Comment #33
pete.discussit commentedOk. I've moved the incorrectly named (7.x-1.0) branch to dev release (7.x-1.x) branch as per: http://drupal.org/node/1015226
Do I need to add a release tag to it or does that come later?
Thanks.
Comment #34
patrickd commentedYou just have to create tags, if you want to create a release (what is only possible after your project is a full one)
See http://ventral.org/pareview/httpgitdrupalorgsandboxcharlie731133136git
Comment #35
pete.discussit commentedI've dealt with all the issues thrown up by pareview.sh. see here:
http://ventral.org/pareview/httpgitdrupalorgsandboxcharlie731133136git
I've run it through coder on strict and the only issues left are ones I cannot fix, as that would require changing code on the API, which the developers are not willing to do.
Have I understood correctly that I do not need to create tags yet, and the git repository is in order?
Kind regards,
Pete Bennnett
Comment #36
klausiReview of the 7.x-1.x branch:
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.
manual review:
Comment #37
pete.discussit commentedThanks. I've gone through the points raised in: http://drupal.org/node/1145422#comment-5420508
Comment #38
klausiReview of the 7.x-1.x branch:
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. Get a review bonus and we will come back to your application sooner.
manual review:
I know, getting feedback on your application took long, you can speed up the process with #1410826: [META] Review bonus.
Comment #39
klausiClosing due to lack of activity. Feel free to reopen if you are still working on this application.