Description:

Very simple module that provides a content type with 2 default fields: a textfield and expiry date. When a node's expiry date has elapsed, the node is automatically deleted by cron. This could be useful for securely sending sensitive information, such as passwords, instead of sending them by email where they are archived indefinitely. Useful for support/issue tracking Drupal sites.

Inspired by x•change, by Matt Gaidica. https://gaidi.ca/x/

Clone:

git clone --branch 7.x-1.x http://git.drupal.org/sandbox/openloop.ie/2398249.git

Project Page:

https://www.drupal.org/sandbox/openloop.ie/2398249

Comments

openloop.ie’s picture

Issue summary: View changes
openloop.ie’s picture

Issue summary: View changes
codesidekick’s picture

Automated Review

http://pareview.sh/pareview/httpgitdrupalorgsandboxopenloopie2398249git There are hundreds of minor formatting issues here that must be fixed. Please follow Drupal best practise for tab indenting, function commenting and file commenting. It's a great opportunity to learn about coding standards and configure your editor - it shouldn't take you too long to fix these up.

You can check out Drupal core modules such as node.module for an example on how you need to add comments above every function and every file and the formatting of the code

Manual Review

No duplication
https://www.drupal.org/project/scheduler, https://www.drupal.org/project/node_expire and https://www.drupal.org/project/rules allow configuring time based unpublishing and deleting for ANY node type on the system. I think that's far more flexible as most people with existing sites who want to use this existing functionality won't want a new content type installed on their site.
Master Branch
Release branch is set up correctly.
README.txt/README.md
Not found. Please add a README file to notify users how to use the module.
Code long/complex enough for review
No, code is not complex or extensible enough. I can't see how this module could be applied to an existing site, with existing content types.
Secure code
NO: But only by suggestion. You mentioned a possible use case of people storing passwords in nodes. Passwords should never ever be stored in plain text in any situation whatsoever. Passwords should be known only to the users they belong to and hashed in absolutely all other situations. The usage suggestion for the module is dangerous.
Coding style & Drupal API usage
  1. (*) Automated code review found many issues
  2. (*) Random URL could lead to duplicates which would create a security risk. Suggest using hashes.
  3. (+) timebomb_form & timebomb_form_alter seem redundent. But anyway, timebomb_form_alter should use hook_form_FORM_ID alter.
  4. (*) Security through obscurity using random URL's is a bad idea.

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.

This review uses the Project Application Review Template.

If this module was rewritten to use Field API or Entity API to make any Entity on a Drupal site expire it would be much more useful than it currently is.

As it stands, as brutal as it might sound, this module needs to be greatly re-written to take advantage of the extensibility of Drupal. At the moment it's too single purpose and single focus and wouldn't integrate well with existing sites (which is where modules are generally installed.

PA robot’s picture

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.

codesidekick’s picture

Status: Needs review » Needs work
drpl’s picture

README.txt/README.md
No: Does not follow the guidelines for in-project documentation and/or the README Template.
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. (*) instance and fields witch is created on timebomb.install line 8&9 need to be deleted in hook_uninstall().
  2. Missing function doc comment in all .module file
  3. there is hook_token to generate a random URL alias and is not used in the same module, is there code missing.

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.

PA robot’s picture

Status: Needs work » Closed (won't fix)

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.