The Restricted Links module allows admins to restrict link fields by user role and date. Links can have both activation and expiration dates. This module could be very useful for ticket links, registration links, or other links that need restricted access. While it shares similarity with the field_permissions module, it distinguishes itself by allowing users to restrict by date and duration, which field_permissions does not do.
It simply adds a new field display called "Title, as a restricted link" for users to select. It does not disturb the existing link fields in any way.
* Note : There is currently a PHP notice for array to string conversion when the widget type is changed from Title, as a restricted link back to another widget type. This is a singular notice, not repetitive, and one that I am looking into.
https://www.drupal.org/sandbox/adam-id/2372881
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/adam-id/2372881.git restricted_links
Comments
Comment #1
PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxadam-id2372881git
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
admurray commentedComment #3
saniyat commentedAutomated Review
Your module have some error that reported by the automated system. Those need to fix. http://pareview.sh/pareview/httpgitdrupalorgsandboxadam-id2372881git
Manual Review
features[features_api][] = api:1present in module info file.The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.
If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.
This review uses the Project Application Review Template.
Comment #4
admurray commentedThanks. I'll get these issues taken care of!
Comment #5
admurray commentedCannot reproduce #2, #3, or #4.
Fixed #6, #9, and #10.
Working on #1 and #5.
Need more info on #7, #8, and and #12.
#11 is a feature request, but wouldn't it require an additional module to be turned on (Date Popup)? Just trying to keep this as lean as possible.
Thanks.
Comment #6
admurray commentedFixed #5.
Comment #7
saniyat commentedFor #2, #4
1) I have used a fresh drupal installation. Without the date module. (Ref rl-7.jpg)
2) Create a content type named Links.
3) Add a link field named link.
4) Save the content type.
5) Click add a new content and enter a link and save it. Then getting this error. (Ref rl-8.jpg)
6) Now click edit the content and getting this errors. (Ref rl-9.jpg)
7) Nothing change only click the save button and getting same error on front end. (Ref rl-10.jpg)
8) Now going to field settings and change numbers of value to 2 form 1. (Ref rl-11.jpg)
9) Again edit the same node and getting this type of view. (Ref rl-12.jpg)
10) No change only save the content and getting this errors. (Ref rl-13.jpg)
For #3
1) Edit link field settings form content type. Goto default value section I have select "Authenticate User" as default role for the links. (Ref rl-14.jpg)
2) Save the field settings.
3) Again click the edit link of the field. Gogo default value section but got the previous default value reverted to module default one. (Ref rl-15.jpg)
4) So, according to point 1 if i select only one role as default then the roles selection option should not come to frontend to select.
For #7
You use time function to calculate the current date/time but this time function return the datetime of the servers timezone. so, if you set any time according to your site then it will not work. User will set time according to the site timezone not the server and many of user never know what is the servers timezone. so, use drupal time functions to calculate date time.
#8
Discard this point. Same as #3. I have said same thing in different way.
#11
No need to use date popup. The drupal code have jquery ui datepicker and you can simply use it.
#12
I mainly said if i need 1:20 Am time then what can I do. So give input field rather than the dropdown.
Comment #8
admurray commentedThanks again, Saniyat. I will work through these clarifications soon.
Comment #9
admurray commentedFixed #7.
Comment #10
admurray commentedFixed #1 and any errors related to "Array to string conversion".
Comment #11
admurray commentedFixed #2 and #4. Cannot reproduce #3.
Comment #12
admurray commentedComment #13
admurray commentedComment #14
admurray commentedSorry to change status so much. In testing, I thought I had found an issue, but it turned out to be nothing.
Comment #15
ameymudras commentedHello ,
Below are my findings of the code review of this module:
Comment #16
admurray commentedThanks, @ameymudras. I will look at how to implement these observations.
Comment #17
admurray commentedJust added a tpl so that the link display can be manipulated by devs.
Comment #18
jardac commentedHello,
the module is interesting, but I encountered following issues. I used pure Drupal instalation with Link and Date module.
1. link does not appear, only label (3.png) - function theme() on line 215 (restricted_links.module) returns only following string " "
2. it would be helpfull to have some default time in Resticted links settings (midnight?)
3. restricted field settings fieldsets go beyond the edge of admin layer (1.png)
4. time restrictions should be optional
5. with multivalue fields administrator is forced to fill Active date even for empty fields (2.png)
6. tabs instead of 2 spaces in code (eg. function restricted_links_field_widget_link_field_form_alter())
Comment #19
admurray commented@jardac, thanks for the review. I will address those issues shortly.
Comment #20
admurray commentedJust pushed fixes for #1, #2, #3, #4. Working on #5, and issue where default settings are not populating widget form.
Comment #21
admurray commentedActually, my fix for #4 takes care of #5.
Comment #22
admurray commentedJust added default values in widget fields. Looking for someone to review this again. Thanks!
Comment #23
karan_mudi commentedPlease, take a look at: http://pareview.sh
EDIT: removed long pareview.sh dump.
Manual Review
Add Implements hook_help() in your module file
Comment #24
admurray commentedThanks.
Comment #25
admurray commentedI have fixed all errors related to spacing. Drupal Coder Review module shows no errors in this module.
Comment #26
cecrs commentedAutomated Review
Link to pareview resultsPareview is still showing some minor formatting problems, mostly indentation issues.
Manual Review
In general, this looks very good. Multivalued fields work as expected with distinct settings, there are no remaining issues with the admin display, all tested permutations work as they ought to. The warning needs to be fixed, but otherwise, this is looking great! Very cool little module.
This review uses the Project Application Review Template.
Comment #27
admurray commentedThanks @cecrs!
I did remove that required field, since the default value will always be returned, and I also corrected a lot of the spacing/format issues that pareview.sh returned.
Comment #28
admurray commentedComment #29
naveenvalechaAssigning to myself for next review.
Comment #30
naveenvalechaAutomated Review :
http://pareview.sh/pareview/httpgitdrupalorgsandboxadam-id2372881git
Please specify on the project page how the module functionality differ from the field_permissions module.Drupal community holds a strong "collaboration rather than competition".
Comment #31
naveenvalechaComment #32
admurray commentedWhile the similarity exists to restrict based on role, the Field Permissions module has no date-based restrictions as it is solely restricting on the basis of permissions/roles.
Comment #33
admurray commentedComment #34
naveenvalechaPlease add this to the project page and the issue summary above so that it will be clear to next reviwers.Thanks! for specifying.
Assigning to myself for next review.
Comment #35
admurray commentedComment #36
admurray commentedThanks. I have updated both pages with that info.
Comment #37
naveenvalechaAutomated Review
No Best practice issues identified by pareview.sh / drupalcs / coder. Please take a look at http://pareview.sh/pareview/httpgitdrupalorgsandboxadam-id2372881git
Manual Review
The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.
Please take a review bonus to come up in hight priority list so that you will get the reviews from git admins.
This review uses the Project Application Review Template.
Comment #38
naveenvalechaComment #39
admurray commentedThanks for the review. Do you have a screenshot of the error in question?
Comment #40
admurray commentedComment #41
naveenvalechaAttached the screenshot.Sorry for coming late was bit busy with some other stuff.
Comment #42
admurray commentedOk, so 2 questions :
1) Any direction with this one? It seems to be a unique edge-case where the user manually changes field widget displays multiple times, and in no way actually affects the display/operation of the links.
2) Based on that, is this minor notice really one that should hold up the release of a module?
Comment #43
naveenvalechaPlease add this notice on the issue summary page so that others reviewer already aware of this.Just discussed with mpdonadio over IRC.We can set it to Needs Review
Comment #44
admurray commentedThanks. I will add that note.
Comment #45
admurray commentedComment #46
admurray commentedAnyone else up for reviewing this? I'd like to see this approved at some point, considering that I submitted it in November.
Comment #47
naveenvalechaI would recommend you, please help to review other project applications to get a review bonus. This will put you on the high priority list, then git administrators will take a look at your project right away :)
Comment #48
cfreed commentedHi admurray,
I found your module interesting, especially for its date-restriction capability, that is not available in field_permission module, as you pointed out.
So here is my review.
Automated Review
There is a warning reported by http://pareview.sh/pareview/httpgitdrupalorgsandboxadam-id2372881git:
FILE: /var/www/drupal-7-pareview/pareview_temp/restricted_links.module
Having looked at the code, I'm surprised: sure it does not prevent the code from running, but what's the point?
The
function _restricted_link_check($item, $user = NULL)is only invoked once, as_restricted_links_check($item);, so you always get$user = NULL, and finally the$userargument is useless. It should be suppressed, as well as theif (!isset($user)), IMO.Manual Review
But you should review the confusing information about enabling date restriction (line 33), as already suggested by @saniyat (#3, 6).
So for a more fiendly result, why not to merely:
'#states' => ['invisible'...condition (module, line 181 and next ones) into'visible'with both checkboxes TRUE).Even if obviously there is no realistic way to presume which default date would reach the user need, any arbitrary date could be helpful: why not to simply use the activation date (notably because we probably often keep hours/minutes unchanged)?
Furtherly, custom setting of a delay (number of hours, days, ...) based on activation date would help too.
variable_get('date_format_short', 'm/d/Y - H:i')as date module suggests.Furtherly, custom settings capabilities would be very welcome, including making hours/minutes optional as already suggested by @jardac (#18, 4).
The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.
If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.
This review uses the Project Application Review Template.
Please don't feel attacked by this long review! Above are only 2 points that should be (helpfully easily) corrected. Other ones are only suggestions and don't hold up release, IMO.
BTW, I looked at the notice that was mentioned by @naveenvalecha (#37, 1): you probably already observed that it comes from
drupal_attributes()interpretation of some data passed thrul(), so clearly coming from lines 52 and 59 in theme.inc.I'm not familiar enough with this part of Drupal code, so I can't exactly explain what happens, but I guess it regards line 43, where
$link_optionsis populated by the$vars['elements']: when previously due to pure "Link" module's, they probably contain some not-array attributes-list (either null, empty or simple string). HTH.Comment #49
cfreed commentedComment #50
PA robot commentedClosing 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.