Our client's custom field needs have expanded to the point where every one of the 10 slots for Orders and Contributions have been filled. To satisfy new data requirements, we've had to start double-purposing fields and embedding JSON inside the field value. Has anyone had success expanding custom fields in other ways? The only other idea I have so far is to alter the custom field columns in the database table to allow more than 255 characters, so that JSON data size won't need to be restricted as much. However, this may have unintended side effects elsewhere in the system and may not survive a major upgrade.
Ideally custom fields would be stored in a separate table called T_CUSTOM_FIELD that would relate to Orders, Contributions or any other type of object via a generic "entity_no" column. There would also be a "keyword_no" column to associate it with the keyword definition of the field and the "value" column would be a TEXT type to allow for very long values if needed. For backwards-compatibility, you could still assign up to 10 fields that would be stored in both the new table and in the current format with the custom_[x] columns, so the legacy columns would always be a mirror of the data in the new table.
Does anyone know if a better custom field system like this is on the Tessitura roadmap?
You could always submit an IDEA to Tessitura as an enhancement, but I definitely have not heard rumblings of an expansion of custom fields from anyone, nor heard many people talk of that notion either, so I would not be particularly expecting of additional updates there. It never hurts to try, but I just would not get my hopes up.
For our custom needs, much like Alan Draper, we use custom tables. Is there a reason a custom table will not work for your needs here? Seems like a custom table based on the order/contribution reference number would get the job done, and certainly your custom table(s) would be as flexible as you need it(them) in terms of number of columns and their types and dimensions.
John A. Moskal II