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.
I'm getting some strange behaviour with Set-PWDocumentState. PWPS_DAB version = 184.108.40.206.
I have a workflow and have bounced a file along to 'Checking' state with a 'CAD' account. I then logged in as an 'Engineer' account to bounce it along from 'Checking' to 'Package Shared'. At this stage, if this is done through PWE, one of the checks that WRE does is the suitability code (BS 1192) to make sure it's not at S0, with a NOT_EQUAL_TO call. Also, the minor rev gets dropped (P01.1 -> P01) amongst other things. This does not happen if I do this through the PS commandline. The file happily bounces along to 'Package Shared' state, with no intervention by the WRE.
# Log in with test accoiunt capable of moving to next state in workflow
New-PWLogin -NonAdminLogin -LoadWRE
$doc = Get-PwDocumentsBySearch -DocumentName 'Some-Doc-Name-Number' -GetAttributes
# File is at 'Checking' state
$doc | Set-PWdocumentState -State 'Package Shared'
It seems like the LoadWRE switch is getting ignored completely
Right. I looked at the release posts and noticed that the LoadWRE switch appeared in 220.127.116.11, so I threw out 18.104.22.168 and installed the version before 22.214.171.124 which is 126.96.36.199.
This does not have LoadWRE, nor does it have the NonAdminLogin switch, so I had to log in with my admin account. Once that was done, I tried to move the file from 'Checking' to 'Package Shared' and received the same error as Pete did in his original post. I then decided to try 188.8.131.52 and see what happened.
After removing 1.4 and installing 1.5 it had the LoadWRE switch, but no NonAdminLogin switch. I logged in wioth New-PWLogin as before and specified LoadWRE and tried the same move from 'Checking' to 'Package Shared' and it went through, exactly as I noted originally.
So it's broken.
Ideally, if you don't log in with the LoadWRE switch, you should be able to bypass the WRE as Pete originally suggested. Sometimes this is necessary because things can become...stuck or unstable.
However, if you log in with LoadWRE it should run all the actions that you would expect the WRE to run as if you were performing the same operation in PWE.
I'm writing Pester tests to test infrastructure changes to the ProjectWise system. This involves logging in with some test accounts. These test account have different access rights at different stages of the workflow i.e. drafter, reviewer, authoriser etc.
So the tests log in with user account, move through workflow, check results, try to move further than user account can and test failure etc. Then log in with next person in the chain and repeat. Being able to do this against the WRE and with Non Admin accounts is critical to the whole process, otherwise it's pointless.
Can this be fixed?
Also, it seems to be returning the document passed in, in it's original state, even when the call succeeds. The error I suspect is just being output using Write-Host and is not being thrown, which would probably be better...
are you adding the -ErrorAction Stop to ensure errors get thrown properly?
Also, when logging in as Non-Admin the account still needs to be in a group named "PowerShell Users"
you probably won't be able to get around the WRE restrictions.
I've tried with and without ErrorAction Stop - the results are the same. Also, the account is in the 'PowerShell Users' group.
Still appears to be broken. Logged in with restricted user account that is in PowerShell Users group, -LoadWRE and -NonAdmin switches then tried moving a file from one state to the next. This would normally fail due to a WRE check for suitability I mentioned previously, but it happily advances the file.
Based on the above I have no confidence whatsoever that the rules and attribute setting/updating specified ion the WRE are being used.