How to find the tasks a user was able to execute before another user "took" them?

1
0
-1

Hi

I've been searching the javadoc, but cant find what I'm after -- which is: a way to list the "human tasks" that the logged-in user WOULD have been an actor candidate for if the task hadn’t been "taken" by someone else (aka: "assigned to" another user).

I want to be able to present a list of tasks that the person is or was responsible for, including those that have been taken by another user in the actor group, but which haven’t been completed yet.

Any clues, gurus?

T

2 answers

1
0
-1

Hi,

I have a very similar problem indeed...
Maybe something that can ease this problem : do not assign the task when the user displays the task's form, but assign it only when the user submits the task (a personalized submit button should be able to do the job). Then you only have to find a way to get all the pending tasks for the user, because you don't have any more unsubmitted assigned tasks. If you have the REST API call that does it I'm very interested !

If you found a satisfying solution please share it.

Best regards,
Marina

1
0
-1

Interesting one, and there is definitely nothing in the product that will do this that I've seen.

Devils advocate for a second though:

I want to be able to present a list of tasks that the person is or was responsible for, including those that have been taken by another user in the actor group, but which haven’t been completed yet.

I want to be able to present a list of tasks that the person is responsible for

If they are responsible for then they will have taken the task, easy through current methods.

I want to be able to present a list of tasks that the person was responsible for

If they were responsible for then they will have taken the task, easy through current methods (archive when the case is complete).

...including those that have been taken by another user in the actor group...

If the task has been taken by another person in the actor group then a different individual cannot be held responsible for it. Standard Labour practice. Imagine if your colleague in the next cubicle got the boot because you didn't find out this answer. Would that be right? :) May be it would but who can tell :)

I also think you're overthinking the

...way to list the "human tasks" that the logged-in user WOULD have been an actor candidate for if the task hadn’t been "taken" by someone else...

The logged-in user WILL ALWAYS be a candidate if they are in the Actor Group that can take a task, there is no Would have been an Actor Candidate.

The way i would do this (as a batch overnight type report) is:

for each Active task
Get Actor Group
order and reduce

for each Actor Group
Get Individuals in Actor Group

Then produce a nice little report that says:

Actor Group
Individual Name:
Tasks that are/were available to you but you didn't take

One thing we found was we also had to match the following :) (might be giving something away here (like we've done something similar)) :

Do not include Tasks that opened and closed during the time that the individual was working on another task. It skews the results you are looking for, which I believe is a

Report of tasks that presented themselves to Actor Group: AG - Employee: Emp while they were not working on another task - I've repeated myself here :(

Also do not forget labour laws on "natural breaks" etc. in your calculations. Unions are very picky on this.

Performance Reporting is a very interesting and fraught with danger subject.

Also be very aware that Actor Groups are one thing, what happens if you have Actor Group that is modified by an Actor Filter?

For example: we have an Actor Group for Claims Processing, which is modified by an Actor Filter removing people who are not in the office (via an interface with HR who look after holidays, training, maternity and sick leave etc.), sometimes we have 25% not in the office for some valid reason or other...

I repeat: Performance Reporting is a very interesting and fraught with danger subject. It needs to be done right.

regards
Seán

PS: As this reply offers an answer your question, and if you like it, please Mark UP and/or as Resolved.

Comments

Submitted by chris.lowth on Sun, 02/12/2017 - 23:53

Hi Sean

Thanks for your comments.

I think there is a use case that sits outside the model you describe.

In my case, my process is for recruiting volunteers to a large community project. The project typically has 500 or so volunteers each year working in 20 or so teams. When a volunteer signs up, he/she chooses the teams they'd like to be part of. Some of the larger teams have 2 or 3 team leaders who share the work of approving the volunteers and progressing their application, running security checks, training, having interviews etc.

This is not an "employment" situation, and no-one is going to be reprimanded for not doing a particular task. This is a relationship-based community project staffed and lead by volunteers who mostly have other "real" day-time jobs, and are involved because they are friends of other team members. We have no contracts, no working hours, we PAY to be part of it (we are not paid to be part of it). So "employment law" etc is irrelevant in this case. Most of the "work" will be done by the volunteer team leaders at home in their evenings, and their motivation for doing it is that it means their team will grow quickly. If I make the process too "big-brotherly" then they can simply walk away from it, and they'd be within their rights to do so [it's a little different from most Bonita applications in that regard, I guess]. Bonita needs to be a facilitator, not a police man in my case.

Now the typical use case: If someone volunteers for the team I co-lead and I take/open a task related to that volunteer (eg: get parental consent in the case of a child volunteer), and then I see something in the details that means that one of the other team leaders is better placed to progress that particular application than I am (for example: the person teaches at the same school that they go to or there is some other established relationship - which is far from uncommon), then as it stands, I need to explicitly "unassign" the task from myself in order for the other person to be able to see it. Now -- if we were using the portal, then I am disciplined and would do that, but I guarantee that at least some of the 40 or 50 team leaders will forget that step - AND; we're not using the standard portal. With my replacement front-end, the "take" step is implied when you click on a task, which means it then vanishes from the co-leaders lists - which is why I need this kind of query. My plan would be to mark the task as "taken by Fred", and allow an option to override that. In short I want ALL the leaders of a team to be able to see ALL the pending/active tasks relating to the team - even those that have been "taken" (in Bonita terms) by the other team leaders. Effectively, what I really want to do is turn off the take/assign/unassign logic entirely (it gets in the way, for me) and introduce an alternative locking mechanism for tasks that is aware of when a user opens a form and either abandons or submits it.

I'm working on adding a ProcessAPI call for the query - it's going to be largely the same as the existing logic, but ignores the setting of the "task assigned to" field. At least: that's the theory.

Chris

Submitted by Sean McP on Mon, 02/13/2017 - 00:20

Hi Chris,

thanks for your understanding of my answer, and as you guessed, I'm used to the Big-Brother adoption usage. Banks, other financial Institutions and government bodies in certain countries other than the normal ones where Watching is a primary, not a secondary management function.

Context in this case is very important :)

Your explanation certainly gives more idea about what you are trying to do and looks very interesting.

I think you may be onto something by creating a processAPI call for the query.

Good luck and apologies for my misunderstanding.

regards
Seán

Submitted by chris.lowth on Mon, 02/13/2017 - 00:37

No need to apologize! I know my use-case is out of the ordinary.
I really appreciate the time you take to understand and answer questions on this forum.

Submitted by Dibyajit.Roy on Mon, 02/20/2017 - 08:36

Hi
I did a Summary Page where User had to choose either a Process from a list of Processes or Choose a group from a list and further choose any member from that Group. The result would be to display Pending tasks, Assigned Tasks and completed Tasks.
Take a look at the Below API's

Get task Details based on User id -
../API/bpm/humanTask? p=0&c=100&f=state%3dready&f=assigned_id%3d{{userID}}

List all the Open Tasks -
../API/bpm/humanTask?c=1000&p=0&f=processId={{processid}}&o=state%3dready

List all the Completed tasks -
../API/bpm/archivedHumanTask?p=0&c=100&f=assigned_id%3d{{userID}}

Hope this helps

Submitted by chris.lowth on Wed, 02/22/2017 - 12:34

Hi Dibyajit

Thanks for the feedback, though sadly it doesnt give me what I want. I need a list of tasks that are assigned to OTHER users who are in the actor groups as the logged in user. In other words: the active/pending tasks the logged-in user WOULD have seen if they hadn’t been "taken" by someone else.

In the end, I cracked it by going directly to the tables in the journal DB using SQL queries - but there is no API to get the particular list I need.

Maybe there should be?

Chris

Submitted by Sean McP on Wed, 02/22/2017 - 19:02

Add it to the Ideas Forum , though I think that will be one a long way off as a slightly unusual requirement.

Or create a custom REST API and then publish it to the Projects Forum for others to use...which might then be taken up by Bonitasoft and integrated...

regards

Notifications