Forum OpenACS Development: workfllow + project permission

Posted by Marcello Bontempo Salgueiro on 07/30/10 07:48 PM

Hello, my name is marcello, and i think i found a bug in workflow permission.
When you use a bug-tracker and set admin permission for one user in bug-tracker, the user only receive permission if he have a perfil administration of openacs site, not in a project of the bug-tracker.
So i resolved this problem with this patch here, don't worry i'm newbie on tcl and openacs. ;)

Here the patch:

--- dotlrn-2.3.1/packages/workflow/tcl/case-procs.tcl 2010-05-06 17:21:22.000000000 -0300
+++ /var/www/dotlrn-2.3.1/packages/workflow/tcl/case-procs.tcl 2010-07-16 17:44:10.000000000 -0300

@@ -1489,8 +1491,15 @@

if { !$permission_p } {
set privileges [concat "admin" [workflow::action::get_privileges -action_id $action_id]]
+
+ set project_id [db_string select_permission_project { select
+ package_id
+ from acs_objects
+ where object_id= :object_id } ]
+
foreach privilege $privileges {
- if { [permission::permission_p -object_id $object_id -privilege $privilege -party_id $user_id] } {
+ if { [permission::permission_p -object_id $object_id -privilege $privilege -party_id $user_id] ||
+ [permission::permission_p -object_id $project_id -privilege $privilege -party_id $user_id] } {
return 1
}
}

and sorry about my english! =D

2: Re: workfllow + project permission (response to 1)

Posted by Eduardo Santos on 08/06/10 03:03 PM

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.