Fix index updating when culture gets unpublished

[cybersolutions-mreiter]

Prerequisites

• I have added steps to test this contribution in the description below

If there's an existing issue for this PR then this fixes #12964

Description

Currently if one culture of a node gets unpublished the whole ValueSet gets marked as filtered and will then later be removed from the index even if there are other cultures which are still published.
This PR changes this as it does not set the ValueSets as filtered but as valid and thus will update the index accordingly.

How to test

• Setup two languages (English and French)
• Create a homepage document type with vary by cultures selected
• Create a homepage node
• Set the hostnames and domains for each culture
• Publish the homepage in both cultures
• Go to Settings and query the external index using *:* you should note the homepage node in there and the fields in both cultures
• Go back to the homepage node an unpublish the French version of the homepage
• Return to the Settings page and query the external index using *:* and make sure that the node is still there but without the content of the unpublished culture

[github-actions]

Hi there @CyberReiter, 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 🤖 🙂

[emmagarland]

Hi @CyberReiter, thanks so much for your pull request to fix the issue where unpublishing a culture variant deletes the entire node from the External Index #12964.

I have merged into another branch to resolve conflicts 12980 with a plan to test with the provided replication steps, and then push to your PR and merge if successful.

I've run the branch but I'm getting the same results regardless of being in contrib or branch 12980:

1. Setup two languages (English and French)
2. Create a homepage document type with vary by cultures selected
3. Create a homepage node
4. Set the hostnames and domains for each culture
5. Publish the homepage in both cultures
6. Go to Settings and query the external index using : you should note the homepage node in there and the fields in both cultures
7. Go back to the homepage node an unpublish the French version of the homepage
8. Return to the Settings page and query the external index using : and make sure that the node is still there but without the content of the unpublished culture

I get the same Examine index values when unpublished in contrib as I do in 12980 ("PR Tests" is the node in question with both cultures). I did rebuild the index, too. I don't get the behaviour of the missing node field in contrib:

Unpublished in contrib:

Fields when unpublished in contrib:

Unpublished in branch 12980:

Fields when unpublished in branch 12980:

Is this something I am doing wrongly, or has the issue since been fixed?

Best regards

Emma

[cybersolutions-mreiter]

Hey @emmagarland
The issue seems indeed to be already fixed.
Should have been this PR #12669

Will close this PR as there is no more need for it.

[emmagarland]

Ah, thanks for confirming @CyberReiter! Glad it is resolved but thanks again for your time on it.

Emma