nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Deployment for Authors

tobias

Does anyone know whether I can give certain authors the right and the possibility to deploy files?
As an author can't start a "New Job" he can't invoke a workflow to deploy files.
I've tried to include a custom_menu_item in the iw.cfg's [iwcgi] section but unfortunately this doesn't seem to work either. I created an .pl (resp. .ipl) script which simply invokes the "iwjobc.exe" CLT with the corresponding workflow and placed it in the iw-home/httpd/iw-bin directory. But when I click on the custom menu item I get either an error message like
"TeamSite: Wrapper
Error: Error opening a pipe to c:\iw-home\teamsite\httpd\iw-bin\author_submit_and_deploy.pl (1)"
(if I refer to the .pl version of the script) or
"Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request. ..." (if I use the .ipl version of the script)
Any help or suggestions would be appreciated. Thanks.

Find more posts tagged with

Comments

Adam Stoller

Do you need a workflow? If you just want authors to be able to deploy - you could just have a custom menu CGI script that prompts for (or pulls from form data) the information necessary to launch the OpenDeploy process.

If you are using OpenDeploy 5.x you could have them login to the OpenDeploy Admin GUI (provided you've set them up as 'users') and have them launch deployments from there.

If you want a workflow - presumably there should be some review performed of the work before it is deployed - in which case, a submit workflow -- which *can* be launched by an Author - would make sense, have it get reviewed by the area owner (who should be an Editor or higher) and after that, run either an externaltask or cgitask to launch the deployment.

--fish
(Interwoven, Curriculum Development)

tobias

Hello fish,
thanks for the suggestions.
In fact, we'd like some authors (who are sure what they're doing) to deploy the files directly without any further review by an editor.
Meanwhile we've been able to create a custom_menu_item that starts a submit and deploy workflow for the current user (even if he is author). However, this custom menu item is visible only in WebdeskPro, not in Webdesk.
Where would I find custom menu items in Webdesk? Or could it be a problem, that WebdeskPro is in English, but Webdesk comes in German? (Because the "MenuName" parameter that has to be addressed in iw.cfg's [iwcgi] section would be either "File" [for English WebdeskPro] or "Datei" for German Webdesk)
Here's the custom_menu_item entry:
custom_menu_item_newjob="File", "Submit and Deploy", "author_submit_and_deploy.ipl", "all", "scrollbars=yes,resizable=yes,width=640,height=545", "Submit and Deploy", "500"
Any suggestions?

Tobias

Adam Stoller

Try removing the second instance of "Submit and Deploy" in your custom menu item entry - but leave the comma. So it ends with ....height=545", , "500"
Then do an iwreset (no flags) and a Refresh in the GUI - and see if that works.
I cannot remember what that second-to-last parameter for the custom menu item is supposed to be, but in all the examples I've seen and/or where I've used it - it's always been blank.

--fish
(Interwoven, Curriculum Development)

gsumers22texas

I've seen the following used:
the following command entry put within an externaltask-
the $extcmd variable was built within a Perl script, that populated all the parameters of the iwdeploy CLT and passed it to the wft

<command v='__INSERT__($extcmd{"deploy"});'/>

Screenshot - 21.12.2010 , 13_30_03.png

tobias

Removing the next to last parameter doesn't help :-( I've opened a support case about this.

Another thing I noticed just now:
A user that can login to WebdeskPro with either of the roles "Author" or "Master" can start this workflow by invoking the custom_menu_item (clicking on "File" -> "Submit and Deploy" in this case), no matter whether he's logged in with the "Author" or "Master" role.
However, if I remove the "Master" role for this user, he can't start the workflow. In this case an error message is generated:
"ERROR: User ecu\gildet cannot submit files in workarea \default\main\hamburg\ros
i\WORKAREA\work in task Submit."
I've also tried to give the "Authors" the right to submit files by setting
"submit_direct=master,administrator,editor,author"
in the iw.cfg file, but this doesn't improve anything.
Any ideas?

Adam Stoller

TeamSite operations will tend to use the highest level of authority (role) the user has regardless of which role they are logged in under - as you discovered.

At this point in time - Authors have *no* access to the staging area within TeamSite - and thus cannot submit as authors.

If you look at the author_submit.wft you'll see that the submittask is actually owned by the iw_areaowner not the iw_user - this is one of the reasons you should never make an author-only user the owner of a workarea. You could create a variant of the author_submit.wft that does the same thing *without* the review (I'm not saying I recommend this - but you can certainly do it) - and thus the Author will be able to use an Editor-or-higher as a "proxy" for submitting files.

--fish
(Interwoven, Curriculum Development)

tobias

I finally found a way (and I have to admit that I should have found it earlier):
In the available_templates.cfg file you can specify which workflow shall be invoked when a user clicks on the "Submit" button (and, what's more important: you can specify which role and/or user this workflow shall be associated to). I simply created a "Submit and Deploy" workflow and associated it with those authors who I want to be able to directly submit and deploy files.
In this workflow it is important to specify the __TAG__('iw_areaowner'); as owner of the different tasks (I didn't experiment much, but maybe this owner's only necessary for the submittask) and not the current user's name.
So, if one of these authors marks a file and clicks the "Submit" button, the workflow is started, the user enters a comment and that's it.
Thanks for your help and suggestions.

Harsh

I have a question on using area owner as the owner of submit task in the workflow. What if, for some reason, area owner's account is disabled then how will the workflow function in this scenario? Will there be any other issues with the branch(es) owned by this user whose account has been disabled?

Thanks
Harsh
Teamsite 6.1 on Windows....

Dwayne

I don't believe that having the account disabled would impact the functioning of the submittask, with one exception: if there are conflicts with the submit, then the submittask goes into a special conflict state, when it essentially resembles a usertask. The owner of that task needs to log in to TeamSite and resolve the conflict.

Obviously, if the account is disabled, it won't be possible to log in with that account. You'd probably have to manually take ownership of the task at that point, to resolve the conflict.

--

Current project: TS 5.5.2/6.1 W2K

Harsh

Thanks for the update. I think I can use an external task to submit files and use iwsubmit -s ..... to skip conflicts as required. OR use skipconflicts = "t" in <submittask>.

Edited by Harsh on 10/06/04 09:16 AM (server time).

Adam Stoller

Use iwidmap to switch the userid associated with the UID to someone who *is* still a legitimate editor-or-above user on the system - then use iwstoreadm to deactivate and reactive the store for the iwidmap change to take effect and presto-change-o you should no longer have any problems with regard to a user who no longer exists.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Harsh

I guess this is required everytime area owner login is disabled, right? We just want to avoid this...... thanks for the info. though...