enums for system entity attributes are named incorrectly!
mrmwink opened this issue · comments
Quite new to dataverse-gen but I have an odd issue where all the enums for the system entities are named incorrectly, e.g. account_acccount_accountcategorycode.ts, which should simply be acccount_accountcategorycode.ts, it's both the TS filename and also the enum declaration!
I've been able to modify the enum.ejs template to modify the generated enum file in this scenario, but then this doesn't help as the generated entity file is then broken due to the reference using the typescript filename! I guess I could change the entity.ejs too but I feel like I shouldn't need to do this and there is something I am fundamentally missing that means all the system enums are behaving in this way, but it doesn't happen for any custom entities and their enums!?
Hi @mrmwink - great to have you on board!
There are two types of choice columns, local definitions and global definitions:
The naming of local enums is (scope)_(choices-logical-name), the nameing of global enums is just (choices-logical-name)
The scope part for enums on local choice columns for entities will be the logical name of the entity, whilst for actions, it will be the name of the action. It's important to have this scope disambiguation to ensure that entity choices and action choices don't collide.
Since the accountcategorycode is a 'local' choice column, the scope is 'account' and the choice-logical-name is account_accountcategorycode - hence you see the double prefix - account_account_accountcategorycode
For global choices, there is no disambiguation prefix, and the logical name will just be the logical name of the choices - e.g. myprefix_mychoicesname
Since the default is to create global choices ('Sync with global choice' in the screenshot above) - you won't see the disambiguation for your custom choice columns.
Dataverse-gen could perform some optimisation where it looks for name collisions and only prefixes where needed - but I chose to go for consistency instead. If you re-name enums then it will make it difficult to re-generate the metadata and so I recommend against it - and it may seem strange having the scope disambiguation - until you find there is an action that has the same choice logical name but a different set of choices!
I hope this makes sense!
All that said - if we can guarantee that the choices-logical-name for actions and entities is always unique, then we perhaps do not need the scope prefix.
Ah, that makes perfect sense, as ever Scott your explanation is on point.
I can also go back to my team now and give them a heads up 👍
I guess you can never be 100% certain that is the case with the scope and naming, only takes a small error when generating one of them and you might get an issue!
Cheers, keep up the awesome work.
Great - glad this helped 😊
The collisions tend to happen with 'legacy' actions where the logical names were created literally over a decade ago. The more recent metadata is much more consistent. I'll close this for now - perhaps we can revisit it later.