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.
- 678 replies
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.)
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.)
+5I 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.
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.
+12- Captain
- 61 replies
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
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... 🤔
+5htimmermans wrote:
Users and customers sometimes get different opinions or ideas I've noticed the last few decades... 🤔
😁
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.
When you empty out you can also create a popup message explaining that this value is no longer active to help the user.
+12- Captain
- 61 replies
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....
+12I'm fully with
- 678 replies
Adding a checkbox in the Software Factory metamodel is indeed quite simple, but this functionality must then of course also be developed for the Windows, Web and Universal GUI and the Indicium service tier.
There are a lot of great ideas on the community, but unfortunately we don’t have the capacity to take them all up. The number of votes, combined with the required effort and the added value of an idea, really helps us to select the best.
+9The following idea has been merged into this idea:
All the votes have been transferred into this idea.
All the votes have been transferred into this idea.
+12As the Domain (elements) Variant Idea is merged with this one, I guess it's better to add a similar suggestion here:
Instead of the Variant Idea, it would be great to be able to use the Layout procedure on domain Elements. We often have situations (especially on status fields) were a user is only allowed to use certain element values or to move it from one element to one other element. The availability of a given element would be based on User permissions or current status (for example: if current status is A, you can only change it to B, and if current status is B you can only change to A or C, but not D). Now if it were possible to show/hide certain Elements in the Layout procedure we wouldn’t have to work with workarounds like creating two similar Domains and using Layout logic to determine which one to show. Maintaining two (or more) similar Domains with Elements is both risky and ugly.
It would be good enough if somehow the Layout procedure recognizes Domain with Element type of fields and we can write logic on each individual Element within that Domain.
Anyone else seeing the value of this addition?
- 678 replies
Hi Arie,
If it is necessary to filter the values in a combo based on context, we often turn to lookups instead of domain elements. You have to add business logic anyway, and filtered lookups using for example expression filter fields provide the most flexibility. You can also add prefilters to limit the options based on the user’s authorization profile.
If you still think your idea should be implemented, feel free to create a separate idea for it as it is not trivial to implement.
- 678 replies
The upcoming 2021.2 release will include the option to deactivate domain elements for a project version. Deviation per variant is scheduled for the 2021.3 release.
Updated idea status Working on it! → Next release
+9Updated idea status Next release → Completed
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.