CiviCRM Community Forums (archive)

I am using ACLs to be able to give limited read access to certain users.

I have set up a role "Role A"
Who have access to see contacts from "Group A"

So far everything is fine, but then I want to limit what information from these contacts that users with "role A" can see.

I tried creating a profile "Profile A" with the fields I want "Role A" to see.
Then I created a rule saying that "Role A" should see "Profile A" but Role A still sees all data from group A.

Am I going about this the wrong way? Or am I just missing something?

[Edit]
Seems I was wrong, that is not how profiles are used. Looking into it some more and will get back as soon as I find a solution.

As to the custom data I belive you are correct. It is the standard data that I don't think I cant limit with profiles.

As I understand
Dataset A are a subset of custom data
Group A are a subset of contacts
Users A have particular mgmt roles
Role A is the Role Users A need to have under ACL to 'see' the contacts

So Users A are restricted by Role A to see only Group A

Now he wants to also restrict Users A to only seeing Dataset A of Group A.

It is something I am also grappling with - well should be, but you know, hoping the answer will pop out of the woodwork.

I have set up ACL to divide our party in to regions. And have a group of managers for each region. Now I am being asked to make some 'second class' managers who are both restricted to the contacts in their region, but also only have access to some of the custom data. Will profiles do this for me?

If User A needs to use the "actions" drop-down (Send Email to Contacts etc.) - then you can't limit their access to CiviCRM to only Profile-based screens.

(Although if that's the only action they need - you might be able to customize the Profile View template to add a link to that action's URL ??)

However, you can create ACLs which provide access to specific Custom Data Groups (i.e. set of custom fields) for roles. Then if you disable "access all custom data" from the Drupal permissions - I think this might achieve what you need. Note that there may be some "gotchas" in this approach - and you'll need to segment out any custom data groups that might need to accessible to "everyone" (i.e. for input on a public-facing page - if you do online contributions etc.).

Perka - we have been 'warned' from using the 'email contacts' for anything more than relatively small jobs. Just in case you hadn't picked that up. CiviMail for larger jobs so that opt-out etc can be utilised.

oh such flattery - glad to know there are still limits to push