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


  • I don't know where it is located and what the code looks like that updates the keyed_name according to the Keyed Name Order. At least I did not find anything similar among the SQL stored procedures. I think that this code has nowhere to take information but only from the AML request passed to it.

    It can receive AML like this from the browser for example

    <Item type='Part' action='update' id='AAA...AAA'>
        <Item action='add' type='MyPartDoc'>
           <related_id keyed_name="DOC-100001" type="MyDocument">
              <Item type="MyDocument" typeId="BBB...BBB" id="CCC...CCC">
                <config_id keyed_name="DOC-100001" type="MyDocument">CCC...CCC</config_id>

    or something like this generated by code

    <Item type='Part' action='update' id='AAA...AAA'>
        <Item action='add' type='MyPartDoc'>

    Both variants are valid and will work. Maybe in the first case this code can fill MyPartDoc keyed_name with the MyDocument keyed_name and in the second it can't.

  • No, I was wrong. I tested and in both cases the keyed_name is set to id.

  • Hmm.. But after I EDIT exisiting relationship

    <Item type='Part' action='update' id='AAA...AAA'>
        <Item action='edit' type='MyPartDoc'>

    the keyed_name became correct.

    I don't know how useful this information is, but for some reason that's how it works

  • 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.

  • 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.

  • 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...