CiviCRM Community Forums (archive)

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

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.

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

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.

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+

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

 

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