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

Locking Issues - Part 2

System

So I've added the lock="t" to my Group tasks, and now after someone tries to take ownership, it hangs saying "Trying to obtain lock" but doesn't actually get the lock.

I've found a thread here mentioning that this is a bug:
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=DOWNLOADS_WORKFLOWS&Number=7694&page=&view=&sb=&o=&vc=1#Post7694

Any idea as to whether this has been fixed or if there is a workaround? I've tried adding unlock tasks before the group tasks, but it still doesn't work.

TIA,
Ronnie

Find more posts tagged with

Comments

Migrateduser

I don't know anything about the bug but I think you can set up a trigger on take ownership action that runs a script that runs iwunlock/iwlock on the files associated with the task if the task is not readonly.

Migrateduser

Your answer is exactly the question I asked yesterday. How would you kick off another lock/unlock task automatically (trigger as you say) on the take ownership action?

Migrateduser

It wouldn't be an ExternalTask, it would be an arbitrary script that is configured as a trigger. You would have to check the admin guide to see how to configure it - I try not to use them because of potential performance issues. The event (key to trigger on) would be TaskGroupTaken. If you look in iwevents.log you will see something like this:

[Thu Mar 20 08:57:35 2003] SYSTEM master TaskGroupTaken WorkflowName 0x3665 TaskName 0x3668 DOMAIN\YourMama

That's how you know which key to use (maybe the hex numbers are the job and task ID). If the command line parameters passed to the triggered script are not documented, your script could temporarily log them to a file so you can identify which one is the task ID. Then have the script use the modules to get the files and workarea associated with that task, unlock them and relock them to the specified user.

Gosh, maybe that should be the default behaviour of TeamSite...

Migrateduser

So shouldn't the lock="t" option in the Group task do exactly what you are describing here automatically? How is your trigger different than what is supposedly built into the group task?

Edited by Lerxst on 03/20/03 09:47 AM (server time).

Migrateduser

This is a workaround you could use for the TeamSite bug (I thought the whole issue was that there was a bug when the task was trying to take ownership).