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