How to determine which PDF From submit button a user clicks

[#1]

Hi,



My form has two buttons to trigger form submission, 'Approve' and 'Decline'.

I used to simply check the value of the AWS_ACTION field, but since

upgrading to LiveCycle ES Update 1 (version 8.2.1 with SP1), the AWS_ACTION

field is always NULL.



Has anyone else experienced this? Is there a new way to determine which

button was pressed with the Update 1 release?



Thanks.

[#2]

Your form just requires one submit button. The AWS_ fields are needed if you want to submit the PDF offline or you intend to render it as HTML.

I assume that your workflow has 2 routes, Approve and Decline? If you are rendering the form as a PDF then Workspace will hide the submit button on the form and 2 button are displayed on the Workspace chrome called 'Approve' and 'Decline'. Clicking on one of these button invoke the submit button on the form.

Hope that helps.

[#3]

Yes,



My form has only one submit button, but the workflow has 2 routes.

In the Workbench, I inserted the "Custom -> Process Fields" and

my rendering process uses the "Inject Form Bridge" operation to

prepare the form for use in Workspace.



Prior to upgrading to LiveCycle ES Update 1, the AWS_ACTION field

would contain the name of the button pressed by the user to submit

the Form (i.e., which route they selected). Now that field is always

null.



I need to know in the Form which route the user is selecting so I can

perform the necessary field validation. For example, if they choice

'Decline', I need to ensure they provided a reason why.



As I mentioned, this Form worked perfectly prior to upgrading to

Update 1 (version 8.2.1 with SP1).

[#4]

The AWS_Action field should still be populated with the action (route) that was clicked from WorkSpace.



I just added a app.alert before it submits and I got the right value.



app.alert(AWS_ACTION.rawValue);

FSSUBMIT_.execEvent("click");



Jasmin

[#5]

Hum.



Could my problem be caused by the fact I'm working with a form created

from the previous version of LiveCycle ES? I just tried it on another

from and I get the same problem, app.alert(AWS_ACTION.rawValue) displays

"null".



My LiveCycle version info is:



Version: 8.2.1, GM

Patch Version: SP1

Service Pack Version: 8.2.2287.2.189966.1



I'll try creating a new form and see if I get different behavior.

[#6]

I created a new form and workflow process, and now AWS_ACTION does

contain the name of the Workspace button clicked by the user.



It's seems there's an issue with the forms or processes that I

upgraded from the previous release. Recreating my forms from

scratch is not really an option for me. Any suggestions on

how to get this working?



Thanks.

[#7]

I've narrowed down the problem a little more.



The form that works as expected is using a process variable of type

"Form" and the PDF is submitted as an XDP.



If I change it so the process uses a "Document Form" variable and

submit the PDF as a PDF, the AWS_ACTION field is always null.



In my case, I have to submit as a PDF since I have attachments

(pdf attachments, not Workspace attachments).



Any ideas?



Thanks.

[#8]

You've hit the nail on the head now. Fixes were done in Update 1 to better support digital signatures. The Document Form is the container that routes the signed PDF. As a result we do not make any updates to the PDF when using the Document Form variable (such as the AWS_ACTION field) to prevent breaking any digsig's on the PDF.



Is there a reason why Workspace attachments cannot be used here?

[#9]

I am running into the same problem. I am doing form validation on submit, but the user has the option to Cancel. They would find it annoying to be prompted for validation when clicking Cancel.

[#10]

You can make the input variable xfaForm and creating a custom submit that uses processFormSubmission to create the XML Form to launch the process. I do not know how the get the attachments over to the main process though as there are a limited number of variables to use.



I may end up looping through the attachments in the form script, Base64 encoding them and inserting into the form data so I can submit as XDP. I would then strip out in the map for use in the next render.