This module is a very simple solution for allowing / preventing your users to see specific content on your site.

For each node, you can specify a list of users that are allowed to access the node (read only).

You can also define an optional expiry date, meaning the user has access to the node only during the following X days.

Administrators can set the permission "Grant content access using the SUNA module" for the users/roles that should be able to administer this access control on a per node / per user basis.

How is this project different from other similar modules such as Content Access, ACL or Nodeaccess?

This is intended to be a very simple solution to grant view access to a node, optionally for a limited period of time.

Those modules provide much more powerfull and flexible solutions but also more complexity and potential interference with other modules. In the "Simple User/Node Access" module there are no new DB tables or interference with drupal's permission system.

An example of use-case would be a library intranet that would need to grant user access to movies or any other media material for specific users, only for a specific time, just as in any borrowing system for a traditional library.

Project page link:

https://drupal.org/sandbox/marcoscano/2017349

Git repository

git clone --branch 7.x-1.x marcoscano@git.drupal.org:sandbox/marcoscano/2017349.git simple_user_node_access__s_u_n_a_

Comments

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://ventral.org/pareview/httpgitdrupalorgsandboxmarcoscano2017349git

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.

zestagio’s picture

Part 1: Ventral Review

There is still a master branch, make sure to set the correct default branch: http://drupal.org/node/1659588 . Then remove the master branch, see also step 6 and 7 in http://drupal.org/node/1127732

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


FILE: /var/www/drupal-7-pareview/pareview_temp/suna.admin.inc
--------------------------------------------------------------------------------
FOUND 36 ERROR(S) AND 1 WARNING(S) AFFECTING 28 LINE(S)
--------------------------------------------------------------------------------
1 | ERROR | End of line character is invalid; expected "\n" but found
| | "\r\n"
4 | ERROR | The second line in the file doc comment must be " * @file"
5 | ERROR | The third line in the file doc comment must contain a
| | description and must not be indented
19 | ERROR | Array closing indentation error, expected 2 spaces but found 4
24 | ERROR | Array closing indentation error, expected 2 spaces but found 4
36 | ERROR | Whitespace found at end of line
48 | ERROR | Array closing indentation error, expected 2 spaces but found 4
49 | ERROR | Whitespace found at end of line
54 | ERROR | Array closing indentation error, expected 2 spaces but found 4
55 | ERROR | Whitespace found at end of line
60 | ERROR | Array closing indentation error, expected 2 spaces but found 4
63 | ERROR | Whitespace found at end of line
67 | ERROR | Function comment short description must be on a single line
83 | ERROR | Function comment short description must be on a single line
83 | ERROR | Function comment short description must end with a full stop
85 | ERROR | Function doc comment must end on the line before the function
| | definition
90 | ERROR | Whitespace found at end of line
91 | ERROR | No space before comment text; expected "// no matter what the
| | user enters, we take only the first numeric value" but found
| | "//no matter what the user enters, we take only the first
| | numeric value"
91 | ERROR | Inline comments must start with a capital letter
91 | ERROR | Inline comments must end in full-stops, exclamation marks, or
| | question marks
92 | ERROR | A cast statement must be followed by a single space
97 | ERROR | Whitespace found at end of line
102 | ERROR | Function comment short description must end with a full stop
106 | WARNING | There must be no blank line following an inline comment
106 | ERROR | No space before comment text; expected "// this array has the
| | structure: array($nodeid => array($userid => timestamp ))" but
| | found "//this array has the structure: array($nodeid =>
| | array($userid => timestamp ))"
106 | ERROR | Inline comments must start with a capital letter
107 | ERROR | Whitespace found at end of line
109 | ERROR | Whitespace found at end of line
110 | ERROR | There should be no white space after an opening "{"
110 | ERROR | No space before comment text; expected "// if the node is
| | already referenced" but found "//if the node is already
| | referenced"
110 | ERROR | Inline comments must start with a capital letter
110 | ERROR | Inline comments must end in full-stops, exclamation marks, or
| | question marks
110 | ERROR | Comments may not appear after statements.
111 | ERROR | Whitespace found at end of line
116 | ERROR | Whitespace found at end of line
118 | ERROR | Closing brace indented incorrectly; expected 0 spaces, found 2
120 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------

FILE: /var/www/drupal-7-pareview/pareview_temp/suna.info
--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
6 | ERROR | It's only necessary to declare files[] if they declare a class or
| | interface.
--------------------------------------------------------------------------------

FILE: /var/www/drupal-7-pareview/pareview_temp/suna.install
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
1 | ERROR | End of line character is invalid; expected "\n" but found "\r\n"
26 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------

FILE: /var/www/drupal-7-pareview/pareview_temp/suna.module
--------------------------------------------------------------------------------
FOUND 35 ERROR(S) AND 3 WARNING(S) AFFECTING 21 LINE(S)
--------------------------------------------------------------------------------
4 | ERROR | The second line in the file doc comment must be " * @file"
5 | ERROR | The third line in the file doc comment must contain a
| | description and must not be indented
72 | ERROR | There should be no white space after an opening "("
72 | ERROR | There should be no white space before a closing ")"
83 | WARNING | Format should be "* Implements hook_foo().", "* Implements
| | hook_foo_BAR_ID_bar() for xyz_bar().", or "* Implements
| | hook_foo_BAR_ID_bar() for xyz_bar.tpl.php.".
83 | ERROR | Function comment short description must end with a full stop
87 | ERROR | Whitespace found at end of line
88 | ERROR | No space before comment text; expected "// we should act only
| | on content types defined with this setting" but found "//we
| | should act only on content types defined with this setting"
88 | ERROR | Inline comments must start with a capital letter
88 | ERROR | Inline comments must end in full-stops, exclamation marks, or
| | question marks
90 | ERROR | Whitespace found at end of line
93 | ERROR | Whitespace found at end of line
95 | ERROR | Whitespace found at end of line
96 | ERROR | There should be no white space after an opening "("
96 | ERROR | There should be no white space after an opening "("
96 | ERROR | There should be no white space before a closing ")"
107 | WARNING | Format should be "* Implements hook_foo().", "* Implements
| | hook_foo_BAR_ID_bar() for xyz_bar().", or "* Implements
| | hook_foo_BAR_ID_bar() for xyz_bar.tpl.php.".
107 | ERROR | Function comment short description must be on a single line
107 | ERROR | Function comment short description must end with a full stop
111 | ERROR | Whitespace found at end of line
115 | ERROR | There should be no white space after an opening "{"
115 | ERROR | No space before comment text; expected "// user access has
| | expired" but found "//user access has expired"
115 | ERROR | Inline comments must start with a capital letter
115 | ERROR | Inline comments must end in full-stops, exclamation marks, or
| | question marks
115 | ERROR | Comments may not appear after statements.
121 | ERROR | Whitespace found at end of line
126 | ERROR | Whitespace found at end of line
129 | ERROR | Whitespace found at end of line
133 | ERROR | Function comment short description must be on a single line
133 | ERROR | Function comment short description must end with a full stop
138 | ERROR | Whitespace found at end of line
150 | ERROR | Expected 2 space(s) before asterisk; 1 found
150 | ERROR | Function comment short description must end with a full stop
151 | ERROR | Expected 2 space(s) before asterisk; 1 found
153 | WARNING | Line exceeds 80 characters; contains 107 characters
153 | ERROR | Line indented incorrectly; expected 2 spaces, found 0
153 | ERROR | No space before comment text; expected "// deletes a scheduled
| | job with these parameters. FALSE is returned if no job is
| | found for this pair nid/uid" but found "//deletes a scheduled
| | job with these parameters. FALSE is returned if no job is
| | found for this pair nid/uid"
153 | ERROR | Inline comments must start with a capital letter

Part 2: Manual Testing

If remove a content type, you must delete the variable. For example, I removed the content type "article", but the variable suna_access_article remains

kasalla’s picture

If i use

git clone http://git.drupal.org/sandbox/marcoscano/2017349.git simple_user_node_access__s_u_n_a_

it fetch only a .info file. Please fix.

marcoscano’s picture

Status: Needs work » Needs review

Sorry everybody for the basic mistakes, and thanks for the review.

All styling issues should be solved now.

@zestagio: True, thanks for the tip. I have added two additional functions, adding and removing variables according to the insertion of new content types and deletion of existing content types.

Please have a look when you have some time.

Thanks

kenianbei’s picture

Status: Needs review » Needs work

Hi marcoscano,

I've manually reviewed your module and found the following issues:

1) After enabling access for articles, I tried setting the days field to an integer and received this error:

Strict warning: Only variables should be passed by reference in suna_page_submit() (line 90 of /Users/nkerr/Sites/acquia-drupal/sites/all/modules/suna/suna.admin.inc).

I suggest reevaluating how you process this field. Perhaps it would be better to use a date element? Also, there is no default value for this field, even though a user would expect the time they entered to be displayed.

2) Using the variables table to save large amounts of settings or data is inadvisable. It would be better to use a database table to save the settings, and even better to use ctools for import/export goodness.

Hope this helps.
Norman

marcoscano’s picture

@kenianbei, thanks for the review.

I couldn't reproduce your warning that refers to line 90. Can you give some more details about the steps to reproduce?
The processing of this field using array_shift(explode(' ' etc) is done in order to filter strings such as "12 days" or "2 weeks", taking just the first numeric value. I did'nt want to use a date field because the purpose of this module is to remain as simple as possible, and with no dependencies on other modules.

A default value for the days field would be expected only in the case the access has been granted just for one user, but the module allows to deal with many users with different periods of access each. For instance, on the same node, you can set 14 days to user 2, and after that use the same form to set 30 days to users 3 and 4 (entering "3 4" on the users field). As a result you will see the string "2 3 4" as default value for the user's field.
Once this setting can be done at different moments in time, showing back to the user "14" or "30" has no meaning, once this value refers to the initiall day only.
I agree that a nice functionality to add would be a way of consulting the dates when the grant access will expire, for each user with access to each node. But this implies formatting the dates and could be seen as an improvement instead of a bug report, no?

About the config in variables, it's true, but I don't believe the size of these configurations enters in the category "large amounts of settings"... :) In fact there are many other module variables that are way bigger than what this variable would ever be, like drupal_js_cache_files, drupal_css_cache_files, addthis_enabled_services, javascript_parsed, field_bundle_settings, i18n_variable_list, theme_mytheme_settings, variable_module_list, etc...
Again, here the idea is to have no dependencies on other modules and the less amount of change in the db sturcture possible. Yes, we could just create a new table to store the config, but I'm still not convinced that the size of the information justifies it.
Do you know if there is a "recommended" limit of when it's advisable to use variables or when to create specific tables?

Thanks again for the review

marcoscano’s picture

Status: Needs work » Needs review
marcoscano’s picture

Last commit has some improvements:
- Implements email functionality, informing the users when their access grant will expire
- Implements the message on the node config page to inform the administrators which users are already allowed to see the node, and their respective expiring dates
- Some minor improvements on input validations checks

Please test and review

chr.fritsch’s picture

Status: Needs review » Needs work

Ventral Review

There are still some coding style issues with your project:

FILE: README.txt
--------------------------------------------------------------------------------
FOUND 0 ERROR(S) AND 2 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
28 | WARNING | Line exceeds 80 characters; contains 82 characters
32 | WARNING | Line exceeds 80 characters; contains 83 characters
--------------------------------------------------------------------------------

And there is also a warning from DrupalPractice:

FILE: suna.admin.inc
--------------------------------------------------------------------------------
FOUND 0 ERROR(S) AND 1 WARNING(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
129 | WARNING | Form error messages are user facing text and must run through
| | t() for translation
--------------------------------------------------------------------------------

Manual review

  • Move the checkbox for enabling suna on a content type to the edit page. We dont need a new tab just for one checkbox
marcoscano’s picture

Status: Needs work » Needs review

OK, fixed the styling issues and moved the checkbox to the vertical tabs on edit page instead of its own form, as per #9 suggestions.

marcoscano’s picture

Priority: Normal » Major

Elevating priority after 2 weeks

kscheirer’s picture

Priority: Major » Normal
Status: Needs review » Needs work
  • In suna_install(), don't set defaults for all your variables. All variables can have default provided when you call variable_get('varname', 'defaultvalue'). I think you can also remove suna_node_type_insert() for the same reason. The _delete is fine though.
  • Why is $type hardcoded in suna_form_node_type_form_alter()? Leftover debug code? Also variable_del('suna_article'); in suna_save_type_config().
  • In suna_node_view_alter(), don't call exit() directly. Just returning drupal_access_denied() should be sufficient.
  • Also in suna_node_view_alter(), can the if statement be rewritten as
      if (user_access('administer nodes') || user_access('bypass suna content access') || suna_has_access($uid, $nid)) {
    
  • Any user-facing content like $string_out should be passed through the t() function.

I have a few questions about the general approach. Managing the scheduled jobs seems to be a large part of what this module is doing. On the project page you state there are no new DB tables, but I think this is a case where a small table would make the module much more efficient. Storing a uid / nid / timestamp combo in a table, and then clearing it out during hook_cron() would be much simpler and more reliable. Potentially very large serialized arrays for each node id is a tough way to do it.

This module intentionally works outside the standard Drupal access control system, so no integration with other modules (like views) is possible out of the box. I don't think this is a blocking issue, but you may want to warn your users about this on the project page.

----
Top Shelf Modules - Crafted, Curated, Contributed.

marcoscano’s picture

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

@kscheirer:
Many many thanks for your review and suggestions.

After reading the comments of the reviewers I'm starting to have second thoughts about the convenience of this module as a full project on d.o. Perhaps it's better to leave it as a sandbox for now, and in the future we can see if there really is a need for it

In any case, I have implemented all the modifications suggested in #12, already pushed the changes to the sandbox.
(Except for the idea of refactoring and using a DB table to store the module information)

Thanks again, and sorry for the trouble!