New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extendable Option type #590
Comments
there are two different concepts that would make more sense and probably even a combination of them. it would make sense to replace options with enumeration, which those are essentially already anyway. the extension object range could be used to extend the enumeration with unique ids. then you could use the json resource files to provide the captions, even translated, for the enumerations |
That sounds like a very interesting new solution for Dynamics NAV. The enumerations provide at least one adequate solution for this purpose, in order to be able to depict such cases in a meaningful way. But an enumeration alone would not solve the problems, which also occur with the options fields. Just remember that there are a lot of CASE XYZ OF blocks in the current objects. Wouldn't it make more sense to create a separate inherited object for each document type? In this case, the existing logic could be adopted. Also, the overrides of logic already proposed in other issues would also make the best use here. For the current extension concept, I see it as problematic if the code contains a lot of CASE blocks, because you cannot publish events in thousands of places. |
We are aware of this problem - the combination of options and case statements. We are investigating different solutions. They all still require the extensibility to be designed into the base-app. |
What is the status on extending option fields? It's really a returning issue. |
We are investigating how create the best solution that is compatible with existing code and at the same time supports extensibility. We know this is an important area - and it is not forgotten. We don't have a timeline for this right now, but it is on the top of the list for extensibility features. |
IMO, you have two options
or, replace everything with tables of type option that are displayed a special way when defined as a table relation and cannot be edited on runtime. daya would have to be defined via packagedata or something at design time. |
Extensible enums shipped in BC Fall 18 release. |
Microsoft Dynamics NAV contains various standard tables, which are uniquely identifiable by option fields. For example, this is the table "Sales Header" and "Sales Line". In the old extension framework 1.0 it was still possible to extend option fields of tables, not nice, but you could.
Unfortunately, it is not yet possible. In my opinion, however, it is also very problematic because option is managed internally as an integer. And if several extensions extend the option fields, it can only lead to problems.
So I ask the question of whether there is a reasonable concept for dealing with this problem.
The text was updated successfully, but these errors were encountered: