This module is designed to handle node access when using Domain Access and other node access modules.
It implements a AND logic between Domain Access and other node access modules.

Drupal default node access strategy consists in applying an OR logic between grants. More clearly, it means that if one node access module allows access then access is granted. Node access modules like Content Access, Book Access or Flexi Access (with ACL) can cooperate quite nicely with the OR logic. For example, access can be granted:

  • to roles on the content type using Content Access
  • to roles on a node using Content Access
  • to a user on a node using Flexi Access (with ACL)
  • to roles or users on a book using Book Access

This does not work properly when adding Domain Access. In this case, Domain Access can allow access where it should enforce domain related access while other node access modules should handle access to node when access to the domain is allowed.
Access Control Bridge allows to solve the problem by introducing an AND logic between node access modules. But it is not sufficient to reproduce the standard behavior of Drupal without Domain Access.
This module handle things quite differently considering only an AND logic with Domain Access and an OR logic between other node access grants. To access a node, the user needs to view the node using a domain associated with the node and to be granted access by at least one of the other node access module.
The module is compatible with standard node access handling that is to say with menu and views.

Project page

git clone --branch 7.x-1.x http://git.drupal.org/sandbox/sebtic/2404545.git require_domain_access

Comments

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.

GoddamnNoise’s picture

Automated Review

No problems detected by pareview.sh. The git commit messages show that the module's coder has cleaned the code to fix all the issues detected by the pareview.sh script before posting the project application (well done!).

Manual Review

Individual user account
Yes: Follows the guidelines for individual user accounts.
No duplication
Yes: Does not cause module duplication and/or fragmentation. It seems there is no other module providing this feature.
Master Branch
Yes: Follows the guidelines for master branch.
Licensing
Yes: Follows the licensing requirements.
3rd party assets/code
Yes: Follows the guidelines for 3rd party assets/code.
README.txt/README.md
No: Does not follow the guidelines for in-project documentation and the README Template. There is a well formatted README file, but it doesn't follows the README Template. The in-project documentation seems ok.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes: Meets the security requirements. It seems ok to me.
Coding style & Drupal API usage
The coding style and Drupal API usage seems correct. Only a pair of minor issues:
  1. There are some function names mixing lowercase and underscores with camel case style. Example: function require_domain_access_getDomainRealms(). See Drupal coding standards for function names to get more information.
  2. There are some debugging code (debugging messages only show up if a Drupal variable is set) mixed with the real code. Maybe it would be a good idea to remove the debugging code before release. Example:
    .....
      if (require_domain_access_getDebug()) {
        drupal_set_message(check_plain('require_domain_access_node_access_records_alter domain_grants ' . print_r($domain_grants, TRUE)));
        drupal_set_message(check_plain('require_domain_access_node_access_records_alter other_grants ' . print_r($other_grants, TRUE)));
      }
    .....
    

Summary

The code seems clean and written by a coder who knows the Drupal API. I've only detected a pair of minor issues. Maybe a more experienced Drupal developer should review those issues and decide if they must block the release of this module.

This review uses the Project Application Review Template.

PA robot’s picture

Status: Needs review » Needs work

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxsebtic2404545git

I'm a robot and this is an automated message from Project Applications Scraper.

sebtic’s picture

I have pushed improvements solving GoddamnNoise minor issues.

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.