Set State Action defaults to Next Lifecycle State

[dwilliams]

When one of our users selects the "Set State" action for an object, the
target state for all the objects collected are automatically set to the
next possible state in their lifecycle. When I perform the same action,
the target state remains at the current state and must be manually
changed.



Any idea's as to why this user is seeing this behavior? The user
expressed that this is a new issue as of today. It's got me puzzled.





Dax Williams
Engineering E-Tools Administrator
GE Healthcare OEC

Surgery

[mlovejoy]

Dax

Have you changed the ACL's lately, taking away the administrative
permissions for that user ?

Marc

On 2/6/2012 6:38 PM, Williams, Dax (GE Healthcare) wrote:
>
> When one of our users selects the "Set State" action for an object,
> the target state for all the objects collected are automatically set
> to the next possible state in their lifecycle. When I perform the same
> action, the target state remains at the current state and must be
> manually changed.
>
> Any idea's as to why this user is seeing this behavior? The user
> expressed that this is a new issue as of today. It's got me puzzled.
>
> *Dax Williams
> *Engineering E-Tools Administrator
> GE Healthcare OEC
>
> Surgery
>
>

[patrick.chin1]

Check your transitions of each state in the lifecycle for set state. Sometimes you should not allow to set every state. It depends on your business and administration rules.

[dwilliams]

Thanks David, Mike and Marc for your replies.



It appears the user was removed from a Library Manager role and only had
set state rights for his remaining access. Library Manager has full
control and transition rules are not considered.



What we found is that if a user only has "Set State" rights, the Target
State will automatically be populated with the first state specified in
the Lifecycle transition rules. This makes sense but I don't necessarily
agree with it since it adds room for error. I personally feel that the
user should have to select a target state.



I guess our best option is to setup the transition rules so that a user
with set state rights can set the state to itself (example: "In Work" to
"In Work")



Thanks again,

Dax