In summary, I am looking for a content-based access control solution, NOT a user role-based solution.
The scenario: Page 1 contains content from various access control levels (i.e. levels a, b, and c).
Currently in Drupal, you can display/hide content based on user role. However, I want to block access to the entire page if the user is not in the highest content level required.
Example: A user with access level a and/or b would be blocked from seeing page 1, but a user with at least level c would be able to see the page and all of the content on it.
The catch being that the per-page access levels must be dynamic to prevent incorrect page tagging as content is added, updated, or removed.
Does a module like this exist already, and if so, what is it?
If this doesn't exist, is there a straightforward way of implementing this?
Server configuration is Drupal 7 with some Open Atrium 2 modules.
I'm not sure on what you mean on access control levels, but lets say they are functions you can call (with returns).
In this case you should implement hook_node_access for controlling access to a node or hook_field_access for controlling access to a field.
https://api.drupal.org/api/drupal/modules%21node%21node.api.php/function/hook_node_access/7
You should return 'NODE_ACCESS_DENY' from it if you want to deny acces.
https://api.drupal.org/api/drupal/modules%21field%21field.api.php/function/hook_field_access/7
You should return FALSE if you want to deny access to a field.
Related
Please i need to understand the idea of wagtail root[depth=0] page. Because for me homepages must be on the root level but currently all homepages are on depth=1 level, why and what is the idea to have root level page.
I checked docs etc, but didnt find clear info of this idea.
Also why homepages[depth=1] related to site object and not root[depth=0]?
It's mostly an implementation detail to make Wagtail's internal logic simpler. For example, the Page model has copy and move methods, which take the new parent page as a parameter. Having a fixed, non-editable page at the root level means that there's always a meaningful value we can pass as the parent - if the root node wasn't there, we'd have to implement separate code paths for "move a page to a new parent" versus "move a page to the top level".
However, there's also one place where the root page is directly meaningful to the site admin: it's possible to assign permissions to that page (through the Settings -> Groups area). Since permissions propagate down the page tree, this means that the permission will apply to all pages across all sites. For example, if you want to give a (non-superuser) group the ability to create new homepages, you can do that by giving them 'add' permission on the root page.
A lot of my site is dynamically generated dependant on the user location.
To get an initial fix I am currently using the Smart_IP module which does this based on the user IP address - which works great as a starting point. I can access $_SESSION['smart_ip']['location']['longitude'] & $_SESSION['smart_ip']['location']['latitude'] as required - perfect!
But I need to allow my user to override this..
Using HTML5 geolocation. I want to only do this on user request, ie click 'locate me', rather than requesting their location uninvited.
Using one of a few pre-defined locations selectable by the user.
Using an inputed address by the user.
Is there any drupal module I can use for this, or how else could I achieve it?
-
Just to clarify, I am talking about anonymous users here - the general public visiting my site. I just want them to be able to refine their 'location' by overriding the defaults I give them using smart_ip.
I suggest to use Geolocation field and all it's submodules or Geofield. Last one provides more input methods.
Use the Address field module to allow the user create multiple addresses into a node (or even into his profile), Geocoder module to get the lon/lat from these addresses and then a Views to display them in a list.
Same as 2 but without views.
If you want to allow user select one of the 3 methods you can use an other - helper - field (eg a select list with the 3 options).
Finally you should add an extra field to store the lat/lon pair final values maybe with Computed field module or 2 simple textfields that will get the selected values through javascript.
I'd like to restrict access to a view based on the CURRENT users role. Not the author. For example, if a user has the authorized user role then they can see the content of the view. If a user is anonymous then they are shown the No Results Behavior of the view. I can't believe there is no way to do this. I know there is the Access settings, but I don't want the anonymous user given an access denied message.
One method I can think of:
Use hook_views_query_alter(). Check if the current user belongs to the set of roles you are interested in. If he doesn't, add a condition which is always false, such as 0 = 1. To see how to add such a condition in code, see the example on this page: http://api.drupal.org/api/views/views.api.php/function/hook_views_query_alter/7. The resulting view will not have any result on adding this condition.
Neerav Mehta.
Drupal Development
For the contacts object, I have a custom checkbox which represents whether the contact owner wants the contact information (email and phone) to be visible. Most of our contacts will be completely visible to everyone. However, for a few contacts, we want them to be visible but their contact information needs to be hidden to everyone except for the owner.
Is there a way to set field-level access dependent on another variable? Could you create a workflow to redirect to another page layout if the contact information is visible? If so, can you restrict objects to certain field layouts depending on whether or not you are the record owner? And would would the contact information for "hidden contacts" still show up in reports?
Redirects, custom Visualforce view page etc hacks are all nice and shiny until you realize people will be able to pull data they want via some reports, list views, Outlook integration, mobile apps etc ;)
There's no straightforward answer because field visibility is really "all or nothing" (by Profiles & Permission Sets). Owner/Role-related stuff will help you only if you'd store data in some new related objects.
Another option - Store public part in Leads (public read only for example) and sensitive part - in Contacts (private)? Some lookup to link the 2, maybe a trigger when new Contact is created and you're good to go.
Last but not least - have a look at https://salesforce.stackexchange.com/questions/777/can-i-grant-different-field-level-security-based-on-record-ownership for some ideas.
If I understood correctly (My english...) You could create a new RecordType and a new customized page layout without this fields assigned to it, then you have to create a WFR that change the Recordtype when the cheked field becomes true.
I'm assuming that you know how you have to give permissions to this new Recordtype...etc
Hope this helps.
In Drupal 7, I have added a block to the Content region of the User page. I did this by specifying
user/*
in the Visibility Settings -> Pages -> Show block on specific pages -> Only the listed pages setting.
However, because the wildcard accepts anything, now the block appears on the User's edit page.
Is there a single number wildcard, like
user/%integer
that I can use here so that the block only appears on the User view page?
How can I hide this block on the User edit page in Drupal 7?
You can try enable PHP filter module, so that you can enter php on Block visibility settings page.
There you can check for argument like
<?php
if(arg(0) == 'user' && arg(2) != 'edit' )
return true;
else
return false
?>
These days there is another alternative available ... which doesn't require the PHP filter to be enabled (which you should try to avoid whenever possible) ... Just use the Rules block visibility module. Here is a quote from its project page:
The Rules block visibility module allows Rules components to be used to control block visibility. This provides Drupal administrators and developers extreme flexibility in controlling when blocks should be displayed on their websites, in addition to the default visibility options provided by Drupal.
The general idea is that if you can do it with Rules, you can use it to control block visibility, so the possibilities are limitless.
Need to show a block only for users registered more than a month ago?
Perhaps you have a block that must be shown only between 8am-5pm on weekdays?
What about displaying or hiding a block based on current weather conditions?
All of this can be done by using Rules block visibility.
With that, and as per the "if you can do it with Rules, you can use it to control block visibility" above, you've reduced your question to making Rules intercept the situation where someone uses an URL like /user/*/edit (replace * here with any allowed value for uid). If you're not familiar with how to do that with Rules, then have a look at my answer to the question "How to make the permissions of a module more granular?" (and pay attention to the regex-expression included in the sample rule I included there).