Xpath Query on Multinode Treepicker no longer working for new Nodes. #14698

[huzzi]

The Xpath Query for the Multinode Treepicker does not work when used on a new node in the content tree. Once the node is saved the Xpath Query will work as expected.

Do not know what version of Umbraco this started to happen with however I can confirm that it was functioning properly with Umbraco 10.3.2 and doesn't work with 11.2.2 and above.

Specifics
Treepicker documentation and how to work with XPath can be found here:

Fixes #14698

Description

Steps to reproduce
You can reproduce by creating a simple Document Type / Content Structure in Umbraco.

Home (Document Type - alias 'home')
Page type 1 (Document Type - Page type 1 allowed below Home - alias 'pageType1')
Page type 2 (Document Type - Page Type 2 allowed below Home and below Page type 1 - alias 'pageType2')

Create a Multinode Treepicker with the following xpath query:

$current/ancestor-or-self::home/pageType1

This XPath picker should find Home and then first node using pageType1 document type. It should then list all nodes below.

Add this picker to page type 2

In the content Tree add:

Home
---Text page 1 (Page Type 1)
------Sub page 1
------Sub page 2
---Text page 2 (Page Type 2) DO NOT PUBLISH

The picker on page type 2 should only show Sub page 1 and Sub page 2 however it will show all nodes in the content tree.

If you save and publish the page and then try the picker again, it will work as expected and only show Sub page 1 and Sub page 2.

The location of the unpublished node is therefore no longer working as it did in previous versions of Umbraco.

[github-actions]

Hi there @huzzi, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[busrasengul]

Thank you @huzzi
Someone from the Core team will look into this PR soon!

[huzzi]

Thank you @huzzi Someone from the Core team will look into this PR soon!

This issue is also on V9 and V13. Please tag it appropriately. Thank you.

[huzzi]

Can someone please review this pr?

[nul800sebastiaan]

Thanks you for your patience @huzzi - we'll need a little more time, but we'll get back to you!

[RuddyOne]

Any movement on this?

We have just noticed the issue in Umbraco 13 and need to resolve it.

[lauraneto]

Hi @huzzi,

Again, thank you for your (first 🎉) pull request and sorry for the delay. 🙏

While your change works for the specific case you mentioned, I'm worried it won't work when you have different queries that are not ancestor-or-self::, as that makes it so the level doesn't matter.
Although, I just noticed in the query help that it says $current: Current page or closest found ancestor, so maybe that was already the case before? I might double check this with HQ and come back to you! 🙂

Either way, I left a comment regarding the if change. Let me know what you think!

[lauraneto]

Ok, I did some additional investigation on this.

In version 10.3.2 there was no logic to check for the parentId because the nodeContextId received by the function was in fact the parent id and not 0 as it is now (only when creating the node, of course).
Then I came across #14127 which feels like it was also a fix due to the change above, but did in fact mention they did not handle $current as it was not part of the issue reported and it was also not clear how it should behave.

As far as I can see, the previous behavior, where $current had an effect was indeed using the parentId as $current so this change would make it work as it did before.
I will still do a double check with HQ just in case they have more thoughts on this 😊

[lauraneto]

Hi again @huzzi ,
I double checked with HQ and if it was working like that before, then it is ok to keep having the same behavior (using the parent as current on new nodes) 🙂
So, when you have the time, could you check my comment?
Thanks 🙌

[lauraneto]

Hi @huzzi,

As I haven't heard from you since I left feedback, I have now adjusted and merged the changes.
Thank you so much for your help fixing this one! 🙌

Do you have an Our Umbraco account? If so, please drop here your username so we can give you a contributor badge. 🚀

[huzzi]

Hi @huzzi,

As I haven't heard from you since I left feedback, I have now adjusted and merged the changes. Thank you so much for your help fixing this one! 🙌

Do you have an Our Umbraco account? If so, please drop here your username so we can give you a contributor badge. 🚀

@lauraneto I'm so sorry I didn't see these messages till now and thank you making the changes and merging it.