3

I'm (trying to) using Reset-ItemField to remove broken workflow links. While no error is shown in the console, the relevant fields are not changed.

$counter = 0

Get-Item -Path :master -Query "/sitecore/content//*[@__Workflow = '{f1fb8a76-9c0e-fcbb-3f7f-a57c84e92e39}']" |
 ForEach-Object {
    Write-Host "Workflow " $_["__Workflow"]
    Write-Host "Workflow state " $_["__Workflow state"]
    Write-Host "Default workflow " $_["__Default workflow"]
    Reset-ItemField -Item $_ -Name @("__Workflow", "__Workflow state", "__Default workflow")

    Write-Host "Workflow " $_["__Workflow"]
    Write-Host "Workflow state " $_["__Workflow state"]
    Write-Host "Default workflow " $_["__Default workflow"]

    Write-Host "Broken workflow link found and removed from " + $_.Paths.FullPath
    $counter++
    if ($counter -gt 0) {
        break
    }
}

UPDATE 1

As Mark mentioned it is necessary to include the -IncludeStandardFields parameter when modifying workflow via Reset-ItemField.

What I have found so far is that I can modify the default Sitecore homepage item (/sitecore/content/Home) using with the following script:

$homeItem = Get-Item -Path :master -Query "/sitecore/content/Home"
Reset-ItemField -Item $homeItem -IncludeStandardFields -Name @("__Workflow", "__Workflow state", "__Default workflow") 

This proves that SPE is not broken in this environment. It also implies that the issue here is either to do with the way I am retrieving items (using Get-Item with a query) or is to do with permissions on the items retrieved by my original query. It is strange, however, that there is no warning or error message when the cmdlet fails to update items. I have also tried wrapping the update foreach loop with a using block with a SecurityDisabler New-UsingBlock(New-Object -TypeName "Sitecore.SecurityModel.SecurityDisabler").

UPDATE 2

After attempting to manually clear the workflow fields, I realised that there is some item:saved handler, or similar, which is re-assigning the workflow after the item is saved. This confirms that there is no problem with SPE or the script and there is no failure (or silent failure). I neglected to mention that the solution uses Sitecore Commerce Engine and I suspect there is some item:saved handler which is reassigning the workflow after an item is saved.

  • Query.MaxItems? presumably there are more items on your real environment, than when you run locally – Mark Cassidy Jul 29 at 19:18
  • But surely Query.MaxItems would only affect how many items are retrieved to update, now how they get updated? – Matthew Dresser Jul 29 at 19:25
  • 1
    Hey, I'm just challenging your assumptions :-) One of them is wrong, that's why we're here. – Mark Cassidy Jul 30 at 7:07
3

I had something similar just a couple of weeks ago. I ended up solving it like this:

$contentItems = Get-ChildItem master:\content -Recurse
ForEach($item in $contentItems)
{
    $item.Editing.BeginEdit()
    $item["__Default Workflow"] = $null
    $item["__Lock"] = $null
    $item["__Workflow State"] = $null
    $item["__Workflow"] = $null
    $item.Editing.EndEdit() | Out-Null
    Write-Host "Processing " $item.FullPath
}
Write-Host "All Done!"

For Reset-ItemField to work, I suspect you may need to add -IncludeStandardFields as an argument. This is required for any fields that are included in Sitecore's Standard Template.

  • I had already tried this approach of using BeginEdit() / EndEdit() but that didn't work for me either. The difference between your answer and my previous approach was the use of $null instead of "" but that still does not fix the issue. I think there must be something else environment-specific which is causing this as my script worked locally. – Matthew Dresser Jul 29 at 12:20
  • 1
    A SecurityDisabler perhaps. You did see the bit about -IncludeStandardFields as well right? – Mark Cassidy Jul 29 at 12:29
  • I did see the bit about -IncludeStandardFields but I don't want to reset every field, just these workflow ones. – Matthew Dresser Jul 29 at 12:32
  • 2
    No, that's not how it works. The switch merely enables these base fields to be worked upon. Without it, your "__Workflow" field names will just be silently ignored. As you experience. – Mark Cassidy Jul 29 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.