I'm trying to set-up an access control system in CiviCRM to restrict access of certain users to certain custom data field sets. I'm planning to use Civi ACLs to achieve this, though my understanding is that they are overridden by Drupal permissions, and therefore the 'CiviCRM: access all custom data' checkbox must be unchecked within Drupal permissions. I will then be able to use ACLs to allow access to these fields to only the users I want.
My problem is that I've created a Drupal role 'crm user' with this box unchecked, but when I log in as a user with this role I can still see all the custom data, which I shouldn't be able to do. Does anyone know what I might be doing wrong? Are there any other Drupal permissions that need to be removed?
Ensure that your 'crm user' role has the minimum required permissions. As noted in #Flying's answer, the 'Administer CiviCRM' permission gives users access to thee whole of CiviCRM and therefore overrides the 'access all custom data' permission.
Note that if you are using custom data fields in exposed profiles or forms that need to be accessible to anonymous users or logged in users then those roles will need to have the 'access all custom data' permission so that they can see and complete those fields, so you'll need to be careful about setting up your user roles and permissions.
Once you have your Drupal permissions doing the right thing you can then move on to setting up the ACLs that you need within CiviCRM.
If the user has the Drupal access of "Administer CiviCRM", that would override the "CiviCRM: access all custom data"-setting.
So any user with the Drupal access of "Administer CiviCRM" can access CiviCRM custom data, regardless of the "CiviCRM: access all custom data"-setting.
Related
I've tried the "Protected Node" module, but that goes to the 404 instead of the password prompt page which it's supposed to give.
Also tried the "Simple Access" module, and after getting it to control access, realised that it still shows users the "edit" menu and there doesn't seem to be a way to switch it off for them.
Thanks to anyone who can help.
I have used the "Node Access" module before. But for one site I had to work on recently, I needed something that allows me to restrict access for anonymous users on a single page. Only visitors, who have received the password should have access.
Installing the Node Access module and creating a specific role seemed to be an overkill for this limited requirement, and I went with the "Protected Pages" module, which allows to set a password for a certain path. (d7 only)
Access to the admin is usually controlled via the user permissions as for limiting access to a specific page, this could be achieved with Panels.
Use NodeAccess module to restrict that page based on role.
Users with the 'grant node permissions' permission will have a grant
tab on node pages which allows them to grant access to that node by
user or role.
I've set up different roles and when I add/edit content I want to be able to check who can view this page by simply checking the applicable roles, is this possible? If so, how?
Thanks
Sounds like the Node Access module is what you're after - http://drupal.org/project/nodeaccess
"Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab."
I need newly created users to be assigned to a particular role as default.
as default, a new user automatically assigned as "authenticated user" I also need as "content admin (custom created role)"
any idea how to do that?
appreciate helps!!
Why I need that?
I create a content admin role for client, I dont give administrator access. and they need the ability to create new users as content admin. as default I need to give access to "administer permission", but by this way they can create administrator user as well :/ and can messed up with the site. So, if I can assign content-admin role as default to new created users, i wont give administer permissions access to client.
Take a look at the module Auto Assign Role. It allows you to automatically assign roles to new users. You can also set different role presets depending if a user registered himself or an admin created the account. Currently it is only in dev for Drupal 7, but from the issue queue it seems to be in working condition.
From the project page:
The Auto Assign Role serves three primary purposes. The first is to
provide an automatic assignment of roles when a new account is
created. The second is to allow the end user the option of choosing
their own role or roles when they create their account. The third is
to provide paths that will trigger a specific role when an account is
created. The administrator has full control over these functions and
can have them working together or independently of each other. Auto
Assign Role is integrated with the Content Profile module so that you
can have content types serving as registration pages. You can even
replace the default user/register page with a customized version of
your own design.
I am using the calendar module with its iCal support for Drupal 6. I have made my event type which appears on the iCal feed. However, I want to make the event content type private, so only authenticated users can read it. By doing this they will not show on the iCal feed. Is there any way that I could get the iCal feed to still show these events?
I agree with calebthorne that normally a feed is public; I can understand the need of making a feed public for a group of users, and not to the anonymous users.
If the feed is created by a view, then you can change the view, and restrict its access to the users you want.
As you can see in the screenshot, you can restrict the access to the users with a particular permission, or to the users with a specific role (authenticated user is one of them).
Hmmm... I would give the Node Access module a look. I use this module to restrict access to content based on content type. I have never tested whether this works in conjunction with the Calendar module but it is worth a shot.
Some more details about the Node Access module (from its project page):
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
How do I give a specific user editing rights to a specific node?
I have a user role named "Student". Multiple users have that role, only a few of them can edit a node. How can I realise this?
I'll try and cover a few use cases, with how I would solve them:
If all members of a category of users can edit any node of a certain type
Create a new role for that subset of users ('Super Students', as Emyr suggested) and grant them 'Edit content of type' permissions through Drupal's core permission system (no node access module required)
If all members of a category of users can edit specific nodes
Create a new role for that subset of users and grant them edit permissions on the specific nodes (a node access modules is required, such as Node Access or Content Access). This will also require that someone has the permissions (and time) to grant access to the role whenever a new node is created.
Some users can edit some nodes; there is no 'elite' group of users who can edit all nodes, and not all members can edit the same nodes
This will require a node access module, such as Node Access or Content Access with ACL. There will also need to be administrative users who have the permission to grant other users access to edit the nodes.
Allow users to grant others access to edit a node they have created.
I implemented this recently with a user reference CCK field and Node Access User Reference. You can grant users permission to edit their own nodes through the core permissions system and they can then add other users to the user reference field. In my case creators are not given that permission and I set up the default value of the field to the creator's user id, which allows a user to remove themselves from being able to edit the node.
These all assume there is no categorization for your content. You may be able to utilize node access modules based on Taxonomy or Organic Groups if your content and users are organized sufficiently.
For sort of abnormal permissions stuff like this, I've always found that a small custom module is the way to go. General node access modules have to be general enough to be useful for a lot of different cases, which generally makes them sort of messy and confusing.
For this specific one, you could create a module that implements hook_nodeapi and on $op==prepare, check the user's ID against your user reference and do a drupal_goto the access denied page if they don't match up.
You can do this with Flexi Access. Giving a specific user the "update" privilege on a node will allow him to edit the node.
For more options, see the page: Overview of Node Access modules # Drupal.org.
Have you tried either Node Access or Content Access?
If only a subset should be able to edit nodes, you need an additional "super student" role.
The Node Access module may help you set appropriate permissions on the nodes. Here is an excerpt from its project page:
... provides roles and user specific security permissions for menus, menu items, nodes, and security integration into the administration and help systems. We would like to provide this suite of modules back to the community to share the usefulness of the suite and involve the community to provide additional support, testing, and moderation.
Special care was taken to ensure the usability of permission management was consistent across all sections of the system (nodes, menus, menu items). Also each security module uses a cascading security scheme to allow global security and the option to override or define exceptions to the security model for individual items.