Set-PWDocumentState enhancement

Hi Peter/all.

With COVID-19 and home working, we are seeing more occurrences of workflow failing/timing out, which leaves the file in the wrong workflow state, (versions are sometimes wrong, or initials missing as well).

I don't see any change to the Set-PWDocumentState command in terms of an 'Admin over-ride'.  Is there any quicker way I am missing to get the State manually changed/reverted when using WRE or is it still a manual hand-cranked fix every time?

As we dont have easy write access to the Datasource DB, we are having to edit the WRE spreadsheet every time, to allow the file to be fixed, and then put the WRE rules back again, which is time consuming and adds risk.

Any advice appreciated.

Thanks.

Jim

Jim

Set-PWDocumentState will change a document's state (even versions) to whatever state you give it. I've used it to change a file stuck in CADQA state back to WIP,l for example.

Cheers

G

Yeah I read that. At least it recognised our WRE States even when not loaded. Appreciate it didn't help your test back then.

Cheers :)

I've started to get the same issue on code that previously worked. I can do it in PWise thru WRE with the same account.

Error:

WARNING: Failed to change state to 'Shared' for ..... Error: 58268

Script:

Get-PWDocumentsBySearch -FileName ($FileName + ".nwd") -FolderPath $PWloc -JustThisFolder | Set-PWDocumentState -State "Shared" -SkipIntermediateStates -IgnoreStatus

Only real difference recently is we upgraded PWDI to 3.299

Installed the most recent PW_DAB with no improvement.

Any help appreciated.

If you are using Server Side processing of the WRE then from my tests Set-PWDocumentState no longer works.

Thanks for the prompt prompt reply. I have switched to server side processing on that datasource so will be the explanation. Do you think this is something that is possible to be fixed with a cmdlet update in the future or is it now permanently broken? Possible to a access/edit thru a SQL call?

If you are trying to invoke a WRE operation with it's conditions/actions you could try the PowerShell module PWPS_WSG and it's cmdlet Invoke-WSGWorkflowCommand. This utilizes the WSG to invoke the WRE server side operation like the Web Connections do from a connected project. If you are trying to change the state of a workflow document outside the WRE operation pathways, for example as an undo function you would be relying on an update to the cmdlet or a workaround such as using a SQL call but I'm not suggesting you do that. If there are enough users asking for an updated cmdlet and it's technically possible to implement with the SDK the developers are normally very helpful in doing so. 

If you are trying to invoke a WRE operation with it's conditions/actions you could try the PowerShell module PWPS_WSG and it's cmdlet Invoke-WSGWorkflowCommand. This utilizes the WSG to invoke the WRE server side operation like the Web Connections do from a connected project. If you are trying to change the state of a workflow document outside the WRE operation pathways, for example as an undo function you would be relying on an update to the cmdlet or a workaround such as using a SQL call but I'm not suggesting you do that. If there are enough users asking for an updated cmdlet and it's technically possible to implement with the SDK the developers are normally very helpful in doing so. 

Jigged the script with Invoke-WSGWorkflowCommand, works well, better than my previous clunky code. Thanks for your input.

I just downloaded this PWPS_WSG and wondered if you could explain the parameters. CommandID, CommandLabel and the WSGClientContext? Not sure what these are looking for. I am basically looking to fix an existing script which would flip a doc state from one to another. 

d