USync Set Deleted Nodes not Included in Set

[fbpenalosa]

Describe the bug We're using USync sets to clearly define which content nodes gets imported. An example set would be like this:

Content Handler Include: Home/Theme1Page, /Design/Theme1, GlobalTheme1 Media Handler Include: /Common,/Theme1

This creates the following content nodes:

->Home --->Theme1Page

-->Design --->Theme1

-->GlobalTheme1

And then the Media handler installs the ones configured on the Media include This is all working as expected but we recently found an issue wherein after it imports, it finds content files that are marked for deletion and deleted it. An example config is this settings.config that has this:

The node path of this is <Path>/Global/Settings</Path>

Which is clearly not included on the config includes so I'm not sure why the import deleted this node. Is the importer running a cleanup of all deleted nodes after the import even if they are not specified in the include handlers? Is there a setting where we can turn this off or make it granular?

To Reproduce Steps to reproduce the behavior: 1.) Deploy some .config files that are flagged for deletion 2.) Run the USync set import 3.) You would notice that the nodes mapped to the configs with delete flag are deleted after the import

Expected behavior We were hoping that by defining the USync Sets, the import will just focus on the nodes defined on that set and not touch any other nodes even though they were marked for deleting.

About your site (please complete the following information):

• Umbraco Version: 12.3.6
• uSync Version: 12.2.3
• Browser : Chrome, Edge

Additional context

• were using USkinned 5.2.0

[KevinJump]

Hi,

Yeah - deletes' aren't looking at the path before they run :(

but this is partly because we don't know the path of content or media when its deleted :(, - items are first deleted to the recylce bin and this changes there path (to e.g recycled/item-name) and then they are deleted.

also the usync "deleted" file doesn't then store the path (and if it did it would be recycled/item name).

you could (and probibly want to) intercept delete's as part of the import process and then check to see if the item exist in umbraco and what the path of the item is.

potentially this is a slow thing (because of db lookups, to get the items and workout the paths of those items). but if you wanted to make sure, that is where i think the answer would be.

i have knocked up a skeleton of the code for this here: https://gist.github.com/KevinJump/1fe978f0d51bead1eb43f6454559dbfc

it would need a bit more work around working out the path of the things where you want them to be (paths are numerical inside umbraco so you need to do a thing where you build the path from the numbers!).

but that would be the thing (i think)

[fbpenalosa]

@KevinJump

Thanks for the response. I'll try explore the code you shared.

I wonder if there's a way to turn off the delete completely, at least for content import side? I mean, after I run the import, I wonder if the process can skip delete actions completely.

Thanks.

[KevinJump]

Hi, yeah the quickest way to turn off delete is to impliment a noficiation handler like in the example, but always return null when the node is a delete node (eg.

if (notification.Item.IsEmptyItem() is false)
  return;

// we only care about documents ? 
if (notification.Handler.EntityType != UdiEntityType.Document)
  return;

// if we are here, it is a delete and it is for content 
notification.Cancel = true;

[fbpenalosa]

Thanks @KevinJump

Correct me if I'm wrong. So I assume these lines:

`if (notification.Item.IsEmptyItem() is false) return;

// we only care about documents ? if (notification.Handler.EntityType != UdiEntityType.Document) return; `

...determines that the import encountered a file that has "Change=Delete" in its flag right?

Or does it have to go more granular like this

    var actionType = notification.Item.Attribute("Change").ValueOrDefault<SyncActionType>(SyncActionType.None);

    if (actionType == SyncActionType.Delete)
    {
        // this is a delete, 

[KevinJump]

Hi,

We are closing this for now, as it's not something we are going 'fix' in the core but can be achieved with the custom code.