Bug 1115085
| Summary: | PermissionDeniedException after an attempt to automatically claim next task in a swimlane | ||
|---|---|---|---|
| Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Tomas Livora <tlivora> |
| Component: | jBPM Core | Assignee: | Alessandro Lazarotti <alazarot> |
| Status: | CLOSED EOL | QA Contact: | Radovan Synek <rsynek> |
| Severity: | low | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.0.2 | ||
| Target Milestone: | ER2 | ||
| Target Release: | 6.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-27 20:07:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tomas Livora
2014-07-01 14:15:12 UTC
actually this is expected behavior as claim operation is attempted by the process logic (work item handler) that has no way to know about group/user relationship and thus rely on task service to perform this check. The exception is logged to at least give a bit of information to administrators why the auto claim operation fail. Do you think we should completely hide the exception? Maciej, I think hiding the exception is not a good idea. We should try to avoid it. I have just had a look at LocalHTWorkItemHandler where auto claim is performed. It should be possible to get UserGroupCallback from RuntimeManager and easily check if the user is a member of the group the task is assigned to. Am I right or am I missing something? Tomas, this is valid suggestion. The only thing I don't like is that we would duplicate the code responsible for checking if user is allowed to claim a task in the handler itself. But maybe it makes sense to avoid any operation on task service ... I'll need to think about this for a while and do some tests. Nevertheless, yes, you're right :) Thanks for good input Tomas, after looking into this more, the issue is that we cannot always rely on the UserGroupCallback taken from runtime manager as it might not be set in some cases. The most obvious example is business central that utilizes CDI to produce TaskService (with user group callback already configured) and provides that to RuntimeManager that will simply use it. That means the runtime manager itself (to be more precise its runtime environment) will not have user group callback set and by that we cannot make use of it inside the ht work item handler. So the only way to actually have it reliable is to use commands on task service to verify if user has rights to be assigned to. Though it will mean that if (s)he has rights to do so, it will cost two commands execution which will do the same things in the beginning just to avoid error being written to logs. Personally I think that is not worth it from execution point of view, what's your opinion on this? Maciej, considering your arguments from the previous comment I think the best way how to solve this issue is to catch the exception and write a message to the log explaining that auto-claim has failed. It is not an ideal solution but while this is low-severity BZ and the current behavior does not break any functionality it is better to fix it this way than executing more commands on Task service. change applied on master, warning will be printed out into logs instead of raw exception. jbpm master: https://github.com/droolsjbpm/jbpm/commit/ec15ecb86d51de01d6ff92e3af1338d90a35ff45 Verified on BPMS 6.1.0 ER2 No tests have been added as this BZ does not affect functionality. The only thing that has been changed is that now a warning is printed to the output instead of exception stack. |