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!!!

  • 0 オフライン in reply to AngelaIp

    Why not use an additional "foreign" property instead of the unreliable keyed_name? However, there may be the performance issues of a bigger query in this case.

Reply Children
  • I just a few minutes ago played around with foreign properties. But I used the foreign as property that shall be used as new keyed_name. This didn´t work, cause it just links the id again. 

    But you are right! Of course I could use the foreign as alternative property for the orderBy task and completely avoid the keyed_name. I was so focused on the keyed_name glitch that I totally forgot the actual task I wanted to solve.

    I will try this approach, thanks!

    ....

    Edit: Now I am mentally ready for the upcoming holiday season. Cause even with correct keyed_name I would never have solved my sorting problem.

    Basically I automatically create a custom DCO from a Document. When creating a new DCO it look up all Parts that use the Document and adds them to a relationship tab in the DCO. Users then shall decide if they want to update the Documents in the Part or not.

    Notice what I do here? I want to order the Parts, not the Documents. The Document keyed_name is completely useless for this use case. I was so focused on less important details that I didn´t notice my embarrassing mistake.

    So Foreign property will properly work, but I need to use it for the source_id...