> > I'd suggest leaving the task in the worklist of the person until he becomes > available (he's probably gone for a coffee).
Actually, with "not available" I mean: the position assigned to that task is vacant or the system has been unable to find a position due to some kind of data integrity errors on the system that manages the organigram. In this case, we need to fix the error on the organigram system and redo the task. This is where the rescue participant comes in. OK, IIRC the 'on_error' handling code is different from the regular > 'dispatch to participant' code. I will investigate that. Thanks. What about a single participant that does all the error handling ? That's not very flexible because the error handling complexity can increase and we would probably end up with a huge set of if-statements. Also, I'd love to be able to filter workitems by participant. Using different participants make it simpler because (if I'm right) Ruote has a method call to return all the workitems for a specific participant. Otherwise, I would have to fetch all errors, then scan all of them to match those where the current participant is the selected rescuer. Anyway, a first implementation can probably share a common participant, to see if we're not making some bad design decisions. I will follow https://github.com/jmettraux/ruote/issues/25, unless I made some bad assumption, I believe it can be exactly the solution we're looking for. Thanks, -- Simone -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
