CiviCRM Community Forums (archive)

Hi.
I have a request from my users that seems simple, but I don't see an easy way to do it :

We have a test civicrm install for evaluations purposes. Only staff users can log in the crm, and all authenticated users can view/edit all contacts and view/edit/create all groups at the moment.

Now I got a request to make some contacts private to the management team : all contacts in a group or with a certain tag should be viewable and editable only by a select few users.

I read the ACL docs and the ACL demystified blog post, but I must have missed something :
If I understood well, I have to
- create a group to store the privileged users (priv_management_admins)
- create a group to store the contacts to be made private (priv_management)
- create an acl role (priv_management_admins_acl)
- assign it permission to edit the contacts from priv_management.
(I did not find a way to use a drupal role for fine-grained permissions)

But if I do this, any user can still edit the groups priv_management and priv_management_admins.
If I remove the 'edit all groups' permission from all users in drupal, two problems arise :
- I have to recreate an acl set for each existing group in the system (it could be hundreds in the long run)
- users can no longer freely create and manage groups, this does now systematically require an admin's intervention
- any users allowed to create groups can edit and override ACL groups
- I found no way to define an acl targeting an exclusion (like !='priv_management'), so each time they create a new group, acl's must be modified by an admin to include it

If I then need to add a private custom field or fieldset to all contacts, it gets even worse...

So, did I misread the documents, or missed an important point somewhere, or is it impossible to use ACLs for a specific group and still let all users create/manage all other groups (acl by exclusion) ?

Also, as drupal roles are not used, users will have to be manually added to groups. We use ldap for drupal authentication and roles mapping, did I miss an option to auto-add drupal users to civicrm acl groups ?

We use drupal 6 + civicrm 3.3.1, if these features are not possible in 3.3.1, are hey present in 7.x/4.x ?

(We're still trying to convince the management and it staff here that civicrm is a good idea, but it's an uphill battle. Any help or pointers are welcome! )

check:

http://svn.civicrm.org/hrd/trunk/drupal/hrd.module

basically only people with the drupal permission: "access secure contacts" can access that specific group

lobo

Hi,

Let us know if you find something better suited, but I'd suggest to focus first on the features, knowing there is a solution for your specific acl needs.

X+

Assuming the competing closed source products aren't free:
- I'd review the spec see what is on both sides and what missing on both sides
- compare the associated cost of adding them (not even sure that's an option to add it on a closed source product, no matter the price),
- add the licenses/other maintenance cost for the close source product

I my experience, that's a mistake to assume open source is free. Some of the cost you have paying the licenses for a closed source product you will pay for custom development or adding new features.

For what I've seen, it often ends up being (much) cheaper using an open source product and with better fit solution, but it won't end up being free, neither open source nor closed source.

X+

It really is a features set problem : why would management, used to pay for software with the belief that they will have great support (no matter how actual support might fall short of that promise), accept to use free but unsupported software ?

Well, only if it provides equal or superior features and does not require lots of support.

Why would you want to go unsupported? Check out the list of professional providers, Got quite a few that can support it. Added benefit, if the support fall short of the promise, you can switch to another provider.

Might be me that don't understand the distinction you make between support for close and open source?

Also, not quite sure what distinction you make between support and development. Say you go with SAP, your "support" provider/integrator will develop custom functions for you, as part of the support.

As for the features, the latest reports I've read said Civi is competing very favourably, I'm genuinely curious to see what competition you'll find better suited.

Again, no hard feelings here, just a reality check. This is presented as 'enterprise level' CRM, so features such as fine grained permissions are to be expected.

No hard feeling on my side either, and we like that kind of feedback, hence all the questions

Furthermore, for such sensitive software, setting and managing permissions must be obviously easy to do otherwise you have the constant risk of accidental exposure of data you thought was protected.
Requiring lots of permissions micromanagement as the system is used multiplies that risk above acceptable levels.

My experience is that it's easier to have an extensible system that allows you easily to customise to do what you want than a one size fits all with a bazillion of options, especially for security.  And things like who can put whom in which group based on their permission (and they type, how old is the record, how many modifications, the phase of the mood...) is something that every organisation seems to have a very different idea and different rules.

Well, at least I find much secure to have one custom module that will check based on my specific rules if the user can or can't add the contact to the group in a few lines of code than being faced with an interface that contains every single option to cover every single need. So Civi is made so you can put the permissions and complex rules you want, offers an UI to cover the common needs, and a clear system to extend it via the hooks to cover the rest.

This being said, I think that's a quite common need to be able to request a different permission to add a contact to a "ACL group" than to add to a normal group. If this can be made generic enough, could be contributed back to the core, and it doesn't sound like a complex/expensive one to code.

X+

As for the evaluation, I don't understand why you can't evaluate at all because one user could add a user to a group she wasn't allowed to. ie. that's mandatory to know it can be blocked later, but it's  pretty much irrelevant for user acceptance and feature, isn't it?

This amounts to show people something that partially works, and telling them 'it will work better than that when we'll use it, trust me'. This is very bad in terms of trust and user acceptance.

This amounts to show people something that partially works, and telling them 'it will work better than that when we'll use it, trust me'. This is very bad in terms of trust and user acceptance.

Its an EVALUATION. not end user training or acceptance testing. You are checking for how close a match things are etc ..

maybe might make sense for you to find something that is better suited for your needs. Would be great if you can report back and let us know what it was so we can potentially learn and improve civi

good luck

lobo