Bundle Inherit

Automated test results:

Master Branch

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.

coder on minor

I noticed some very small code style issues. Please run the Coder module on "minor" setting to help catch these. The coding standards have even more information in this area. I noticed things like ...

Please note: The Coder module currently has an unresolved flaw which will prompt you to add file declarations to your .info file even when it's not necessary to do so. Please do not try to make this warning go away by declaring files which do not contain classes or interfaces.

Severity minor, Drupal Commenting Standards, Internationalization, Drupal Security Checks, Drupal SQL Standards, Drupal Coding Standards

/bundle_inherit_node/bundle_inherit_node.module:
 +3: [minor] @file description should be on the following line

/bundle_inherit.module:
 +110: [minor] Missing parenthesis after function name
 +117: [minor] @see should always be followed by a filename, a URL, class/interface name (optionally including method), or a function name including ().
 +117: [minor] @see references should be separated by "," followed by a single space and with no trailing punctuation
 +131: [minor] @see should always be followed by a filename, a URL, class/interface name (optionally including method), or a function name including ().
 +131: [minor] @see references should be separated by "," followed by a single space and with no trailing punctuation
 +198: [minor] Use an indent of 2 spaces, with no tabs
 +199: [minor] Use an indent of 2 spaces, with no tabs
 +200: [minor] Use an indent of 2 spaces, with no tabs
 +201: [minor] Use an indent of 2 spaces, with no tabs

Status Messages:
 Coder found 3 projects, 3 files, 10 minor warnings, 0 warnings were flagged to be ignored

coder_tough_love and comments on minor

This is optional.

Severity minor, Project application tests - Comments, Coder Tough Love

/bundle_inherit_node/bundle_inherit_node.module:
 +3: [minor] All comments should end with a ".".
 +4: [minor] All comments should end with a ".".
 +8: [minor] All comments should end with a ".".
 +9: [minor] All comments should end with a ".".
 +10: [minor] All comments should end with a ".".
 +10: [normal] If you define a @param or @return, you should document it as well.
 +10: [normal] @param and @return syntax should not indicate the data type.
 +11: [minor] All comments should end with a ".".
 +11: [normal] If you define a @param or @return, you should document it as well.
 +11: [normal] @param and @return syntax should not indicate the data type.
 +12: [minor] All comments should end with a ".".
 +12: [normal] If you define a @param or @return, you should document it as well.
 +12: [normal] @param and @return syntax should not indicate the data type.
 +17: [minor] All comments should end with a ".".
 +25: [minor] All comments should end with a ".".
 +26: [minor] Lines in comments should not exceed 80 characters.
 +26: [minor] All comments should end with a ".".
 +26: [normal] Function documentation should be less than 80 characters per line.
 +27: [minor] All comments should end with a ".".
 +27: [normal] If you define a @param or @return, you should document it as well.
 +27: [normal] @param and @return syntax should not indicate the data type.
 +28: [minor] All comments should end with a ".".
 +28: [normal] If you define a @param or @return, you should document it as well.
 +28: [normal] @param and @return syntax should not indicate the data type.
 +32: [minor] All comments should end with a ".".

/bundle_inherit.module:
 +3: [minor] All comments should end with a ".".
 +4: [minor] All comments should end with a ".".
 +8: [minor] All comments should end with a ".".
 +9: [minor] All comments should end with a ".".
 +10: [minor] All comments should end with a ".".
 +10: [normal] If you define a @param or @return, you should document it as well.
 +10: [normal] @param and @return descriptions begin indented on the next line.
 +11: [minor] All comments should end with a ".".
 +11: [normal] If you define a @param or @return, you should document it as well.
 +11: [normal] @param and @return descriptions begin indented on the next line.
 +12: [minor] All comments should end with a ".".
 +12: [normal] If you define a @param or @return, you should document it as well.
 +12: [normal] @param and @return descriptions begin indented on the next line.
 +13: [minor] All comments should end with a ".".
 +13: [normal] If you define a @param or @return, you should document it as well.
 +13: [normal] @param and @return descriptions begin indented on the next line.
 +17: [minor] All comments should end with a ".".
 +33: [minor] All comments should end with a ".".
 +52: [minor] All comments should end with a ".".
 +53: [minor] All comments should end with a ".".
 +54: [minor] All comments should end with a ".".
 +54: [normal] If you define a @param or @return, you should document it as well.
 +54: [normal] @param and @return descriptions begin indented on the next line.
 +68: [minor] All comments should end with a ".".
 +69: [minor] All comments should end with a ".".
 +70: [minor] All comments should end with a ".".
 +70: [normal] If you define a @param or @return, you should document it as well.
 +70: [normal] @param and @return descriptions begin indented on the next line.
 +71: [minor] All comments should end with a ".".
 +71: [normal] If you define a @param or @return, you should document it as well.
 +71: [normal] @param and @return descriptions begin indented on the next line.
 +91: [minor] All comments should end with a ".".
 +92: [minor] All comments should end with a ".".
 +92: [normal] If you define a @param or @return, you should document it as well.
 +92: [normal] @param and @return descriptions begin indented on the next line.
 +110: [minor] All comments should end with a ".".
 +111: [minor] All comments should end with a ".".
 +112: [minor] All comments should end with a ".".
 +113: [minor] Lines in comments should not exceed 80 characters.
 +113: [minor] All comments should end with a ".".
 +113: [normal] Function documentation should be less than 80 characters per line.
 +114: [minor] All comments should end with a ".".
 +114: [normal] If you define a @param or @return, you should document it as well.
 +114: [normal] @param and @return syntax should not indicate the data type.
 +115: [minor] All comments should end with a ".".
 +115: [normal] If you define a @param or @return, you should document it as well.
 +115: [normal] @param and @return descriptions begin indented on the next line.
 +116: [minor] All comments should end with a ".".
 +116: [normal] If you define a @param or @return, you should document it as well.
 +116: [normal] @param and @return descriptions begin indented on the next line.
 +117: [minor] All comments should end with a ".".
 +124: [minor] All comments should end with a ".".
 +125: [minor] All comments should end with a ".".
 +126: [minor] Lines in comments should not exceed 80 characters.
 +126: [minor] All comments should end with a ".".
 +126: [normal] Function documentation should be less than 80 characters per line.
 +127: [minor] All comments should start capitalized.
 +127: [minor] All comments should end with a ".".
 +128: [minor] All comments should end with a ".".
 +129: [minor] All comments should end with a ".".
 +129: [normal] If you define a @param or @return, you should document it as well.
 +129: [normal] @param and @return descriptions begin indented on the next line.
 +130: [minor] All comments should end with a ".".
 +130: [normal] If you define a @param or @return, you should document it as well.
 +130: [normal] @param and @return descriptions begin indented on the next line.
 +131: [minor] All comments should end with a ".".
 +152: [minor] All comments should end with a ".".
 +153: [minor] All comments should end with a ".".
 +154: [minor] All comments should end with a ".".
 +154: [normal] If you define a @param or @return, you should document it as well.
 +154: [normal] @param and @return descriptions begin indented on the next line.
 +155: [minor] All comments should end with a ".".
 +155: [normal] If you define a @param or @return, you should document it as well.
 +155: [normal] @param and @return descriptions begin indented on the next line.
 +156: [minor] All comments should end with a ".".
 +156: [normal] If you define a @param or @return, you should document it as well.
 +156: [normal] @param and @return descriptions begin indented on the next line.
 +172: [minor] All comments should end with a ".".
 +173: [minor] All comments should end with a ".".
 +174: [minor] All comments should end with a ".".
 +174: [normal] If you define a @param or @return, you should document it as well.
 +174: [normal] @param and @return descriptions begin indented on the next line.
 +175: [minor] All comments should end with a ".".
 +175: [normal] If you define a @param or @return, you should document it as well.
 +175: [normal] @param and @return descriptions begin indented on the next line.
 +176: [minor] All comments should end with a ".".
 +176: [normal] If you define a @param or @return, you should document it as well.
 +176: [normal] @param and @return descriptions begin indented on the next line.
 +188: [minor] All comments should end with a ".".
 +189: [minor] All comments should end with a ".".
 +190: [minor] All comments should end with a ".".
 +190: [normal] If you define a @param or @return, you should document it as well.
 +190: [normal] @param and @return descriptions begin indented on the next line.
 +191: [minor] All comments should end with a ".".
 +191: [normal] If you define a @param or @return, you should document it as well.
 +191: [normal] @param and @return descriptions begin indented on the next line.
 +192: [minor] All comments should end with a ".".
 +192: [normal] If you define a @param or @return, you should document it as well.
 +192: [normal] @param and @return syntax should not indicate the data type.
 +208: [minor] All comments should end with a ".".
 +209: [minor] All comments should end with a ".".
 +209: [normal] If you define a @param or @return, you should document it as well.
 +209: [normal] @param and @return descriptions begin indented on the next line.
 +210: [minor] All comments should end with a ".".
 +210: [normal] If you define a @param or @return, you should document it as well.
 +210: [normal] @param and @return descriptions begin indented on the next line.
 +211: [minor] All comments should end with a ".".
 +211: [normal] If you define a @param or @return, you should document it as well.
 +211: [normal] @param and @return descriptions begin indented on the next line.
 +236: [minor] All comments should end with a ".".
 +251: [minor] All comments should end with a ".".
 +262: [minor] All comments should end with a ".".
 +263: [minor] All comments should end with a ".".
 +264: [minor] All comments should end with a ".".
 +264: [normal] If you define a @param or @return, you should document it as well.
 +264: [normal] @param and @return descriptions begin indented on the next line.
 +265: [minor] All comments should end with a ".".
 +265: [normal] If you define a @param or @return, you should document it as well.
 +265: [normal] @param and @return descriptions begin indented on the next line.
 +266: [minor] All comments should end with a ".".
 +266: [normal] If you define a @param or @return, you should document it as well.
 +266: [normal] @param and @return descriptions begin indented on the next line.
 +276: [minor] All comments should end with a ".".
 +277: [minor] All comments should end with a ".".
 +278: [minor] All comments should end with a ".".
 +278: [normal] If you define a @param or @return, you should document it as well.
 +278: [normal] @param and @return descriptions begin indented on the next line.
 +279: [minor] All comments should end with a ".".
 +279: [normal] If you define a @param or @return, you should document it as well.
 +279: [normal] @param and @return descriptions begin indented on the next line.
 +280: [minor] All comments should end with a ".".
 +280: [normal] If you define a @param or @return, you should document it as well.
 +280: [normal] @param and @return descriptions begin indented on the next line.

/bundle_inherit.install:
 +3: [minor] All comments should end with a ".".
 +4: [minor] All comments should end with a ".".
 +8: [minor] All comments should end with a ".".
 +9: [minor] All comments should end with a ".".
 +10: [minor] All comments should end with a ".".
 +10: [normal] If you define a @param or @return, you should document it as well.
 +10: [normal] @param and @return syntax should not indicate the data type.

Status Messages:
 Coder found 3 projects, 3 files, 77 normal warnings, 88 minor warnings, 0 warnings were flagged to be ignored

README.txt

Please take a moment to make your README.txt follow the guidelines for in-project documentation.

It looks like you have windows line endings in http://drupalcode.org/sandbox/lemark/1313824.git/blob/refs/heads/7.x-1.x... and in http://drupalcode.org/sandbox/lemark/1313824.git/blob/refs/heads/7.x-1.x...

I ran all tests (thanks for adding those): all green

I had a quick look at the code, and it looks ok to me.

Agree with attiks about windows style line ending. Please change to unix style.

This module seems usefull and desireable for Drupal itself, extending inheritance functionality. So, it looks great for me. Code looks well and all works fine as I can see, so I give this the RTBC status.

As a wish, I would like to see a more, very MORE descriptive text of what and how this module do. And of course, with some typical usecases for that. So please provide some more information of your great module and underlying idea (in english).

Thank to all, looking for angels to make from this a real project. :)

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

• ./bundle_inherit.test: comment lines should break at 80 characters, see http://drupal.org/node/1354#general
  

      // Add new content type (for example we'll create node type, but generaly, kind of the entity type does not matter here)
      // When implementing inheritance on node entity type we should delete body field first.
  

• ./bundle_inherit.test: The description for the @param/@return documentation is either missing or not formatted correctly. See http://drupal.org/node/1354#functions
  

  113-   *  First instance
  115-   *  Second instance
  117-   *  TRUE if $a and $b are equal.
  

• ./bundle_inherit.module: The description for the @param/@return documentation is either missing or not formatted correctly. See http://drupal.org/node/1354#functions
  

  164- *  Entity type parent type.
  183- *  Parent form element to attache inheritance form to.
  185- *  From state from the parent form.
  187- *  Entity for which bundle is creating for.
  241- *  Newly created bundle name.
  

• Bad line endings were found, always use unix style terminators. See http://drupal.org/coding-standards#indenting
  

  ./bundle_inherit.info:                                    ASCII text, with CRLF line terminators
  ./bundle_inherit_node/bundle_inherit_node.info:           ASCII text, with CRLF line terminators
  

This automated report was generated with PAReview.sh, your friendly project application review script. Please report any bugs to klausi.

manual review:

• "'description' => 'TODO: please describe this table!',": yes, please do so!
• bundle_inherit_perform(): comments in function bodies should use "//" instead of "/** .. */" comment style. See http://drupal.org/node/1354#inline
• "if ($strict) $new_instance['locked'] = TRUE;": always us "{}" around if structures, even if they are just one liners. See http://drupal.org/node/318#controlstruct
• bundle_inherit_field_update_instance(): array indentation errors, array elements should be indented 2 spaces only. See http://drupal.org/node/318#array
• bundle_inherit_bundle_get_children(): don't indent the query methods so far.
• "Attache ineritance form to selected form element.": the English word is "attach", not "attache"
• bundle_inherit_attache_inherit_form_submit(): $v is a bad variable name, always use self-explaining names like $bundle_name, $bundle_properties or whatever.
• "protected $priveleged_user;": instance variables should use lowerCamleCase naming, see http://drupal.org/node/608152
• setUp(): array indentation errors. "do{": there should be a space after "do".

Great, RTBC for me.

Thanks for your contribution, lemark! 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.

Congratulations! :)