delegateas/XrmDefinitelyTyped

Some String Attributes defined as Attribute<any>

daryllabar opened this issue · 4 comments

Describe the bug
For some custom attributes, the type (most are phone number formatted string types) is getting defined as Attribute<any>, rather than Attribute<string> and I can't determine why. Also for the Connection Entity, the record1 and record2 attributes are being defined as any attributes as well, rather than maybe LookupAttribute<string>

Expected behavior
The correct type would be set for these attributes

Environment

  • CRM/D365/CDS version: Version 1710 (9.2.21061.146) online
  • Tool version: 5.5.1

Not able to reproduce the custom attributes issue. Could you elaborate here? Does it happen for all custom phone no formatted fields, or do you have some that are correctly typed? Do you have other examples, and are they also "special" formats?

With regards to the connection roles, I guess they should be Lookups to multiple entities - (Similar to a Customer field, which is typed as Xrm.LookupAttribute<"account" | "contact">). I think the field is created slightly different from "normal" lookups (seeing as it can hold a reference to any entity), which XrmDT does not support at the moment. I will split that part to a separate issue to ease tracking.

Ah, I think I've figured it out. I believe it is due to non standard controls being used for those attributes:
image
Are you just looking at the form metadata controls and mapping them, rather than the attribute types as well? Hopefully you can fall back to the attribute type if it isn't a default control, but if not, provider some sort of config to manually define them?

Yes. I'm pretty sure it was the "easy" way to handle the type historically.
The attribute type should respect the attribute type independently of the control. I'm not entirely sure what to do about custom control types though. For now, it seems to me the quickest way forward would be to ignore them entirely, as the backing field's type is already known.

I'm looking into the issue.

Fixed in 5.6.0.