Author Topic: Real Private Groups (Read 1744 times)

bazaarsoft · February 20, 2008, 12:42:26 pm

Hello,

Noob issue: I'm looking for a way to create a group that only an administrator can assign users to. The most restrictive setting for a group is current User and User Admin, but, unfortunately, I don't want any user putting themselves into the "Board of Directors" group! Am I just missing something really obvious?

AAACK! It's even worse! I have the groups available for any user to update on a page of their profile, but I'm only showing the groups marked as "Mailing List", but, when they update those, the other group memberships that aren't "Mailing List" groups are undone! I MUST be using groups wrong...

OK, so, here's the two things I'm trying to do:

1) Group our board of directors together in a list that can be used in CiviMail as well as for other purposes. I don't want anyone but an admin to be able to put someone into or take someone out of that group
2) Use multiple groups to represent multiple mailing lists that people can arbitrarily opt in and out of
3) Use groups, not for mailing lists, but to group people in other ways, like, say, Volunteers; again, the user should be able to put themselves into/out of the group

I'm not sure that using the existing group mechanism will work for all three of these; thoughts?

Thanks,
jay

Donald Lobo · February 20, 2008, 04:03:57 pm

1. not sure what version you are using. If you are new, i would recommend you install and use 2.0 beta

2. Not sure what you mean by, "when they update those, the other group memberships that aren't "Mailing List" groups are undone! I MUST be using groups wrong...". Can you be more specific or better yet, reproduce this on the demo server (http://demo.civicrm.org/) and let us know how to reproduce

3. There are 3 types of users in CiviCRM (at a very broad level)

a. A CiviCRM admin who pretty much can do anything. This is typically the tech person in the org.
b. A CiviCRM user who has access to CiviCRM but does not have access to some CiviCRM functions (like administer CiviCRM etc). These are the staff members / advanced volunteers.
c. The end user. These are typically your constituents. People who donate / sign up for an event etc

Given the above, here are some answers to your queries:

1. users a and b above can add / remove folks from the BOD list. There are ways to restrict this using ACL's but its a bit too complex to discuss now
2. Yes, make all these groups visible as Public and of type Mailing List
3. You can do this with groups also, if your dont mark them as mailing list, they will not appear in the CiviMail selection boxes

lobo

bazaarsoft · February 21, 2008, 01:09:36 pm

Thanks for your reply,

I was just composing a very long reply with lots of description when I realized that I have no idea how to "really" set up the #3 type of user. What I'd like is for them to: 1) use event sign-up pages, 2) edit ONLY the information I show in CiviCRM Profiles as they're linked to the "My account" page (don't want them to see the "View Contact Record" or "View Contact Dashboard" links), 3) Donate, 4) subscribe/unsubscribe to mailing lists.

OK, I've recreated the group issue on the demo. There is now a profile called "Group Membership Bug" (not a bug probably). That shows a list of all groups that are Public. Put the demo user (Eileen McNaughton) into a group that's defined as User or User Admin, then go to the "My account" page, click Edit tab, click on "Group Membership Bug" tab, change the groups, and save, and now Eileen is no longer in the User or User Admin groups.

That was my attempt to restrict the user to change membership in just the groups (more specifically, mail lists) I wanted (by specifying those as "Public") while leaving the other group memberships alone. Obviously, that doesn't work. So the question is, since group membership can always be changed by the user, how can I "group" people together in a way that's controlled by specific users/admins? Or, better yet, how can I get users who have NO access rights to CiviCRM to be able to do the things listed in the first paragraph?

Sorry if I'm just missing something fundamental here...

One last thing: should I really use 2.0 beta? I usually shy away from beta versions in favor of shipping versions which generally have more answers to questions generally available since they aren't new.

Thanks much!
jay

Dave Greenberg · February 22, 2008, 09:17:02 am

Thanks for recreating the "Group Membership Bug" - this is indeed a bug and I've posted an issue for it (where you can track progress):
http://issues.civicrm.org/jira/browse/CRM-2719

Type #3 "user" requirements can be configured using Drupal "roles" (for example, the default "authenticated" role) to NOT have "access CiviCRM" permission - AND to grant them:
- profile listings and forms
- make online contributions
- register for events
- access custom data (if you want them to input / edit custom field data in a profile or online contribution page)

Then you'll create links to expose one or more profile forms to your users, as well as any contribution and event registration instances:
http://wiki.civicrm.org/confluence/display/CRMDOC/Profiles+Admin
http://wiki.civicrm.org/confluence/display/CRMDOC/Linking+Profiles

You can choose to allow these users to view / edit one or more profiles via My Account or not - based on the Settings >> Used For value for each Profile

For more granular control - read about ACLs:
http://wiki.civicrm.org/confluence/display/CRMDOC/Access+Control

bazaarsoft · February 22, 2008, 11:41:04 am

A related bug: the same thing happens to "smart" groups - turns out they aren't so smart...

Thanks for confirming this bug. It's really a show-stopper for us unfortunately. Perhaps I'll get my feet wet and see if I can fix it...

CiviCRM Community Forums (archive)

News:

Author Topic: Real Private Groups (Read 1744 times)

bazaarsoft

Real Private Groups

Donald Lobo

Re: Real Private Groups

bazaarsoft

Re: Real Private Groups

Dave Greenberg

Re: Real Private Groups

bazaarsoft

Re: Real Private Groups