DCR Form won't instantiate workflow

There is/was an existing bug where the finish button would not kick off a WFM model from tt_data. I do not remember the specifics, but it was something like if there was an entry in available_templates.cfg (albeit a different one) then it would work.

Faizi

Andy is correct, tt_data has problem with WFM.

I also found that in OOTB example of 'Faq Entry'. In datacapture.dct file, submission of dcr handled by FormAPI using handleOnSaveDone() event.

You can check it in below code:


/**
* OnSaveDone handler.
*/
function handleOnSaveDone(obj)
{
 var ret = lsContext.handleOnSaveDone(obj);
 var whichUi = ( top.document.location.href.toLowerCase().indexOf('ccstd') > -1 ) ? 'ccstd' : 'ccpro';
 if( whichUi != 'ccstd' && ret && confirm('Would you like to publish this form entry?') )
 {
  var form = document.createElement('form');
  HtmlUtil.setFormAttribute(form, 'action','/iw-cc/command/iw.ccpro.submit');
  HtmlUtil.setFormAttribute(form, 'method', 'POST');
  HtmlUtil.setFormAttribute(form, 'target', top.name);
  var input = HtmlUtil.createNamedElement('input','vpath',document);
  input.type = 'hidden';
  input.value = IWDatacapture.getDCRPath();
  form.appendChild(input);
  document.body.appendChild(form);
  form.submit();
  ret = false;
 }
 return ret;
}

For more detail you may go through the SitePublisher Developer's guide.

Thanks

RatingChart.zip

There is/was an existing bug where the finish button would not kick off a WFM model from tt_data. I do not remember the specifics, but it was something like if there was an entry in available_templates.cfg (albeit a different one) then it would work.

Do you mean if there was an entry in available_templates,cfg that was just some workflow that would kick off on tt_data (for that same branch/role/group then that would make both of the workflows appear in the list? So there's possibly no way for a single WFM workflow to be available for DCR forms upon Finish? Ugh.

Problem is, that WFT workflow would be a dummy workflow - not one we would want anyone to choose. So short of naming the dummy workflow "This is a dummy workflow - don't choose it", is there a way to make that workflow hidden on the list? I am not in the office right now, so I'll play with this once I get there.

I found the Article (#58570) that talks about this Bug (#69324). It was supposed to have been fixed in TS 6.7.1 SP1, but we are running 6.7.2, so I don't know if maybe it wasn't fixed or I have some configuration messed up.

I opened up a new support case so I'll see what they say.

I found the Article (#58570) that talks about this Bug (#69324). It was supposed to have been fixed in TS 6.7.1 SP1, but we are running 6.7.2, so I don't know if maybe it wasn't fixed or I have some configuration messed up.

I opened up a new support case so I'll see what they say.

I know it would be a total shock for a bug to come back. That *never* happens at IWOV.

anisha

I found the Article (#58570) that talks about this Bug (#69324). It was supposed to have been fixed in TS 6.7.1 SP1, but we are running 6.7.2, so I don't know if maybe it wasn't fixed or I have some configuration messed up.

I opened up a new support case so I'll see what they say.

Do you have the following specified in applicaton_custom.xml?

< application id="ccpro">
< param id="ccpro-use-tt-data" value="true">
< /param>
< /application>

Do you have the following specified in applicaton_custom.xml?

< application id="ccpro">
< param id="ccpro-use-tt-data" value="true">
< /param>
< /application>

No I don't have that. Do I need that? Why?

No I don't have that. Do I need that? Why?

I suggest you spend a bit more time reading the manuals, getting training, or hiring someone who already knows what they're doing.

I just *had* to post that.

I suggest you spend a bit more time reading the manuals, getting training, or hiring someone who already knows what they're doing.

I just *had* to post that.

If I wasn't flailing so bad about this I would take it like a man, but right now all I want to do is cry.

Seriously...is this important? It seems like it might be important. I am looking at the customization guide as we speak. What is curious about this is that it does allow me to start a workflow in CCPro as long as there are enough workflows available for that particular area. It only seems to misbehave when there is only one workflow and that workflow is a WFM workflow. So it's not like it's restricting me from starting a workflow at all, so that's why I'm curious about this particular piece of advice.

What I'm trying to say (very poorly up above) is that it seems like the default value for that flag "ccpro-use-tt-data" is probably "true" because if it was not, we would never get the option to push our DCR updates through a workflow. But we do get the option if the conditions are right.

you are right, the default value for tt_data is true.

Did you try the "workaround" that was suggested by IWOV ? That will admittedly suck, but I wonder if it is the same problem.

Also from old posts here, it appeared you needed to have just 1 WF defined to use tt_data in available_templates.cfg. Can you try that ?

Andy

Did you try the "workaround" that was suggested by IWOV ? That will admittedly suck, but I wonder if it is the same problem.

Andy

The workaround is just as unacceptable. From what I read it is telling us to just open up all workflows for availability. Having a bunch of workflows to choose from that they shouldn't be using is worse than having one extra workflow they shouldn't be choosing.

how about the fix in this thread

how about the fix in this thread

I think that's what we have in place right now. I have a WFT workflow enabled for tt_data in available_templates.cfg, and that allows that workflow plus my WFM workflow to show up as options for the user to choose after they finish editing their DCR. However the WFT workflow is useless and I don't want it to appear. This is what we have in place now, just so the users can proceed. However it is not an acceptable long term solution. Another downside to this approach is that it shows the WFT workflow as the first option, so that's the default option (its radio button is selected). I did name the WFT workflow "DO NOT Choose This Workflow" but you know someone will choose it just to be a PITA.

I do not think it has to be active for your branch for the workaround to work. Limit it to a non-existent branch and see if it still works.

Tried and failed. If I define the WFT workflow for only a different area, then the DCR wizard disappears after saving the file. Same behavior. That would have been sweet if it worked, though.

Adam Stoller

[/html]

Do you have the following specified in applicaton_custom.xml?[html]

No I don't have that. Do I need that? Why?
From the 671SP1 UICG (some emphasis added):[indent]Enabling Prompting after Modifying Forms (use tt-data) in ContentCenter Professional[indent]The default behavior in ContentCenter Professional after users create or modify a form is to not associate the modified form with a workflow, even if such workflows (tt-data workflows) are configured in available_templates.cfg and the user has access to them. To alter this behavior so that users, after creating or modifying a form, are prompted to associate it with a workflow (provided one is configured and they can access it in their current role), edit

application_custom.xml

:[html]

[/html][/indent][/indent]I suggest you make the above configuration setting, run make_toolkit.ipl (successfully) and then see if your problem persists.

I made the update to application_custom.xml as you suggested, but the behavior is the same. Unless I have the WFT workflow configured to appear as well as the WFM workflow, the DCR wizard just disappears after saving the file.

Someone from support is supposed to be looking at my case, so we'll see if they are able to help me.

From the 671SP1 UICG (some emphasis added):[indent]Enabling Prompting after Modifying Forms (use tt-data) in ContentCenter Professional[indent]The default behavior in ContentCenter Professional after users create or modify a form is to not associate the modified form with a workflow, even if such workflows (tt-data workflows) are configured in available_templates.cfg and the user has access to them. To alter this behavior so that users, after creating or modifying a form, are prompted to associate it with a workflow (provided one is configured and they can access it in their current role), edit
application_custom.xml
:[/indent][/indent]I suggest you make the above configuration setting, run make_toolkit.ipl (successfully) and then see if your problem persists.

interesting.... i dont have that enabled in application_custom.xml, but DCRs have been showing the option to associate them with a workflow since i installed patch 6 on 671 sp1. ( so i assumed it is enabled by default).

also i commented out everything in available_templates.cfg since we are just using wfm based wfs, and all our workflows are still working with tt_data.

interesting.... i dont have that enabled in application_custom.xml, but DCRs have been showing the option to associate them with a workflow since i installed patch 6 on 671 sp1. ( so i assumed it is enabled by default).

also i commented out everything in available_templates.cfg since we are just using wfm based wfs, and all our workflows are still working with tt_data.

I assume you have more than one WFM workflow available for your DCR forms, though? If you were to only enable one WFM workflow for a particular DCR, would you still get the option to Submit Now via workflow? Are you still on 6.7.1? We are on 6.7.2 so maybe something went backwards in 6.7.2....

Yeah i am TS 671 SP1 Patch 6.

i just tested, yes i had to have at least one workflow open for the workarea (/default/main/branch/WORKAREA/wa.* or /default/main/branch/WORKAREA/.* | /default/main/branch/.* | /default/main/.*). if i have at least one workflow with matching workarea vpath, then i can restrict the rest of workflows all i want. if i dont have that then the option to submit thru tt_data goes away. and you are right, the reason i didnt notice the issue is because we do have one generic submit (version) workflow enabled for the entire branch.

and concerning this:

Another downside to this approach is that it shows the WFT workflow as the first option, so that's the default option (its radio button is selected). I did name the WFT workflow "DO NOT Choose This Workflow" but you know someone will choose it just to be a PITA.

i would say create a workflow that does nothing, or maybe a WF with just an external task that yells at the user who selected it even you told him not Smiley Happy

Hey S

Can you limit the generic WF to master only ? Or a certain user ?