Allow a default value for Tags

[David Hepper]

It seems odd that when defining a Tag there is no option to specify a default value for it. All Tag values default to False. For example, when creating a new Civi Member manually all the Tags on the form are unticked by default. We want some of the opt-ins for mailings to default to ticked, meaning 'Receive the mailing'. If these could be ticked by default it would save a mouse click per Tag per new member for all but exceptional cases and reduce the risk of accidentally leaving them unticked.

Workarounds:
- Define a Custom Field instead of a Tag since a Custom Field can have a default. But at cost of losing the ease and speed of working with Tags.
- Reverse the Tag's meaning, e.g. from 'Opt-in' to 'Opt-out', so that False is the normal value.
- Is there a concept of a 'Begin-Form' function, where code can set fields when the form is loaded?

I'm not keen on any of these. Default values are pretty basic for database systems.
David

[JonGold]

Hi David,

There are a variety of ways to add code to automatically set the value of tags - but I would caution against this path, because you'll have to add all sorts of logic on when to use the default vs. the saved value on a renewing member.  Either add jQuery via an extension (http://www.jackrabbithanna.com/articles/easy-jquery-modificaiton-civicrm-forms) or with an .extra.js file.

However, since I've always handled this with custom fields, I'm curious what the "loss of ease and speed" is you're referring to?  I don't use tags a lot, so I won't claim to be an expert - but it seems that it's the same number of clicks to edit a custom field as a tag, and I can't see any other special advantages of tags over a custom field.  Custom fields also allow me to organize my data more logically, which is why I've always opted for them.

[Donald Lobo]

a couple of issue worth thinking about:

a. In general having default values and allow the admin flexibility with regard to this is always a good thing. Allowing stuff to be done via jQ / code is always beneficial but we should always move towards giving the end user the flexibility (and this could be via an extension also)

b. There is lots of data in civicrm that is "optional". i.e. not all contacts have them. This is true of both tags and custom data (in addition to lots of other objects). What does default mean in this case? It has the value when someone visits the relevant page? or when a contact is created, it has the value. Something to think about

c. I think most/all of this should be doabble via an extension to prove the concept. Wanna take a crack at it david?

lobo

[David Hepper]

Thanks lobo. It looks core-like to me: general-purpose, low-risk, no side-effects, no changes to existing implementations. Is this something I could contribute at the Edale Sprint? - with suitable oversight, of course.

[Donald Lobo]

we've not yet decided the focus of the edale sprint. It depends on where we are with 4.5 and other stuff

lobo