L3 - Default Environment (Required on creation):
Java, Spring Boot, Camunda 7.13.0
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):
I have a filter "tasks that I own" with one critera. The criteria has the key "User / Group" : "Owner" and the value of that key is "${currentUser()}" (see screenshot "filter settings"). I assign, with the help of a listener, the current user as an owner to the current task. Then I would expect that task to appear in the filter "tasks that I own". However under that filter I cannot see my task (see screenshot "filter shows no tasks"). But when I click on the settings of that task and just click save (without changing anything), suddenly the tasks I am owner of are appearing (see screenshot "filter shows tasks after clicking on save").
Steps to reproduce (Required on creation):
Create a filter in java "tasks that I own" with one critera. The criteria has the key "User / Group" : "Owner" and the value of that key is "${currentUser()}" .
You will need a process that calls at the beginning a listener, which sets the currentUser to the owner of the task. Start the process and look if under your filter "tasks that I own" the task is shown.
If I create the filter directly in the tasklist, the filter is working fine. Its only not working when I create it in my java code. The strange thing is that when I open the filter and just click save, its suddenly working. So my java code is creating it with the right attributes, but somehow there is a bug in the webapp.
Observed Behavior (Required on creation):
I have a filter "tasks that I own" with one critera. The criteria has the key "User / Group" : "Owner" and the value of that key is "${currentUser()}" (see screenshot "filter settings"). I assign, with the help of a listener, the current user as an owner to the current task. Then I would expect that task to appear in the filter "tasks that I own". However under that filter I cannot see my task (see screenshot "filter shows no tasks"). But when I click on the settings of that task and just click save (without changing anything), suddenly the tasks I am owner of are appearing (see screenshot "filter shows tasks after clicking on save").
Expected behavior (Required on creation):
The user clicks on a filter "tasks that I own" in the Camunda Webapp. All tasks are shown which the current user owns.
Root Cause (Required on prioritization):
When you create the filter "tasks that I own" there seems to be a bug. All other tasks that I created with my java code are working fine.
Solution Ideas (Optional):
Hints (Optional):
This is the controller panel for Smart Panels app
[CAM-13353] Filter key "User / Group" : "Owner" is not working when created with java
Hey MarvinKern,
yes I could. And then I also just realized how to probably fix it.
In the code that creates the filter's task query, how exactly are you setting the expression for the owner? I assume you are using something like
taskService.createTaskQuery()
.taskOwner("${currentUser()}")
Using that query option, I can reproduce the behavior you described. However, in order to use an expression for such an attribute, the query API additionally offers "#taskOwnerExpression" that allows to set the expression to evaluate directly. That way, it worked in Tasklist directly for me.
Why is that?
Using "#taskOwner" will try to match the String as-is without evaluating the expression beforehand. Now, saving the filter in the Webapps (Tasklist in that case) will post the filter to the backend again and since we only offer one field for setting either an expression or a direct value for the owner via frontend, the value will be evaluated with regards to being an expression or not. The appropriate method from the task query API will then be used (either "#taskOwner" or "#taskOwnerExpression"). Tasklist is "fixing" the error for you, so to say.
Please give it a try and let me know if that works for you.
Best,
Tobias
Hey Tobias,
Wow thanks a lot!!! I have been looking for a solution for so long.
As you described, the following code is working fine for me:
taskService.createTaskQuery()
.taskOwnerExpression("${currentUser()}")
So as a workaround this works great 
I am happy that you will try to fix this bug in future.
Thats a good start for the weekend 
Have a great day,
Marvin
Hey MarvinKern,
great to see that this works for you.
Would you mind detailing what you would expect to be fixed, now that we discovered that using the right query option for the job solves the issue you discovered?
Best,
Tobias
Hey Tobias,
Yeah I am very happy about that
I am not sure if the behavior is wanted, that #taskOwner is not working 100% correctly and #taskOwnerExpression is working fine.
For me it lead to lots of confusion. However not that I know that there is a workaround, this wont have to much priority for me. But I guess it would be nice if both options work in future. On the other hand I understand, that there are much more things to do, that might be more important.
So I leave it on your side to decide, what will be the best thing to do next with this bug
Best regards,
Marvin
Hi Marvin,
thanks for that detailed feedback.
The behavior of the query API options is wanted and expected, thus their separate naming. They are also properly described in Javadoc and the REST API. I agree that being used to creating filters in the Webapps, this might not be the most obvious choice to make. I am however also not sure how to improve this any further.
We are happy for any suggestions on this based on your experiences. Is there any resource that you think would have helped you in avoiding running into this? Merging the functionality of those two methods into one is not ideal from our perspective due to a higher complexity when it comes to evaluating the value of the query in the database.
Thanks again and best,
Tobias
Hi MarvinKern,
with regards to my previous comment, is there anything you would see that can be done to improve the situation you experienced?
If not, I would rather close this ticket as fixed as there is a proper method for your use case.
Thanks and best,
Tobias
Hey Tobias,
Thanks a lot for your help on this case
I guess the only thing that would help would be to mention that problem in the camunda documentation. To be honest I am not 100% sure where to put it, so I would leave this decision on sour side.
I also created an entry in the camunda forum which should help.
If this problem is mentioned anywhere in the documentation, I guess we can close this ticket.
Best regards,
Marvin
Hi MarvinKern,
sorry for the late response.
We inspected the current documentation (including the Javadoc) and still consider all parts sufficiently described.
Also considering that this is the first time we have come across this issue, we will not adjust any documentation related to this topic proactively.
That being said, we value the specific insights you might have gained while using our APIs and are open to concrete suggestions regarding documentation improvements from your side. Any specific input via this ticket and/or any pull requests will be much appreciated. If you would like any pointers for starting with such a thing, let us know and we will be happy to get you started.
Thanks for your time and for moving forward with this in the first place.
Best,
Tobias
Hi MarvinKern,
I will close this for now due to inactivity.
Feel free to reopen if you have any more input or questions on this.
Best,
Tobias
Hey @Tobias Metzke-Bernstein,
Thanks for the quick response.
Could you reproduce the error in your code?
Best regards and many thanks,
Marvin