Permissions and Coded Destination Rules

  • 6 August 2007
  • 4 replies
  • 0 views

Badge +5

We have built a workflow that has the destination of the next activity chosen by the user in the previous user event.



The code in each activity destination rule looks something like this...



public void Main(ref DestinationRuleContext K2) {

K2.ResolveQueuesToUsers = true;

K2.Destinations.Add(DestinationType.User,"domainusername");

}



(there is code that figures out the username, but I've left that out).



The issue we have hit is that each user requires admin privileges on the workflow for the above to work, which is totally unexpected. Any ideas why ? Looking at the code generated by a normal destination rule - such as "Send to Originator" has no special configuration for security...



Any explanation would be great. Obviously we don't want to give all users admin privileges.



Jonathan Beckett


4 replies

Badge +5

In the true spirit of finding the answer immediately after posting the problem, I think I may have done just that.

The code I have written (in a code module) to resolve the destination user uses the string table to hold the database connection strings.

Am I right in thinking you  need to be an admin on the process to read from the string table container in the SourceCode.KO.DestinationRuleContext object ?


 

Badge +4

J,


I'm not so sure about that as you can use string table entries elsewhere in event wizards without granting a specific user admin rights on a process. Mind sharing the error you are getting when running the process without the admin rights set?


 G

Badge +8

Hello Jonathan,


The code in the destination rule and any code accessing a string table var are executed on the k2 server by the k2 server service account user, end-users does not come into the picture at all.


What are the symptoms which make you beleive they need admin permissions?


In K2, if a user becomes a destination user he does not need any permissions at all to complete the worklist item, not even view permissions.

Badge +5

I just found the problem.


It was nothing to do with code modules, or string tables...


The ASP page used by users to manipulate their worklist items had some legacy code in it that tried to push a couple of process data field updates back into the process instance through the K2ROM.


Of course - in SP4, this avenue of updating process data fields was closed off - you have to be a process admin to call the Update() method on the process instance.


Thankfully I have abstracted virtually all the data to our own data store outside of K2, which we use for everything from destinations to line rules, to meta-data - so it was just a case of removing the legacy code...

Reply