visibility control for tags

[tonyg]

When creating a profile, you can include a group's field and only the groups the are marked with the visibility for public user pages are visible in profiles. this is great and i would love to see this visibility control implemented for tags.

Example: an organization has a group called volunteers and has tags that distinguish them (i.e. stuff envelopes, phone calls, etc.) based on interests, skills, etc.. When using a profile, it would great if people could sign up or check off their interests by checking tags.  Unfortunately, as it is now, if you wanted to include a tags field in a profile, every tag appears which is not good since most are for internal/admin use only.

what do people think of this?

thanks
tony

[Dave Greenberg]

Tony - Is there some reason you wouldn't use a custom field for these specific cases?

[tonyg]

Sure, you can use custom fields and i have recommended them many times for clients. But why should you when you have built in to core CiviCRM the ability to tag contacts on specific attributes like volunteer interests (and much more)?  In many cases you can and would use custom fields (for say food preference for participants at an event) but tags are great way to manage this type of information.  Combined with profiles and visibility control, they would be even more powerful and useful.

[ctarascio]

   We host multiple instances (and growing) of CiviCRM for our US/International offices. In some cases, the Regional Director wants there to be one CiviCRM database that is shared among program staff in offices that are part of that particular region. Each office has its own set of programs (Middle East, Iraq, Prison Reform etc...) and accordingly, tags. As you can imagine, the list of tags can become enormous. In addition, program people have to deal with seeing many tags that have nothing to do with their area of focus. It would be great if we were able to limit, perhaps by role, what tags a user sees. Or are we using tags when using groups or something else might be better?

Thanks,
Cynthia

[Dave Greenberg]

I think dealing with large number of tags OR groups creates user interface challenges - and hopefully we can improve how these are managed over time. One step in that direction is the option to create hierarchies of groups which is part of 2.1. - and the "checkable tree" control for browsing and selecting groups which is part of that project.

The widget still needs a few tweaks - but it would be great if both of you could try it out on the sandbox and give us some feedback. We could potentially add a hierarchy / nesting feature for tags in a future release and use a widget like this to make it easier for folks to find what they need etc.

To try out the "tree" widget:
 - go to: http://sandbox.civicrm.org and login
 - navigate to Find Contacts and click the "Select Groups" link in the search form

[ctarascio]

Thanks Dave. Will do ASAP and report back.

Cynthia

[geilhufe]

It works as expected... since the group summer volunteers is the same as the group all volunteers, it checks everything. I added a test group into the sandbox so you could see the behavior you are probably expecting.

[Sarah]

Yes,that is what I was expecting with the test group.  although I added myself to the volunteers group but not the summer program group and it still selected both.  I just searched again and it seems to allow me to search for just summer programs or just volunteers this time.

You're saying it searched for all volunteers because summer programs was the only subgroup?

[xavier]

FYI,

http://wiki.civicrm.org/confluence/display/CRM/Hierarchical+Tags

The db is ready to support these features on the 2.1, the code will probably come for 2.2 and as patch.

X+

[Dave Greenberg]

Yes,that is what I was expecting with the test group.  although I added myself to the volunteers group but not the summer program group and it still selected both.  I just searched again and it seems to allow me to search for just summer programs or just volunteers this time.

You're saying it searched for all volunteers because summer programs was the only subgroup?

We're still "thinking" about some pieces of how this should work. My current thinking is that the search should be "precise" in returning the groups that are checked, regardless of the hierarchy. AND that the interface should make it easy to find everyone in a parent group and it's children by automatically checking all children when the parent is checked.

Examples:
I have Parent Group A with 10 child groups (Groups A1 - A10).
1. I want to find everyone in Parent Group A and all 10 child groups. I check Parent Group A - all child groups are automatically checked.
2. I want to find everyone in Parent Group A and in child groups A1, A2, A5, A7. I check parent Group A and then uncheck A3, A4, A8-A10.
3. I want to find everyone in child group A3. I just check that group.

Does this make sense to folks? (I'm not saying the search works this way now BTW - I think the queries need some tweaking).

[Donald Lobo]

Here is what happens in trunk/2.1 currently. Note that we've started caching the contacts belonging to smart groups to optimize the queries since it was getting a bit too complex / inefficient

A nested group is treated exactly like a smart group. i.e. choosing a parent group implies choosing ALL the children group underneath it. Thus for dave's case below:

1. I want to find everyone in Parent Group A and all 10 child groups. I check Parent Group A - all child groups are automatically checked.
2. I want to find everyone in Parent Group A and in child groups A1, A2, A5, A7 - CANNOT BE DONE in current model
3. I want to find everyone in child group A3. I just check that group.

I think i like the elegant simplicity (since it also makes the code simple) of choosing a group means choosing everyone under that group. I've been trying to figure out how to get around it efficiently (and have not yet figured it out). I suspect we'll leave this as an exercise for 2.2

lobo


lobo

 

[tonyg]

Just to bring it back to the original post, is visibility control for tags not doable for a future release? Am I the only one who thinks this is a good feature?

I did test hierarchical groups on the sandbox and it seems to work fine. I agree with the current thinking that a search should return just those groups that are checked, regardless of whether it's a parent or child. I am a little concerned about how to best explain to clients when to use groups, sub-groups, and/or tags. Our clients already struggle when to use tags vs. groups.  I think, I just need to think through it some more though.

[Donald Lobo]

tony:

yes it is doable, but not yet planned/scheduled. We probably need to consider a generalized tagging scheme for at least contacts, mailings, groups (maybe events too) to allow folks to organize  a large number of them (and we've seen some installs with 100+ groups and events)

At that point in time, we will consider visibility control and hierarchy. If important to you now, please consider filing a patch against the current implementation. This typically has the unintentional side effect of us taking a good look at the code, incorporating it and making more changes / extensions to it

lobo