Pages

Wednesday, April 14, 2010

Owner fields and the Javascript Grid Editor

Since the release of my Javascript Grid Editor project, I've been blessed and blessed again by helpful and constructive contributors and developers helping me locate bugs and implementation-specific considerations.  One of the most annoying to date, has been the incompatibility of the script with Owner-type fields.

To be honest, I don't use Owner fields in my implementations of the script personally, so I was rather taken back to discover that the metadata for Owner-fields does not include a "Targets" node with information pointing to the "systemuser" entity, as every other Lookup in CRM does.  This troubles me because I'm fully aware that CRM 5 will introduce team-based ownership, and I anticipate they will use the "Targets" descriptor in the metadata to delineate ownership by either "systemuser" or "team" entities.

I've included a fix for this in the most recent update of my code, and published version 1.0.4 to the repository.  The fix operates during the retrieval of the metadata, and checks each attribute to determine two conditions: 1.) that it's an "Owner" attribute, and 2.) that no Targets were located.  If these conditions are met, the RetrieveEntity() function simply creates a single-target reference to the "systemuser" entity--which should fix the problem in all areas of the script.

I hope this bug hasn't precluded the implementation or deployment of the JGE to any CRM deployment that needs it, but if it has, please grab the latest version of the script and try it out!

2 comments:

  1. As I mentioned in our email conversation, thanks a bunch for making this fix. It has really helped for inserts into custom entities that our user-owned

    ReplyDelete
  2. I never personally experienced this bug, and found no troubles working with the Owner field in my deployment. Maybe it was the entities I used it on, but I always got a "systemuser" Target in my metadata.

    One individual I worked with told me that he was using a System Administrator account, and naturally had all the Metadata Entity, Attribute, and Relationship privileges assigned by a CRM role (which is absolutely necessary to the operation of the script).

    Even in this case, he experienced the bug, and after probing the metadata tables found examples of entites with and without the "Target" information. After he updated the SQL tables, the script worked.

    I'm altogether conflicted about telling people that their deployments are bugged and they need to update SQL to fix their problems, but I honestly think that Microsoft has broken their own Metadata mold in places that preclude relying on the "Target" information, for no conceivable reason--personally, I think it's their bug, not mine.

    However, I'm bothered to discover that others are reporting trouble with the "Integer" field in the same manner. Apparently, sometimes this field is missing its "Format" Metadata information. Why? It should be "None" for pure Integer fields, and in my deployment it is. Maybe the trouble rests around custom entities, since those are the ones being reported in conjunction with these flaws. In any case, I'm personally finding it inconvenient as a developer, and I hope the community will continue to report discrepancies like these so that I can fix them. Stay tuned for an "Integer" field fix.

    ReplyDelete

Unrelated comments to posts may be summarily disposed at the author's discretion.