New

Add import functionality for dropdown values

I think it would be highly appreciated if there was an import functionality for updating and adding values to a dropdown field. Sometimes there's many values that should be added or updated and this takes a lot of time to do as it is now. It would be great to have the opportunity to upload a file with two columns (item name and display label). 

Emelie Garton
Parents

  • I can see the utility in that when deploying the same dropdown to multiple instances making sure there are no typos and that data and labels are spelled exactly the same.
    If you work for a partner who does a lot of custom work for clients that could become quite a chore to do in Studio, but I assume that partners, like me, would just copy and deploy those in code.

    In my case it's easier because I'm OnSite and I can just edit/copy the language file and I don't need to package it with manifest etc... it's still somewhat of a delicate process but no more than other code changes.

    Perhaps, it would be easier if there was an option in Studio to copy/paste into a grid, Excel style, and submit the list all at once.
    Or perhaps edit the value/label array in code format (similar to PDF Manager where you can edit in Wysiwyg or HTML) rather than typing them in one by one. That way one could copy/paste from one instance to the other.

    I agree with that in some cases custom modules acting as dictionaries is the better alternative, especially when dropdown items are often inactivated/changed. But that requires more coding and knowledge of how to build a custom field that would present options based on queries, and somewhat defeats the purpose of the simplicity of managing drop downs via Studio.

    As a side note, we have a workaround for inactive dropdown items where we mark the labels of a dropdown with the tag [legacy] and filter them out during the edit process, this ensures that any inactive dropdown values are still displayed in record view and list view etc.. (if you remove them from the list they remain in the database but do not display in the application which can confuse things) but those values cannot be selected when editing and saving changes to that field (unless you are an administrator), if the user tries to edit the field and save it with a [legacy] value they are notified with an alert and cannot save. They can however change other fields and leave the legacy value as it is, if that is what they need to do. When creating a new record we don't even include [legacy] values in the dropdown list, we just remove them before the create view is generated.

    Being on-site we also have complete control over our databases, so very occasionally we have had to actually replace values in the back end to remove an entry completely from the dropdown list - but that's even more extreme and potentially dangerous, I don't recommend back end updates.

    FrancescaS

Comment

  • I can see the utility in that when deploying the same dropdown to multiple instances making sure there are no typos and that data and labels are spelled exactly the same.
    If you work for a partner who does a lot of custom work for clients that could become quite a chore to do in Studio, but I assume that partners, like me, would just copy and deploy those in code.

    In my case it's easier because I'm OnSite and I can just edit/copy the language file and I don't need to package it with manifest etc... it's still somewhat of a delicate process but no more than other code changes.

    Perhaps, it would be easier if there was an option in Studio to copy/paste into a grid, Excel style, and submit the list all at once.
    Or perhaps edit the value/label array in code format (similar to PDF Manager where you can edit in Wysiwyg or HTML) rather than typing them in one by one. That way one could copy/paste from one instance to the other.

    I agree with that in some cases custom modules acting as dictionaries is the better alternative, especially when dropdown items are often inactivated/changed. But that requires more coding and knowledge of how to build a custom field that would present options based on queries, and somewhat defeats the purpose of the simplicity of managing drop downs via Studio.

    As a side note, we have a workaround for inactive dropdown items where we mark the labels of a dropdown with the tag [legacy] and filter them out during the edit process, this ensures that any inactive dropdown values are still displayed in record view and list view etc.. (if you remove them from the list they remain in the database but do not display in the application which can confuse things) but those values cannot be selected when editing and saving changes to that field (unless you are an administrator), if the user tries to edit the field and save it with a [legacy] value they are notified with an alert and cannot save. They can however change other fields and leave the legacy value as it is, if that is what they need to do. When creating a new record we don't even include [legacy] values in the dropdown list, we just remove them before the create view is generated.

    Being on-site we also have complete control over our databases, so very occasionally we have had to actually replace values in the back end to remove an entry completely from the dropdown list - but that's even more extreme and potentially dangerous, I don't recommend back end updates.

    FrancescaS

Children
No Data