Hi Marcello,
I guess the permission problem is a little bit more complex than that. You see, the bug-tracker package is based on the workflow package, wich is a general package that provides implementation to cases and actions. A bug in bug-tracker can be described as an specialized case of action.
For every action in workflow you can provide a set of roles. Every set of roles for one action may have individual permissions.
So, resuming the permission check, the first check will be: is this case assigned for that user? Take a look at this piece of code:
1483 set assigned_p [db_string assigned_p {
1484 select 1
1485 from wf_case_assigned_user_actions
1486 where enabled_action_id = :enabled_action_id
1487 and user_id = :user_id
1488 } -default 0]
1489
1490 if { $assigned_p } {
1491 return 1
1492 }
If the case is assigned for the user, the permission is ok.
The next check is related for the role. Take a look at this piece of code:
1494 foreach role_id $user_role_ids {
1495
1496
1497 # Is this an allowed role for this action?
1498 set allowed_roles [workflow::action::get_allowed_roles -action_id $action_id]
1499 if { [lsearch $allowed_roles $role_id] != -1 } {
1500 return 1
1501 }
1502 }
1503
If the action is allowed for the role, the permission check is ok. Now, the last check will be: is this allowed for the action admin? If the action admin has enough privileges, the permission is ok.
It seems to me that the problem is not related to workflow, but with bug-tracker. If the user is admin in one bug, it should be administrator for the specified action. The permission is not probably being set correctly when you set admin privilege for a bug in bug-tracker. I would take a look at that.
