I have related a Product Type object to itself (hierarchy) and then related a Product object to the Product Type (many to one) and the Product Type's parent (may to one). This is to both categorise (parent type) and type a product (not common in e-commerce applications).
The problem comes in the interface when using the native filtering "You can narrow available choices for this lookup to be consistent with current selection in another (main) lookup, connected to Product Type through link lookup.":
The Parent - Parent Link Lookup behaves differently when Styled as a Selector vs a Picklist. As a Selector, the auto typing fails, however the correct set of (child) Product Types is displayed and can be selected and saved successfully. But the field is cleared the next time it is edited. If it is changed to a Picklist it shows the parent, not the children (i.e. the opposite result).
I suspect it is interpreting Parent - Parent correctly for the Selector, but incorrectly (opposite) for the type ahead and picklist, which may explain the behaviour.
Do I need to revert to c small script and not use the native Filtering in this situation?
Could you please provide a sample application xml?
Please find a test application XML attached.
Let me know how you get on.
Thank you for sharing application XML. I am able to reproduce all the issues you reported. Auto type fails, picklist style issue & value cleared in the edit page.
Logged a defect #37273
Thank you Srinivas. I look forward to the defect/s being fixed.
In the meantime, can you suggest a workaround using (filter) code. An example would assist greatly.
I have tried your use case by creating a separate object for child type. It is working fine. Attached the sample application xml.
Yes, this was the solution I had already implemented as a workaround. I was hoping to use the one (same) object for the parent./child relationship but understand the limitation.
Please advise when the defect #37273 might be fixed.
As of now we tentatively planned it for June release. I will let you know once it is fixed.
Any idea when this fix is planned to be released? I don't believe it made the most recent release.
Any idea when defect #37273 will be fixed?
We are looking into this.
This bug is triaged for 4.5 release (tentatively mid-March). We will keep you posted if there are any changes.
Thanks. I look forward to this (and other related issues I have logged regarding relationships and lookups) to be resolved.