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; } } }

Author unlock of other objects.

nipper

We have a reviewers receive HTML email with a review and edit button for the objects under review. The edit button is just the CCI to edit the file. But since they are authors it does not work.

So my plan is to have a perl script that runs before the edit run iwunlock, but I am not certain if this will work (due to user
permissions).

Anyone try this before ? Tips or pointers welcome.

Andy

Find more posts tagged with

Comments

Johnny

Im assuming you are running a workflow to do this.

You can use the lock flag in a user task, as well as having an external task before hand that unlocks all files in the workflow.

Im pretty sure TS ships with an example script in IWHOME/local/bin

John Cuiuli
Consultant
Sydney, Australia

nipper

That would work if I want to blanket unlock everything, not my first choice.

If I did not have groups approval tasks, then I could unlock the file & then lock it to the approver, but that is not known in the WF only after the task has been taken.

What I need is the ability to unlock when the WF is in the review process and then I know if there are files to unlock

Andy

Migrateduser

I think you can set up a trigger on taketask, parse the command line arguments for the task ID (and check for other properties such as task name if needed), parse the XML from that or use the perl modules, unlock the files and lock them to the user taking ownership (should be one of the parameters to the trigger script).

Adam Stoller

It may sound a bit kludgy - but if you explicitly unlock and then re-lock all the files associated with the workflow - so that they specifically have "workflow" locks - then you should be able to have your grouptask set with the lock="t" attribute which should occur when someone takes ownership of the task. As long as the locks are "workflow" locks - the workflow system should be able to transfer the lock from its present holder to the new owner of the grouptask without any problems.

I'm not sure if calling 'iwlock' on files within an externaltask script will generate a workflow lock or not - if it doesn't - consider doing an externaltask that calls IWHOME/local/bin/unlock.ipl followed by a locktask (owned by the job owner? or "iwui" or "Administrator" ?) followed [eventually] by your grouptask.

--fish
(Interwoven Senior Technical Consultant)

Bowker

NIpper -

If you successfully get this to work, please let me know.

I have not successfully transferred locks with a workflow (Win2K, TS 5.0.2 or TS 5.5.2) from the author to the approver to allow the approver to make changes to the author's work.

Dan Bowker

nipper

Fish,

This sounds interesting but I am not certain I know the difference between a "regular" lock and a workflow lock.

So I should unlock the list of files and then run the lock task within the WF ? Make certain the lock=T on the approval task.

How can one distinguish between a WF lock and a lock assigned by launching edit ?

This does seem much less of a cludge than the other options I know of.

Thanks again

Andy

Adam Stoller

I seem to be battling a head cold right now - so I might not be phrasing myself clearly here... sorry.

A "regular" lock is someting like where the lock description is "File locked by templating" or "File locked by editing" - in contrast, if a file is locked within the context of workflow, and you do a File Properties on it, you'll see it says "Workflow lock".

I just did a bit of checking - and I believe that an externaltask running unlock.ipl followed by a locktask will produce the desired results (I didn't go too far in the testing, but I did verify that using iwlock within an externaltask doesn't seem to have the desired results)

--fish
(Interwoven Senior Technical Consultant)

nipper

I was only partially sucessfull. I just created a job that unlocked the original files (using unlock.ipl).

So now we are walking without the net underneath.

I tried to set the flags to lock with the group task, hoping that would work as fish had thought, but so luck. When one approval task started, it locked the files. My next (3 serial approvers) approval task (who may want to edit it also) failed on the edit.

So I think my design will need to be:
Start -> Unlock -> Approve1 -> unlock -> Approve2 -> unlock -> Approve3 -> End

Andy

Adam Stoller

Did all the approval tasks have lock="t" set on them?
Is the file being edited a DCR? (I think templating locks the file explicitly for templating and not for workflow - haven't verified this though).

If that's the case - yes, sticking an unlock task between the other tasks shoudl work - though as I suggested earlier (I think) - I would have the externaltask running unlock.ipl followed by a locktask, so that the files are locked by workflow while you're waiting for someone in the grouptask to take ownership.

--fish
(Interwoven Senior Technical Consultant)

nipper

>Did all the approval tasks have lock="t" set on them?
>Is the file being edited a DCR?

I did include the lock=T and yes it is a DCR. I also missed the
lock task (assuming the lock=t on the review task would take
care of it, looks like that might not have been a valid assumption.

Thanks

Andy