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

tt_data showing strange behaviour

cheeku

I have used tt_data command in avalable_templates.cfg . It shows a starnge pattern. At times it initiates the workflow at the click of 'Save & Close', while at other not. I am using teamsite version 5.5.2. Could anybody suggest what can be the problem?

Find more posts tagged with

Comments

Jeremy

Could the DCR already be in a workflow when you click Save & Close? I think tt_data would not kick off a workflow if that DCR was already in a workflow.

Could that be the problem?

cheeku

Yes, you were correct.Thanks for spotting the problem.

This problem has arisen because the file was not locked. I tried locking the file using the 'lock=t' attribute in wft. But many a time the workflow hangs showing the status 'Trying to lock files'

Do I have to set lock=t only once in a worflow..i.e . in one(first) task only (until and unless i want to unlock it in a task) or I have to include lock=t in every task in which i want the files to stay locked?

Jeremy

Not too sure about the lock=t bit. I know we have had many problems with that as you have also seen.
I remember on past projects when that was a problem we had specific lock and unlock external tasks.

Maybe someone else will be able to chip in regarding the locking part....

Adam Stoller

Workflow can create locks on files that are currently unlocked and can transition locks that were created within the workflow previously. If the workflow attempts to transition a lock (with lock="t") for a file that was locked *outside* the context of the workflow - you will get the "hanging" problem that you've seen. This can generally be cleared up administratively by unlocking the file and then waiting 1-2 minutes (literally, 60-120 seconds) for the workflow to then figure out that it can now assign a lock to the file.

The other way of handling this within the workflow context is to use explicit locktask's which have both 'success' and 'failure' transitions and/or to use an externaltask running IWHOME/local/bin/unlock.ipl either before a task with lock="t" or as part of a locktask's failure transition.

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