Open

Possibility to make domain elements "Inactive"

  • 21 May 2019
  • 6 replies
  • 120 views

Userlevel 5
Badge +8
We've got a table with years of historic data. Numerous fields are dropdowns with a fixed set of of domain elements. A customer now has the desire to come up with a complete different set of possible values and keep the historic data working (with the old values).

There is no way to get this done with how domains and elements work currently. A great addition (i.m.h.o) would be the addition of a new field in a domain element "active" or "available_to_gui" or something like that.

This would then reslult in the GUI not showing elements that are not active when the drop is pulled (or grayed out if that's a better way), but in that matter the translation would still work for historic data.

When adding new records to the table, the inactive elements should not show up.

6 replies

Userlevel 6
Badge +6
One way you can achieve this is by using a look-up table instead of domain elements. By adding a default non-locked look-up prefilter to filter out the old values and disabling the look-up popup, the user interfaces will still be able to translate old values while preventing the user to select them.


Please note that through the Indicium API, it will still be possible to insert and update rows using the old values. You might want to add some business logic to prevent that. (Which, by the way, would be more difficult when using deactivated domain elements.)
Userlevel 4
Badge +2
I think you also need to consider what legacy you want to create. By adhering to this requirement, you will create legacy and have to maintain both new and old elements for years to come.

The more robust solution is to migrate all the old elements (the ones no longer valid) to the new values. I'm almost certain you could make a mapping in order to come up with the right plan for migration. Short term, this is a bit more work, but if you disregard this, and situations alike, it will come back to haunt you.
Userlevel 5
Badge +8
@Jasper , @Robert Jan de Nie

I know, this could be resolved by changing the domain of the field to a same type (e.g. integer), create a table, but also a translation table and accompanying view that shows things in the users language, possibly a instead_of_trigger on the view is needed when users should also be able to change data. A lot of things to be build when a domain with elements.

For instance, who would build a table/translation/view/trigger when initially a status of an order can only be
  • status 1
  • status 2
  • status 3
according to the user requirements.. And months or years later "status 2" may no longer be used, but historic data still needs to be displayed as "status 2", Normally I wouldn't think twice about whether to create a lookup table for such a field, or create it as a domain with elements when building the applications initial version... Who would?

Thinking like this one could completely get rid of domains with elements (and additional translations). Because I can't see what the business wants in a couple of years.... Users and customers sometimes get different opinions or ideas I've noticed the last few decades... 🤔
Userlevel 4
Badge +2
Users and customers sometimes get different opinions or ideas I've noticed the last few decades... 🤔

😁
Userlevel 4
As a work around you could write a default procedure which empties out the field (domain with elements) when the user select a value which is not longer active (You can even use a table to determine which element is no longer active.).

When you empty out you can also create a popup message explaining that this value is no longer active to help the user.
Userlevel 5
Badge +8
@Robbert van Tongeren

If a domain-element pre-filter kind of solution is not an option to build into the SF, than that is probably a workaround.... A bit difficult to explain to (new) users of the application however that "They may not choose certain values in a dropdown".

Either that, or going for a table/translation/view/trigger solution. But I bet I won't be the only one walking in the domain-element trap for years to come....

Reply