Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
6.1 Workflow Permissions
Jeremy
Hi,
I am in the process of doing some testing to upgrade our 5.5.2 Win2K system to 6.1 Win2K.
I have set up the branches with the correct permissions as on the current system.
So we'll have a User A who has access to the config branch and the content branch and then a User B who only has access to the content branch.
Now I come to test the Workflows to see if they are running. Part of the workflow instantiation form is to read files from the config branch. This configuration branch has permissions set for only User A to access.
I run the workflow as User A and it populates the Instantiation Form as required with the corect values. This is good.
I then log in as User B who does not have access to the config branch, but the user is a Master. I try to run the workflow but the fields in the instantiation form are not populated.
After much debuging it seems that this is down to a permissions problem.
I tried logging into the local machine as User B and ran the following script:
#!C:/iw-home/iw-perl/bin/iwperl.exe
print "Starting\n";
$iw_workarea = 'Y:/default/main/mywyeth_emea_global/STAGING/WORKFLOWCONFIG/mywyeth_uk/uk_template_map.cfg';
open MINE, $iw_workarea or $temp = "could not open : $!\n";
while ( <MINE> )
{
print "$_";
}
print "$temp :: end $iw_workarea";
This returns on the command line the following result :
C:\iw-home\local\bin>debug.ipl
Starting
could not open : Permission denied :: end Y:/default/main/mywyeth_emea_global/STAGING/WORKFLOWCONFIG/mywyeth_uk/uk_template_map.cfg
However this same script runs perfectly when logged in as User A.
Does anyone know if Workflow now runs as the User starting the job? This worked fine with no problems on 5.5.2 SP6.
If you can give me a RTFM it would be great too.
Thanks,
Jeremy
Find more posts tagged with
Comments
Jeremy
Ok so I have created a very simple workflow - just a simple workflow that moves files around (I know it works) since this part is really irrelevant.
In the begining part of the WF I put in some code that would open a config file, read it and write it to a log file.
This works fine on 5.5.2 but will not work on 6.1 saying "Permission Denied".
It really does look like the way this works has changed.
Anyone know of any work around for now?
Thanks.
Adam Stoller
Is this code within the WFT itself - or code within an externaltask or cgitask script?
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Jeremy
The code is within the workflow.
I have attached the workflow here.
Only concerned part is lines 36 -44.
Thanks.
Adam Stoller
Hmm - interesting. This could indeed have been a change; and while it sounds like a reasonable way for the workflow to function - if it changed it should have been documented and probably should have been done in a backwards-compatible or optional-backwards-compatible manner.
As for what you could possibly do to alter this - try first changing the 'creator' attribute in the <workflow> element to be a user known to have access to that file and see if that works. If not, change that back but change the 'owner' attribute and see if that works.
Regardless though, you should probably open a case with Support to get an official response regarding this apparent change.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Jeremy
Ok. Thanks for the help Ghoti.
I'll get onto support and see what they have to say.
Jeremy
Latest news on this:
I have opened a case but have been told that this "was" a bug but is now fixed.
I got told "If it worked before probably was a bug that got fixed. ".
Now this is not helpful to me. Does anyone know of any workarounds for this?
Options I have thought of are trying to read the file as a different user. Something like "sudo" on Unix. Any ideas on whether this is possible in Windows?
The other option is that we'll have to move our Config files to another location - maybe a deploy to somewhere in <iw-home> so that any user can read these files.
Any thoughts or other ideas?
Thanks,
Jeremy
Jeremy
I have found a possible work around for this now - in case anyone else is also reading config files in the Workflow from a Branch the actual user does not have permissions on.
After much searching I have found a possible workaround. Unfortunately this will involve some changes to both the code as well as File System permissions. What I did was change the workflows in question to look to read the file in the WORKAREA rather than in the STAGING area. This meant I could then adjust the permissions on these configuration files. I then browsed in the File System and changed the permissions on the files to include the “Everyone” group with “Read” permissions.
Again, this is not an ideal situation but at the moment it looks like one of the only solutions, apart from using OpenDeploy to send the config files to another location where all users can read them.
Just thought I would update this in case anyone else has this problem.
Jeremy