1 of 1 people found this helpful
I had this issue also. My way around it was to recreate the actions in another environment, but set it back to original state. I then packaged that and applied it to the broken environment. Hopefully this helps.
This confirms what I was trying myself to do to get the things working.
But what did you export exactly ? Because I beleive If I just select the transactions generated by checking an unchecking that option it would contain additional transaction details that generate the current issue, and those I cannot selectively exclude from the package...
Ahh... now I remember the issue. This was working in 2016.1 which is where I created the package, then applied it to 2016.2 where it was broken.
This is actually an issue I came across before. What happens is that the change on Contract (Frs_CompositeContract_Contact) removes some settings on the OrgUnitLink on Employee and other objects used by it.
If you go to the Employee object, you can scroll down to the Contract composite end edit the locked field OrgUnitLink. You will notice it is "Not set" there as well. While on Employee, select the Orgunit relationship on this field (It is selectable from Employee, and won't affect other objects using this composite). Save, and your problem will be resolved.
If you look at a base install, you will notice this field is actually set on Employee and not Contract.
NOTE: You will need to do the same on External Contact as well.
After making the change, Tab out of the combo box. If the "save" doesn't show, add another field temporary which you can then delete afterwards.
I tried that, also clicking on other areas related to the object, nothing except external windows like saved searches and quickactions react to my input.
I went to higher breadcrumb level Build >Business Objects >Business Object Employee# (I was in >Fields), but then the change is cancelled if i go back to check it.
I'll try to trick it by doing the relationship addition in another environment and import a package and see what happens.
That one is a though one to crack
OK, unfortunately I have the same issue if I want to do the opposite (removing the selected relationships) on other tenants, so something is really amiss with that field. :-/
I'm busy making my own package manually and it contains the same thing.
I'll report here what the outcome will be
So it worked, I also leave the field OrgUnitLink visible under Employee and ExternalContact before someone else later gets the idea to try to make it visible again and then maybe break it again.
Ben, you package is correct concerning the Link insert in the first part of the xml, but It contains a lot of other stuff at the end for ExternalContact that seem not necessary in my case.
I also don't know about the importance of the sequence numbers for the transactions so I choose numbers following up on the last ones in my transaction overview in my target tenant.
I'll post my version after I validate it on a clean tenant.
The shared object also broke External Contact. My fix was for both Employee and External Contact (Just in case). I am happy it works for you.
1 of 1 people found this helpful
So this is the package I made for this issue:
It does following things:
- Uncheck HideFromUI on OrgUnitLink on object "Employee" and "ExternalContact"
- Force add relation settings under OrgUnitLink on object "Employee" and "ExternalContact" in case those are removed after unchecking HideFromUI manually + create related auxiliary fields
- Make the field OrgUnitLink marked as "System" (this is optionnal, but in my case the original setting that I needed to revert to)