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

New Fom within workflow

System

Hi,

When I create a new DCR from within a workflow task by clicking "New Form" link, is there any way to know what Job Id the new DCR is being attached to? The challange is, "on init" of the DCR I have to fill its content by pulling in information from the Job it is being attached to. The DCR is not yet saved at that point of time and I am not sure if the job has any information about the document at that time. I guess not.

I did kind of a workaround and provided a text field in the DCR where user can enter the job id and on change of that field I am using Form API to pull in information from the Job. But the users want automatic population avoiding that manual step of entering job id in between.

Appreciate if any body could throw some idea how to accomplish this.

Thanks

-PB

Find more posts tagged with

Comments

Adam Stoller

Depending on your needs, perhaps this would do:
1. Use FormAPI to hide the field in question if it has no value.
2. In the workflow, have an externaltask script verify that all DCRs [of a specific type?] that are attached to the job have this information added to the content of the DCR (TeamSite::XMLnode).

I'm not sure I'd call it "elegant" but I think it could accomplish what you want without the users having to worry about it.

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

Migrateduser

Thanks much for the reply.

The question is when I open a "newform" the document doesn't get attached to the task. So how my external script will be able to get an handle to the DCR?
But what I feel there must be some underlying protocol between the form newly created and the job. Otherwise how the DCR gets automatically attached to the task on save. What I am not sure whether there is any exposed interface or CLT to get the same information.

Appreciate if you can shed some light on this.

-PB

Adam Stoller

Are you creating the DCR within the workflow, or initiating the workflow after saving and closing the DCR?

My guess is that TeamSite, internally, traps the createFSE or Save/Close operation and uses that information to add the file (e.g. iwaddtaskfile or more likely, the CSSDK equivalent) to the workflow (either one that is getting initiated, or one that already exists). I don't think there's any [easy / supported] way to tap into that for your own customizations. (Brinko or someone else from IWOV Engineering can feel free to correct me here).

In either case however, you can place an externaltask in your workflow to insert the job-related information into the DCR before it gets submitted.

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

Migrateduser

Thanks again.

It is not only the question of saving Job information to DCR, but DCR fields themselves get populated with all kinds of information stored in Job variable when the new DCR opens up (New Form). And user (author) then edits those information before saving the DCR. So the external task is not good enough here.

In DCR document there is a form called "dataform" and that form has got a hidden field called "taskid". This field does store taskid information. Wondering if there is any way to capture the value of this field from FromAPI javascript.

Kindly let me know if you have any idea.

-PB

Adam Stoller

Let me ask the question another way then.
Are you creating the DCR, programmatically, within the workflow, or are you attempting to interact with a yet-to-be-created DCR within a workflow.

The first case is trivial - if you create the shell of the DCR programmatically within the workflow, you can insert all kinds of data into the shell before the user has had a chance to edit it - i.e. prepopulating fields.

If it's the latter, or any other situation in which you did not programmatically create / pre-create / have pre-selected, the DCR within the workflow - I don't think there's any way to associate the job to the DCR when it's being created. The Edit DCR window is, I believe, completely unaware of being used within a job context. The only point at which it comes into play is when you save / close the Edit DCR window - because at that time it needs to determine whether it's going to initiate a tt_data job - and it won't do that if it is already within a workflow context. Unfortunately, I think that detection is done too late (for you) and in a manner which cannot be manipulated (by you) - though I'm more than willing to be proven wrong.

You could try using FormAPI to display every single form / cookie / environment variable it can get it's hands on to see if anything looks like a jobid or taskid (assuming you do this from within a workflow context) - perhaps someone else here can suggest the code to do this (I don't know what it is) - if you can get a handle on the taskid, you can do a CallServer(), pass the taskid in as a parameter, and have your server-side script extract information out of the task / job and insert it into fields within the DCR (*asynchronously*).

But all of this starts getting very abstract at this point, and starts to look exceedingly hackish. I tend to prefer the strategy where you *only* create DCRs from within a workflow context and have the workflow prompt for information about DCR type / name / location and then create a "shell" of the DCR for the user to then edit. Doing it this way buys you all sorts of control over the process - including being able to insert task / job information into the DCR shell before the user has a chance to edit it.

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

JonathonG

One possibility (and read ghoti's posts above about more robust ideas) is that the taskid or jobid is being passed to the datacapture via a query-string variable. I have some vague recollection of seeing it there. To test, place an alert with the 'location' attribute of the parent window into your FormAPI. Then, check the query string. Of course, even if this proves fruitful, it will be a completely unsupported way and may/will break in future releases of TeamSite.

Jonathon
Independent Interwoven Contractor