error when calling WF...

anyone has any idea how to overcome this error (see attached). I had wanted the WF to be able to execute with the user only having to be Author role. But it seems that the account requires both Author & Editor roles to execute the WF, which I do not want...

Find more posts tagged with

Comments

Adam Stoller

The current official status is that workflows can only be initiated by Authors if they are initiated by Submit or the closing of an Edit DCR window.

Anything that you find or do to enable to Authors to initiate a job via New Job is NOT supported and may fail to work when patches / service packs / or upgrades are performed.

This MIGHT change in the future - but this is the current situation.

--fish
(Interwoven Senior Technical Consultant)

andrew_yeo

actually, this WF is initiated via the "SUBMIT" button. But it seems that it will work only if the user acct belongs to both author & editor roles and not for author-only role acct.

even when i explicitly hardcode the 'task_owner' & 'creator' to an admin acct (author,editor & admin)... it still gives the same error...

Adam Stoller

Can you describe in more detail how it doesn't work if the person invoking it through the Submit button is only an Author?

At what point in the workflow does it fail?
What are the symptoms of the failure?

I have a hunch about what the problem is, but I'd rather know what you are running into rather than go completely into left-field with a detailed response

--fish
(Interwoven Senior Technical Consultant)

andrew_yeo

if i use "author" only acct, i will most certainly get this error message "Permission Denied.." (see attachment). Hence, the WF doesn't get executed. It will show-up in the To-Do Lists but when you do a "Start Task" then "Submit" it fails again (same error as above).
My WF contains an external cmd to run OpenDeploy XML...

streamstudio.zip

Adam Stoller

My hunch was correct. One way or another the owner of the submittask is an Author - and Author's cannot perform submit operations to staging.

Who owns the workarea in which the workflow is being instantiated? Is it an Author or an Editor?

Through some unfortunate lapses in design, it has been possible to make Author's owners of workareas (documentation states they should be Editors or above but the software doesn't enforce that) - but the submit workflows tend to assume Editor or higher as they use the implied form variable iw_areaowner as the owner of the actual submittask - or you wrote your own and used 'iw_user' - which is the person who initiated the job, and they're an Author.

The choice is either to make sure your workarea owners are Editor or above - or - "proxy" the submittask to be owned by "someone" who is definitely an Editor or above (e.g. "Administrator" or "root").

--fish
(Interwoven Senior Technical Consultant)

andrew_yeo

Based your last suggested workaround, that will work. But it also means that the tasked owner needs to logon to TeamSite to "approve" the task.

In this case, I was hoping that the author can somehow initiate the WF and have it complete, 'cos there's really no task required by anybody in this WF. The author calls the WF and the external task cmd takes care of the rest (i.e. submit the job).
Why am i doing this? Economically, am Author license costs less than that of an Editor. Also, with user begining at Author, they are less likely to make mistakes and it's easier to get them accustomed to having a WF than giving them the option to "Direct Submit". It's got to do with the whole publishing process which is still in its infant stage...

Adam Stoller

While I cannot advocate skimping costs and circumventing the system in so doing, proxying the submittask will achieve the result you are looking for.

However, I think the process you are implementing is short-sighted. The reason for reviews is to prevent both stupid mistakes, and malicious modifications - by providing that anything that goes onto your website has had a least two sets of eyes look at it first (the original content contributor, and someone else).

The other alternative is to have the Author who initiates the workflow, select an Editor (or higher) to perform the review and own the submittask, during the instantiation process.

The requirement in this alternative is that you (a) don't use iw_areaowner to own the reive and submittask, (b) you either make sure that the editors have appropriate access to the Author's workarea [group for sharing] *or* you need to go through the process of using updatetasks to transfer the file into the "reviewer's" workarea and have it submitted from there - after it's submitted, you'd probably want another updatetask to copy the submitted file back from the staging area into the Author's workarea [though you'd have to test that the Author can own that task - not sure]

--fish
(Interwoven Senior Technical Consultant)

logs.zip