Add custom fields to notes

[xavier]

Hi,

being able to add a file to a note would be great. In general, any custom field

With 4.1 and custom fields on case, the note is more or less the last entity in civi that can't have custom fields.

Would be be complicated to add? If you had to put a number of hours on the task?

X+

[Donald Lobo]

i'd say 10-20 hours

I think there are a few other objects that also need custom fields. we've been moving towards a place where addin this is very simple (and are quite close to getting there)

lobo

[josue]

if we are messing with notes, could we add importing and searching of the subject field? it could be very useful but we do not recommend using it because it can't be accessed.

[xavier]

Hi,

Not sure adding custom fields would be "messing"

It doesn't search on the subject? Never realised it. Good point, kind of useful

[JohnFF]

*bump*

Xavi, did you ever reach a resolution with this?

[xavier]

kinda: I used activities at the end

[Jeremy Proffitt]

I agree that adding custom fields to notes would be a valuable improvement, but appropriate documentation needs to get written to help inform users on which type of entity is best to use for one of the given notes use cases:

• Tracking atomic admin comments about a contact - perfect use for notes with custom fields
• Adding generic content information to a contact record (like a bio, etc.) -- This should really be a custom field of type "note"
• Adding free-form text about an interaction -- All interactions really need to be activities so they can be properly tracked. If when something happens is important... always an activity.

If we don't add the documentation... there will be a lot of needless hacking from implementors, with unwanted results.

[xavier]

Because there is more than one way of doing it and what you recommend as the best way might not be someone else preferred solution. We tried to find a consensus on tags vs groups vs custom fields vs contact types for contact segmentation, and failed.

They are some wrong ways, but I don't think we can offer a universally chosen best one to recommend.

[Jeremy Proffitt]

If that is the approach then we should be very cautious about how custom fields are added to the notes, and indeed with other things as well. It should not be possible for every component to do everything if we just slap enough custom fields on it. They need to be segmented and specific for a reason so that they actually have value.

If they don't have unique value as is, then they need to be revised or removed altogether.

[xavier]

I would agree with you and I'm not convinced at all we should keep note for instance. as in, with an activity type and adding a privacy flag on the activities, it would serve the same need, one less bit of code to maintain.

However, the proposal of having to migrate the notes as activities+time spent on training+removing the code+bugs introduced+having one less checkbox "does it allow to store notes"... plus at least a handful ready to take the pitchforks to defend their notes...

and about zero people interested to pay to remove a feature they don't need or make a compelling case of "it doesn't do X anymore" as a marketing point...

you do the math, but does seem a tough choice, with a lot of short terms reasons not to do it.

Do you have examples of free software where they did manage to remove stuff? how did it happen?

X+

[Jeremy Proffitt]

I have seen projects like Joomla remove stuff entirely, although I can't say they did it with an exceptional amount of finesse. No one will be happy all the time, but given enough notice and guidance, changes can be made without disastrous impact. I'd say you're correct that no one pays to remove a feature, but no one would ask for that either. Instead the gradual pruning of dead or unhelpful code makes it possible to maintain the best code.

In the case of notes, I'd actually leave the interface almost the same, but change the underlying functionality. No matter where a note is, it should create an activity. The type and options might be determined by context, but it is still fundamentally an activity, and could be viewed as such. (Just an example that I happen to think would be a good idea).

I feel like a lack of documentation and guidance is what causes most users to find their own way, and then complain when that unsupported way doesn't work right. Another example where a good combination of code improvement and documentation would be in the Profile->email to X option. This should never have worked that way. By definition, every interaction in the CRM should be tracked, and this allows a loophole. Creating a simple contact form in CiviCRM is fairly complicated, because of the need to decide how the free form response is stored. Most developers know that you could create a hook and have that produce an activity assigned to X persons, thus generating an email notification to those individuals. That should be a core option of Profile.

The core litmus test of any function added to the CRM should be can we answer or does it contribute to answering "what?, when?, why?, by whom?, and to whom?". If not, then it just shouldn't be there.

I think your initial question in the thread actually pointed to a genuine issue, but looked at the wrong solution. It's not the notes that should change, it's that adding a file field (which already is a custom field option), should have a datestamp, description, and the option to use an external file link instead of a local uploaded file.