CVS edit link for ositoblanco
For a community platform I developed the following digest module:
The digest module provides API functionality to send status or digest mails
to users once a day to inform them about new activities (like new unread private messages or new unconfirmed relationship requests).
This module is an API, therefore it does not provide new functionality to your site, unless you use other modules which take use of the digest functions.
Two modules are contributed to demonstrate the use of the Digest module:
contributed_modules/user_relationships_digest and
contributed_modules/privatemsg_digest.
Comments
Comment #1
osopolarComment #2
avpadernoHello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review the code, pointing out what it needs to be changed.
Comment #3
berdirI've just looked at the privatemsg related sub-module...
- Note that the database schema has changed in privatemsg 6.x-2.x. This is not a problem in your code, just an information :)
- You're doing a pretty huge query with a ton of left joins there. Given that the pm_ tables could contain a very large number of entries, this might be quite slow. But I'm not sure if there is a better way.
- You should use the db_placeholders (http://api.drupal.org/api/function/db_placeholders/6) function to insert the role ids...
Comment #4
avpadernoI am changing the status as per previous comment;
db_query()-placeholders should be used instead of injecting a value into the query, especially if the value is not static.Comment #5
osopolarActually the submodules should go into the core of the corresponding modules, due the digest is an api and should not take care about database change - as recently in privatemsg 6.x-2.x. Anyway the code of the submodules is very important.
If somebody sees how to cut down the large sql queries, just leave a node. The only thing (actually I did before in a previous version) is to use an inner select instead of the users_roles join:
One idea came into my mind to improve performance (not yet in the code):
As far as we are only interested to inform the user about new private messages (or new relationship requests) we can modify the query to only take in account the new messages which were send after the last digest run and before the current one (see INNER JOIN {pm_index}). As far as I know this should be SQL standards-compliant.
Will there be any benefit from using _privatemsg_assemble_query?
@Bendir Thanks for reviewing the privatemsg related sub-module. If you would like to have this feature in privatemsg please have a look at the other code ... actually the tough part of the module are the sql queries in the submodule
Comment #6
osopolarComment #7
avpadernoDeleting Drupal variables using a query that matches any Drupal variable with a name that starts with the module name would remove also the Drupal variables of other modules.
It should be there were no digest mails.
The username could contain characters that have particular meaning for HTML.
The array
$optionsshould simply bearray(0, 1, 2, 3, 4, /*... */), orrange(0, 23).By default, a fieldset is not collapsible, and not collapsed; the default values should not be declared.
Strings used in the user interface should be translated.
Comment #8
osopolar@kiamlaluno: Thank you, for reviewing my code.
Comment to (2: "DELETE FROM {variable} WHERE name LIKE 'digest%%'") ... removed. But now each implementing module is responsible to delete variables like digest_roles_permissions_{modulename} and digest_message_part_{modulename}. Is this OK? or should I rename them to {modulname}_digest_roles_permissions and {modulename}_digest_message_part?
I've attached the updated version of digest module.
Comment #9
avpadernoIf the module name is digest.module, then every Drupal variable name should be prefixed by
digest_.Comment #10
osopolarThe variables depending on the implementing module (eg. privatemsg_digest) like digest_roles_permissions_privatemsg and digest_message_part_privatemsg are somehow special. They are set by the digest module settings, but they will get deleted by the uninstall hook of the implementing module. This is the only way I can see to delete them.
For example:
The new version fixes a copy paste error in the contributed modules - the uninstall hook called accidentally drupal_uninstall_schema('digest');
Comment #11
drupalshrek commentedLooks good to me.
A couple of small things:
1) README.txt I think doesn't need $Id$
2) LICENCE.txt is not needed as CVS will add this automatically
Comment #12
zzolo commentedHi. Please read all the following and the links provided as this is very important information about your CVS Application:
Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications
Comment #13
avpadernoAs per previous comment, I am setting this issue to won't fix.
Since new users can now create full projects, applications have a different purpose and they are handled on a different issue queue. See Apply for permission to opt into security advisory coverage for more information.
Comment #14
avpaderno