Workitem approval changes workflow state?

Dan Sevcenco (50●2●19●23) | asked May 04 '13, 2:27 p.m.

I am writing an advisor that is responsible to decide whether the save operation can be allowed based on the state of all the approvals that exist in the workitem.

Upon debugging the code, I noticed something strange to me. When the approver closes an approval and saves the workitem, the workflow state for the oldstate and new state show that the server thinks a workflow state transition is about to take place, even though the state of the workitem has not been changed by the user.

Why is RTC behaving like this? This behaviour is throwing off my validation logic that says that if the workflow state is not changing, the advisor does not need to do anything. How do I compensate for this?

3 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Ralph Schoon (62.0k●3●36●43) | answered May 05 '13, 4:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Dan, the process configuration can be set to change the state of a work item on approval. This might be configured and cause what you see. You can configure it not to do that however.

permanent link

Dan Sevcenco (50●2●19●23) | answered May 05 '13, 11:06 a.m.

Hello Ralph,

I know of that possibility and it is disabled in my case. I did a bit more debugging and this is what I found:

- on the first attempt to save the item after an approval is closed by the approver, RTC returns the next state of the workitem on the workflow as being "state.s2".
- on a 2nd attempt to save the workitem, after the first attempt is rejected by the advisor, without making any changes to the workitem, the same RTC returns the next state of the workitem as being "state.s1".

I wonder why is it doing this and how on earth am I to compensate for this behaviour in order to make the right decision in the advisor?

Thanks,
Dan

Comments

Dan Sevcenco commented May 05 '13, 1:41 p.m.

OK, please strike my answer. I figured it out.

Ralph Schoon commented May 05 '13, 1:44 p.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

What did you find?

Dan Sevcenco commented May 06 '13, 3:28 a.m. | edited May 06 '13, 3:45 a.m.

It was a mistake a made due to the fact that I do not know RTC well enough, yet. Basically, I forgot that I had attached state transition rules to the work item workflow and the observed behaviour did not trigger in my mind the link to the cause.

The pre-defined behaviour of RTC's would have worked very well if not for the fact that my work-item has to have several approvals that are all closed before a state transition can be allowed to take place.

permanent link

Dinesh Kumar B (4.1k●4●13) | answered May 05 '13, 11:16 p.m.
JAZZ DEVELOPER

have you tried the precondition "Required Approvals" which does :
"Verifies that a work item can only be saved if all required approvals are in the configured state."

You can reach it through:
Open PA in Eclipse Client > Process Configuration Tab > Team Configuraiton > Operation Behavior > Work Items > Save Work Item (server) > under specific role > Preconditions > Add Required Approvals > Work Item Type > Select specific state and Edit Approvals

Comments

Dan Sevcenco commented May 06 '13, 3:33 a.m.

I know of that precondition. However, it does not exactly map to the business rules that need to be automated in order to properly manage this workitem type.

I have several approvals that need to be processed by different people in different organizations. The owner is changed automatically each time an approval is closed to transfer the workitem responsibility and accountability. And only after all the approvals are closed, a workflow state transition can be allowed, depending on the approval decision.

It's all about the answers!

Related questions

Workitem approval changes workflow state?

3 answers

Your answer