How to update keyed_name of relationship item reliable after new related item was added?

Hi community,

I have a custom Document item type that is connected to the regular Part like this:

Part  (Source ItemType)
- MyPartDoc  (Relationship ItemType)
--- MyDocument    (Related ItemType)

It´s important for me that keyed_name of "MyPartDoc" relationship item is set to the Document number of "MyDocument".

To achieve this, I use "Keyed Name Order =1" for the property "related_id" in ItemType "MyPartDoc"

Problem: In my case the keyed_name is not set reliable. When user add Documents to Parts, the keyed_name property isn´t set to the correct Document item_number. Most of the time the Document id is used.
But soometimes the keyed_name is set correct. But I so far haven´t figured out the reason.

When I take a look at Relationship ItemType "MyPartDoc", I get a list where both variants are used in a obscure mix:

So sometimes the keyed_name seems to be set correct. 

In my Innovator 12SP7 the former Action to rebuild the keyed_name is no longer available. And the keyed_names are not updated when I save the ItemType.

Does anyone have an idea how to set the keyed_name more reliable?

Thanks for any hint!

Best regards

Angela

Parents
  • Wow! Many thanks for taking the time to do such detailed tests!SmileyThumbsup

    Quote: "But after I EDIT exisiting relationship the keyed_name became correct."

    That´s an important hint that I haven´t noticed yet. This explains the mix of correct and wrong keyed_names in my list!!!!!
    I can confirm that when adding a relationship, the "id" is used as keyed_name. When I then edit the relationship the "item_number" is used keyed_name.

    This keyed_name behavior just seems to affected relationship ItemTypes, not the normal ItemTypes. That´s one of the typical evil details of Innovator that can drive an admin crazy. 

    I want to use the keyed_name so I can use it as orderBy property in bigger query. This way I don´t need to include the top Part in the query which makes later processing the result data much easier cause of the reduced amount of levels. My current customization would be perfect already, but I disliked the wrong sorting. Actually a trivial problem that now get´s complex to solve just because of this keyed_name glitch. 

    Yesterday I made some tests with using a custom "getKeyedName" Method in my "MyPartDoc" ItemType. I discovered that the context item (this) contains the source_id but NOT the related_id. The property is completely missing.

    Haven´t tested your solution yet, but it sounds promising. We either need to do a fake update or use some kind of onAfterAdd Method where we query for the relationships ourselves.

    I will let you know my results!

    Thanks again!!!

  • Ok, some results:

    One working variant right know is using a "onAfterAdd" Method that just contains the following code:

    return this.apply("edit");

    So basically it fakes an update.

    As I wanted to avoid the additional "edit", I tried to use an onInsertRow relationship event. With this variant I was able to set the keyed_name correctly as soon user add a new relationship. But my correct keyed_name was immediately overwritten when user save the item. Seems like some Innovator core Method always strikes in. So using onInsertRow doesn´t work.

    I noticed that I have many ItemTypes with this kind of messed up keyed_names (Part BOM...). It´s not always a problem, but I wouldn´t call it beautiful.

Reply
  • Ok, some results:

    One working variant right know is using a "onAfterAdd" Method that just contains the following code:

    return this.apply("edit");

    So basically it fakes an update.

    As I wanted to avoid the additional "edit", I tried to use an onInsertRow relationship event. With this variant I was able to set the keyed_name correctly as soon user add a new relationship. But my correct keyed_name was immediately overwritten when user save the item. Seems like some Innovator core Method always strikes in. So using onInsertRow doesn´t work.

    I noticed that I have many ItemTypes with this kind of messed up keyed_names (Part BOM...). It´s not always a problem, but I wouldn´t call it beautiful.

Children
No Data