Taxonomy revision

welcome back,

As installation and usage instructions are quite important for us to review, please take a moment to make your project page follow the tips for a great project page. Also create a README.txt that follows the guidelines for in-project documentation.

An automated review of your project has found some issues with your code; As coding standards make sure projects are coded in a consistent style we please you to have a look at the report and try to fix them. Anyway, note that issues found are possibly false positives and fixing all issues is not a requirement for getting through the application process.
Report: http://ventral.org/pareview/httpgitdrupalorgsandboxskipyt1611652git

• The 'restrict access' key for permissions is for highly dangerous permissions - are your permissions really highly dangerous for the site?
• You don't have to specify that your module belongs into the "Other" package, giving no package would result in the same
• Please never use generic variable names such as $i or $k
• module_load_include('install', 'taxonomy_revision'); - this is what module_load_install($module) is made for
• If you invoke hooks - document them in a .api.php (See https://drupal.org/node/161085#api_php)

However the module is definitely long enough this time :)

We do really need more hands in the application queue and highly recommend to get a review bonus so we can come back to your application sooner.

regards

1. It is really necessary to alter the core module table taxonomy_term_data as module adding new column revision_id into taxonomy_term_data.
2. On module uninstall column revision_id still exist intaxonomy_term_data table

please leave application issues as tasks

Hi,

After reading the code which appears clean and well structured, I have the following comments/questions:

* In taxonomy_revision.install

- The schema of the taxonomy_term_data_revision says tid is the primary key, but revision_id is defined as it.
- There is no index for (tid, revision_id) but it could be useful for taxonomy_revision_delete
- I think a call to db_drop_unique_key is missing in taxonomy_revision_uninstall
- A authorid field could be useful. Also it's mentioned in taxonomy_term.views.inc

* taxonomy_revision.module

- In taxonomy_revision_term_load: maybe you could use EntityFieldQuery to get the tids matching the condition as recommended on the entity_load page to make it compatible with Drupal 8.

* taxonomy_revision.views.inc

- As mentioned above, there is a reference to the authorid field for the taxonomy_term_data_revision but this field doesn't exist. (I think it would be interesting to have it.)

* Automatic review

http://ventral.org/pareview/httpgitdrupalorgsandboxgarphy1358780git-7x-1x

Several style errors have been detected (mostly class/function names and missing scope for the views plugins) but none is blocking.

So once the issues with the schema have been fixed, I think it's good to go.

Hi,

It looks good, thanks for the modifications.

It would be nice to handle the user information in taxonomy_revision_overview to have something similar to node revision ('!date by !username').

Also, apparently there is no way to see a revision. For example for a node we can access it through node/NODEID/revisions/REVISIONID/view. It would be great to have this feature.

I will run a second series of test tomorrow.

Thanks for your work.

No problem found after second series of test.

This module looks good to me.

Note: I've also created a case (#1643800: Revision view page) with a patch to add the functionality mentioned in #7.

Review of the 7.x-1.x branch:

• Drupal Code Sniffer has found some issues with your code (please check the Drupal coding standards). See attachment.

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. You have to get a review bonus to get a review from me.

manual review:

1. You can ignore the code style errors on the Views class and method names.
2. _taxonomy_revision_access(): You can return TRUE immediately as soon as user_access() returns TRUE here, right? Checking the permissions further is useless?
3. _taxonomy_revision_access(): The $term parameter is unused?
4. taxonomy_revision_entity_info_alter(): no need to use module_load_install() as you are including files from your own module which you already know where they are. Use something like require_once dirname(__FILE__) . '/mymodule.inc';
5. taxonomy_revision_field_attach_form(): There is only one case here, so replace switch() with if(). Same for taxonomy_revision_taxonomy_form_term_submit_build_term().
6. "module_invoke_all('taxonomy_revision_delete', $revision);": Hooks that are provided by a module should be documented in MODULENAME.api.php, see http://drupal.org/node/161085#api_php

Although you should definitively fix those issues they are no blockers, so ...

Thanks for your contribution, skipyT! Welcome to the community of project contributors on drupal.org.

I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

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.

As you continue to work on your module, keep in mind: Commit messages - providing history and credit and Release naming conventions.

Thanks to the dedicated reviewer(s) as well.