Would it be possible to add an 'Admin Override' option to the 'Set-PWDocumentState' command in PW PowerShell?. This option should only be useable by members of the Administrator group or by using a '-AdminOverride' option
When this function is used on an object managed under the Workflow Rules Engine (WRE) it returns a 58268 error ("Manual change state not allowed. Please use Workflow customization rules to change document state")
Access to this additional option is required for system Administrators to fix problems with WRE where on occasion the rule action times-out and the file is left in the wrong state. This can be caused by a number of things such as large/corrupt files or even a slow network connection.
I know this can be achieved by editing the database entries but I need a managed function that can be configured to achieve the result in a consistent and controlled manner.
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.
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.
Thanks Glenn. Appreciate the quick response.
I guess Peter's original behaviour observation has been superseded then. I didn't notice anything in subsequent release notes that suggested Set-PWDocumentState would now work with files using WRE. It even let me change state without logging in using -LoadWRE switch just now.
This will help the business.
Glad to help. As I posted above, the LoadWRE switch seems to be completely ignored.
Yeah I read that. At least it recognised our WRE States even when not loaded. Appreciate it didn't help your test back then.
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.
WARNING: Failed to change state to 'Shared' for ..... Error: 58268
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.
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.