I was wondering if it’s expected behavior to be able to delete options from an option set, especially in instances where the option is used in an option group and where the option is used to collected a coded value for individual level data. If an option is accidentally deleted it could have an impact on data integrity, especially if the code used is not clear. As background, we are doing some testing of version 40 and observed this but have noted this as an existing behavior for many versions.
@Kris_Reinhardt In general I’ve always thought of an option to be logically removable, as data itself doesn’t need to have the option available to retain the value that was saved to it (and should be place where you could retrieve any codes that were saved for options as you were describing). But I hear you on option groups; removing/adding options in the past has also created issues in our server for event reports and pivot tables if the sortOrder was not reorganized, or if the version was upgraded when there was spaces in between the sortOrder (i.e. if it went from 12 to 14, an upgrade would create a N/A in sortOrder 13 that would break down functionality of analytics and capture).
That didn’t really feel like an answer----I’m both happy that I can delete options without crazy amounts of dependency issues, but also am always nervous to delete options without fully thinking about the ripple effect that might occur from it.
yes program rule actions can hide options with whatever condition you choose. We have done things like “true” if we want the option to always be hidden—but keep in mind this might remove data if you go back into an event where it was selected.