Upvote for Ryan @ Pinella's solution. I agree, all configurable lists of data entry types should have a hidden backend ID# that keeps them all unique, so you can edit the Description of any field's data points without losing associations for prior items that reference that selection. This is common sense programming.

As a minor workaround, if you're just looking for historical data on a customer with Referred By value that may have been deleted because you no longer use that source, you can do a Customer Export from Admin>Reports that will still retain old text. You could use this method to update Referred By in Excel in bulk, then just make sure all current entries match options in RepairShopr settings and import the changes.

I also want to throw out that having the default 5 required options is silly. Why require anything at all? The way you have them conflicts with the way I've been tracking customer sources for 20 years. I can't create "Referral" because that logically conflicts with "Customer" and "Friend" that are required. But what if it was a business they were referred by? Just silly. Let us make our own lists.

After almost 3 years and no update STILL!!!!!

Horrible!

Copy of my original post from duplicate post on 6/23/2014 - [Change list "types" to auto-fill drop downs] :

I was originally making this suggestion to request the "referred by" field type be converted; but then realized there's several different lists and modules in RS that are using inferior, non-editable, databases. Specifically, the "referred by" field is hugely important information, as you all know. My list of ways-customers-are-acquired is ever-growing. As of now, I've tried to combine certain referred terms together to make it easier to figure out what we're looking for. However, this is proving more difficult.

I have the perfect solution for how to add/edit/delete these types of terms, and the best part is you're ALREADY using it! It's the same as your inventory items fields! They are amazing, and here's what is to be gained by converting ALL lists in RS to the same type as inventory items:

- Items are searchable by ANY word in the description (ie. I could just type FAMILY and it would pull up the term called CUSTOMER REFERRAL, FRIEND, FAMILY, PREVIOUS CUSTOMER)
- Items are editable and would update existing uses of existing terms (which is a big deal because right now you can only delete a term, which deletes all uses of that in the system, including existing)
- Items are organized (I have no idea why the current system doesn't let you organize by name or specific order - very annoying)

This is a simple conversion request, NOT a new feature. It's so obvious that the way inventory items is great, which is why it's used in the module with the most values in it. Why not start using this "item list" method for EVERYTHING - Ticket problem types, ticket status list, list of product categories, logistics, preferences, etc.

Please let me know if this makes sense. It's a really good idea to make the system more "editable", rather than just deleting and adding stuff all the time.

Darn, our votes for the exact same thing are scattered between 2 separate forum posts. I had made this one literally 2 weeks before this one was made:

http://feedback.repairshopr.com/forums/165658-general/suggestions/6088913-change-list-types-to-auto-fill-drop-downs

@RS - Can you merge these votes together or something. Any updates on this (or mine, which talks about even more modules where list types could use adjusting)?

This is a biggie. We should not be able to actually delete an item from a list, just mark it as inactive. Would still show in old jobs where it had been selected but not in new ones. Little "if active=true" would solve this problem. Also being able to organise lists its required (referral source, job type etc)

So, no updates on this . . .

I would also add the Custom fields to this list, I think the name of the field should be getting updated not the entire field.

It looks like the data is actually preserved in the background, I did an experiment with this. I populated data into a custom field, then changed the name, it was all gone. But when I changed the name back the data came back so I suspected that the entire field was getting updated as if it was making a new record not just updating the name of the record.

Any updates on this?