Set-PWDocumentState enhancement

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 would be reluctant to create any cmdlets or capabilities to bypass the WRE. If you are encountering issues, I would recommend contacting Bentley Support to determine the cause and find a solution.

  • The fact is that the WRE does fail at times and also there is a requirement to move files through the workflow programmatically outside of Projectwise Client (the benefits of PowerShell).

    As long as this function is restricted to administrator users (and/or another controlled group) then this should not be an issue

  • That's fine in a sterile environment, but when a supplier is screaming because their submission is delayed and Early warnings and compensation events are set to be initiated against your organisation it is not always possible to wait for TSG to respond. Over rides used by responsible teams are sometimes necessary and having that functionality available would be preferred.

    I have outstanding calls open for weeks whilst investigations are ongoing into the cause, but in the meantime the thousand or so construction staff on our sites are not waiting for me to find out the result.

    The risk in these cases is sometimes acceptable to bypass, but should ultimately be made by each customer, as they see fit. But the customer also needs to understand that if they do use a bypass there could be consequences, hence the use by the customers Administrators or responsible persons. 

  • I'm getting some strange behaviour with Set-PWDocumentState. PWPS_DAB version =

    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, so I threw out and installed the version before which is

    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 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?