Hi,
I have a timesheet business object and I'm using a state machine to allow it to go through the following states:
Draft
Submitted
Approved (or Rejected)
I have an "Assigned to" field. When the timesheet gets created, it is assigned to the employee, and when they change the state to "Submitted", I change "Assigned to" to be that emloyee's manager. However, the employee can still see the state options "Approve" and "Reject", and can change the state, even though only a manager should be able to approve or reject a timesheet.
Is there a way that I can lock down the State Transitions to a particular user or role?
Thanks
Alistair
We have closed this ticket because another page addresses its subject:
StateMachine - How to manage availability of transition actions based on security roles and current object criteria
Hi Alistair,
To prevent certain users from entering certain states, you can specify criteria for a state (IState.TargetObjectCriteria). Use the IsCurrentUserInRole custom function to test the current user role name. However, it supports only the old security system. We will address this shortcoming in the next maintenance update (Security - IsCurrentUserInRole custom function cannot be used with the new security system).
Thanks,
Michael.
Thanks.
In the state machine builder at run time, I can set TargetObjectCriteria = "[AssignedTo] = '@CurrentUserID'".
However, I would rather do this is code (I don't want to have to set up the states every time the database gets cleared down, or if I want to deploy a new instance, or if I want to reuse the code elsewhere).
I tried
approvedStatus.TargetObjectCriteria = "[AssignedTo] = '@CurrentUserID'";
But this doesn't work - it's a readonly property.
Then I tried:
approvedStatus.TargetObjectCriteria.Insert(0,"[AssignedTo] = '@CurrentUserID'");
But this throws the following exception in code:
Object reference not set to an instance of an object.
Is there any way to set this in code?
Thanks
Alistair
Hi Alistair,
It is unclear what "approvedStatus" in your code is. Both non-persistent DevExpress.ExpressApp.StateMachine.NonPersistent.State and persistent DevExpress.ExpressApp.StateMachine.Xpo.XpoState classes that represent states have their TargetObjectCriteria property writable. Would you please provide us with a small sample project, demonstrating the issue?
Note that the "[AssignedTo] = '@CurrentUserID'" criteria string is not quite correct. First, it uses an obsolete read-only parameter. Second, it compares an object instance (a reference type) with a key (a value type). Please use the "AssignedTo.Oid = CurrentUserId()" filter string instead.
Thanks,
Michael.
Thanks. My mistake, I was using new IState rather than new State.