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
Comment #1
PA robot commentedThere 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.
Comment #2
zestagio commentedPart 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:
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
Comment #3
kasalla commentedIf 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.
Comment #4
marcoscanoSorry 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
Comment #5
kenianbei commentedHi 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:
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
Comment #6
marcoscano@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
Comment #7
marcoscanoComment #8
marcoscanoLast 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
Comment #9
chr.fritschVentral Review
There are still some coding style issues with your project:
And there is also a warning from DrupalPractice:
Manual review
Comment #10
marcoscanoOK, fixed the styling issues and moved the checkbox to the vertical tabs on edit page instead of its own form, as per #9 suggestions.
Comment #11
marcoscanoElevating priority after 2 weeks
Comment #12
kscheirer$typehardcoded in suna_form_node_type_form_alter()? Leftover debug code? Alsovariable_del('suna_article');in suna_save_type_config().$string_outshould 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.
Comment #13
marcoscano@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!