TeamDesk Knowledge Base & Support

basenine 11/26/2017 2:45:58 PM

The best solution I’ve found for these types of columns is to turn them into their own table

All the data from the column remains. Ie choices of:
ABCD
EFGH
IJKL
MNOP
will create a new record for each choice in the new table. The best bit is that all existing data remains in tact.

Maybe create a dev branch first to test it out

Philipp Matuschka (MMB) 11/29/2017 4:42:05 AM

Agree with that and it is how I have done it. Give all users View access but only some users New, Edit and Delete access to the table

cooper collier  12/4/2017 1:37:39 PM

This is what we do also.. It is a great way to do it.
But it does have shortcomings. Nothing is perfect. You end up making what I call LIST tables, that clutter up the dev environment. You also need to specially train users to not change or delete existing LIST entries. If a choice is changed, all previous records using that choice change.. (sometimes that's a good thing... ). If they delete a choice, all previous usages will default to the ID number of the deleted choice.

Plus consider when your choices are small and limited. Maybe for family relation. (Parent, Grandparent, Sister, niece)... You really don't need or want a separate table... but you only want maybe the owner to add the new relation type. If you let his kids do it, you would end up with, (Pinky buddy, BFF, etc)

So while the suggested solutions are excellent.
I think the functionality would still be very useful to have.