M-Files VBScript State Action Problem - Access Denied

The underlying issue is that the server will look at the object's starting state (2) and the ending state (3), and check that the current user has the rights to make that transition.  If there is no valid transition from 2->3 then normal users cannot possibly have rights to do so.  Admins bypass this requirement check.

One simple hack you can use is to add a new state (4) after 2, place your code there, and make an automatic state transition from 2 to 4.  Automatic state transitions are run by the server, so the "current user" who then moves from 4-3 should be the server, who's an admin, who can then move the object regardless of whether there's a defined transition.

I haven't personally used this hack for a few years, but I think that I'm remembering it correctly.

Another solution - albeit needing you to use VAF - is to add an entry to a task queue on state 2, then get a task processor to do the move to state 3.  It adds some delay to the process so it may not be desirable, but it is a good workaround in some situations.

The underlying issue is that the server will look at the object's starting state (2) and the ending state (3), and check that the current user has the rights to make that transition.  If there is no valid transition from 2->3 then normal users cannot possibly have rights to do so.  Admins bypass this requirement check.

One simple hack you can use is to add a new state (4) after 2, place your code there, and make an automatic state transition from 2 to 4.  Automatic state transitions are run by the server, so the "current user" who then moves from 4-3 should be the server, who's an admin, who can then move the object regardless of whether there's a defined transition.

I haven't personally used this hack for a few years, but I think that I'm remembering it correctly.

Another solution - albeit needing you to use VAF - is to add an entry to a task queue on state 2, then get a task processor to do the move to state 3.  It adds some delay to the process so it may not be desirable, but it is a good workaround in some situations.

Craig is correct as always and has described very well why this rejection occurs. The "hack" he offers is a pretty good solution in most cases. I myself use it when necessary, but in this case it will remain in history that the action was performed by the M-Files server, and this will hardly please the auditors.

If you work for a regulated industry, or one where auditing of these specific objects is important, then obviously speak to your compliance officer (or similar) to understand the implications of such changes.  It is incredibly important to ensure that scripting does not affect your ability to meet any external or internal requirements.

But a blanket statement that automated actions cannot appear in an object's history is perhaps not accurate; there'll be a record of the fact that the object was moved from state 1->2 by user X, and there should be a documented automated process that the system will then move from 2-3 and 3-4.  As such there's still a record of who caused it to go to 4.

Plus, even in the original set of code, the object would be altered by the script and would have lost the audit trail data anyway.

I totally agree with you Craig. I was particularly impressed by this part of the code, which really manipulates the user who last modified the object.

Dim objLastModifiedByTypedValue
Set objLastModifiedByTypedValue = CreateObject("MFilesAPI.TypedValue")
objLastModifiedByTypedValue.SetValue MFDatatypeLookup, CurrentUserID

' Update the last modification info.
Vault.ObjectPropertyOperations.SetLastModificationInfoAdmin ObjVer, True, objLastModifiedByTypedValue, False, Nothing

This is documented on the Developer Portal: Audit Trail and Scripting (fixing "(M-Files Server)" in the audit logs)

But, again, from an auditing perspective, needs to be done with care.