3

We have an Organisation with cca. 400 local branches and have trying to achieve a following ACL behaviour:

-- Organisation members needs to be able to login and have access to their Organisation members records only.

-- Organisation admins may administer all members in their Organisations and Organisation itself (and in theory could be administering more than one Organisation thus more members).

-- Organisation admins need some kind of dashboard which gives them access to their own societies.

-- Main civiCRM admin(s) need to be able to assign ACLs to a user

We have Relationships in place, so each Organisation has it's members listed in Relationships tab in civiCRM. Now, this is a workaround which seems has to be done:

1. civiCRM side

1.1. Create Group (AccessControl) for each Organisation

1.2. Create Group (AccessControl) for each Organisation Admin Users (NB! SmartGroups wi not work since there is no AcessControl for them, there is a thread from 2007 regarding this: http://forum.civicrm.org/index.php?topic=1645.0)

1.3. Create ACL Role for each Organisation Admin

1.4. Assign each ACL Role to corresponded Organisation Admin Group

1.5. Create ACL for each Organisation where Role = Soiety Admin Role and operation = Edit and Type of Data = Group of Contacts and Group = corresponded Organisation Group

2.Drupal side

2.1. Create Role for each Organisation Admin

2.2 Grant access:

  • Admin Menu

  • CiviCRM: profile listings and forms

  • CiviCRM: profile listings

  • CiviCRM: access CiviCRM

  • CiviCRM: access Contact Dashboard

2.3. Create/move DrupalUsers based on Civi Contacts we'd want to be admins and assign each of them to own Role

2.4 Use "CiviMember Roles Sync" http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMember+Roles+Sync to sync Drupal Roles with Civi Groups

We've studied some related threads:

  1. "Multi-level Organization ACL Permissions" Multi-level Organization ACL Permissions ( where multi-site workaround suggested sounds even more overhelming than current approach,since we have 380+ organisations and all Contacts data currently stored in single CiviCRM database ). Have tried also "local permissions extension we built for the National Democratic Institute" hoping that it would be possible to convert geografic-centered approach to Organisations-centered; may be it's a way to go, although it needs deep code diving.

  2. "Allowing group management to users with limited permissions" Allowing group management to users with limited permissions from where we've found out that " users can only view the groups for which they explicitly have an ACL for. " which doubles all work, since now we need a pair (Admins and Members) of Role,ACL,Group for each Organisation.

  3. Yet another option found has been a "Related Permissions Module" extention from nz.co.fuzion ( http://github.com/eileenmcnaughton/nz.co.relatedpermissions/zipball/master ) suggested among related threads at stackexchange or forum.civicrm.org, however it doesn't seems to be compatible with most recent version of civicrm. This one sounds like a best "theoretical" approach so far since it tends to use component (Relations) which have been already installed and configured. However it's hard to find out from here if it worth investment of development hours to make it work since it's hard to say if it was working the way we need.

Afraid, not all related links from all sources are listed here (like related pages from book.civicrm.org or wiki.civicrm.org), we've studied a lot.

So, any fresh advice will be highly appreciated; can't believe CRM might have such,well, let's call it "complex" permissioning system.

Improve this question
7
  • 1
    To clarify what 'not working' means in terms of the relatedpermissions extension. The extension will 'work' in terms of the ACL part - ie I have a permissioned relationship of branch Y & branch y has a permissioned relationship over 85 people then I have permission over those 85 people and the branch. The part that doesn't work (athough anecdotally it may) is that the extension injects extra fields into the relationship type form, allowing you to specify that a particular relationship type will always be permissioned. The breakages is specifically around the the UI on this form
    – eileen
    Commented Jul 17, 2015 at 23:21
  • 1
    Also note, if you DO use relatedpermissions extension you ALSO need the entitysettings extension & you should obtain both from github rather than the extensions directory to be sure you have the latest
    – eileen
    Commented Jul 17, 2015 at 23:24
  • 1
    If you need any help with using relatedpermissions or entitysettings extensions please get in touch with either Eileen or myself.
    – petednz - fuzion ♦
    Commented Jul 18, 2015 at 1:44
  • Hi Eileen and petednz, haven't expected you'd participate in discussion! Thanks for a chance to talk to you! Your extension sounds like the best available alternate of default ACL workaround for our needs. I've tried to follow extensions docs carefully. Mean, have got both entitysetting and relatedpermissions 1.2 from github, but after enabling extensions have got this ( awesomescreenshot.com/0e652su886 ); also, not really sure what exactly "Always Permission A to B" and "Always Permission B to A" should work. Frankly, not even sure how all this thing should be configured.
    – yurg
    Commented Jul 18, 2015 at 14:43
  • @petednz Yes, please, I do need help with an extensions; will you please tell which way of getting in touch would be more convenient? We could continue here so thread could be found useful to someone, not sure, however, if our case is quite unique, since there is not much about similar issues at civicrm forum/wiki and here, at stackexchange. Thanks a mil!
    – yurg
    Commented Jul 18, 2015 at 14:59

2 Answers 2

Reset to default
4

IMHO it seems like you really need a consultant for this stuff. Hopefully an organization of your size (400 chapters with an unknown # of people per chatper) has budget for help.

But let me offer a few bits of advice:

  1. the "corresponded Organisation Group" as you put it CAN be a smart group, thus people (not admins) can self-select their own groups when they signup and/or register if you use a custom data field for "select your chapter".

    1. CiviMember Roles Sync doesn't work as you describe, that's Civi Group Role Sync for that functionality

    2. I'm not sure why you feel people need to use CiviGroup Role Sync

    3. Don't understand your point 2.3

So I hope that helps, I've done this on a smaller scale for a group with 12 national chapters and 20-30 people per chapter, it works pretty well. Please remember I do think a consultant with experience on ACL is needed.

Improve this answer
3
  • What you're trying to do is not easy without custom coding. Setting up and maintaining so many groups is likely to cause problems even if you manage to make it work. As CiviTeacher suggested you are better off working with someone who has done this sort of implementation before. Working with a CiviCRM Partner and Contributor makes CivCRM better for everyone.
    – Sanjay Jain
    Commented Jul 17, 2015 at 18:48
  • Thank you for an input, it's valuable to talk to someone who has relevant experience, believe stackexchange is all about experience exchange, not sure if "paid development" advised as preferred option would be our #1 and only option indeed. So, let me ask if you have made a similar setup you've mentioned manually, following all steps for each of 12 chapters? Thanks!
    – yurg
    Commented Jul 18, 2015 at 14:14
  • To be clear I'm not advertising my services, and I'm not available as a consultant. My Stack Exchange to you advice is both technical and instructional in "how the Civi community works" - I'm trying to help you get what you want. I did a similar setup as I describe for an organization and it worked well. For your situation, I think that someone who is a consultant could help you achieve your goals more rapidly and efficiently than Stack Enchange can (as wonderful as Stack Exchange is) it's more for simple "how to" solutions not detailed project planning.
    – CiviTeacher
    Commented Jul 19, 2015 at 6:32
0

Well, it has turned that unfortunately it's a feature one would have to pay for.

Improve this answer
3
  • Can you please clarify what solution you ended up using as it might benefit others reading this ticket
    – petednz - fuzion ♦
    Commented Aug 6, 2015 at 21:53
  • Yeah, on its own this isn't a very helpful answer, but if you edit and elaborate, it would be very useful to share your experience @user1924232
    – Andie Hunt
    Commented Aug 8, 2015 at 3:50
  • @petednz My honest thoughts about it might start a flame which would be a way out from a question itself and more about your sponsorship/funding seek methods. So let it be as is, mean this feature demands a paid development.
    – yurg
    Commented Aug 17, 2015 at 10:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.