Button Behaviors
All forms have buttons that allow submission and routing of the form. Behind each button is behavior that helps with the manipulation of the form. Each button behavior also transfers signature information into the signature table and sends notifications as needed.
Forms submitted to UTS create tickets which are pre-assigned to a user or team.
For forms that create footprints ticket:
The following fields need to be included at the end of the message box of the Notify object for the ticket to be created.
Submitter = Email Field (ex. txthiddenEmail)
Contact = Email Field (ex. txthiddenEmail)
Categories = Department Applications
Level 2= File Transfer
Type = Task
This can be done both on the Submit button or the Approve button. Depending on the form – a supervisor may be able to fill out a form on behalf of a student/employee and submit it directly to uts or the form can be submitted to the supervisor that will then approve and route the form to uts.
Under the ‘Button is pressed’ behavior – the Notify object when opened shows the notification message to be sent.
The fields for the footprints ticket would be at the end of this message as shown below.
Depending on the kind of form created, a form can be initiated by a student. However, a form cannot be routed to a student.
Before submitting a form it, we need to know if, it is submitted by the student or staff. This information is captured from LDAP. Both the primary and secondary affiliations.
The first step in verification is to capture who the form is being routed to. This ‘Oakland Email for routing’ email is used to get information about the person’s affiliation. There are two conditions one, students are not allowed to route the form. Second, on some forms - a submitter is not allowed to route forms to themselves.
The following branch behavior checks if the person who the form is being routed to is not a student. If the person is identified as a student, the submission is canceled and a popup message is displayed.
processhiddnaffiliation is set equal to “student” and hiddenAffiliation is set equal to <empty>
If it is a student, then cancel the submission and show message should be - “The email you have provided cannot be processed. Use the Check Email button to verify the email is associated with a valid OU employee.” Then show other message saying “This Route to email you have provided may be a student account. This form does not allow for routing to students.”
The following branch behavior checks to see if the user is routing the form to themselves. If the routing email and submitter email is same then the error is shown if it is different than it moves to the next step. Use the Simple branch, In the properties go to the Advanced then chose the txtRouteTo equal to txtSubmitterEmail.
Show message should have “Sorry! The forms cannot be routed to yourself. Please provide a valid Oakland University email address.”If the User is not submitted the form to themselves In the Connect property, a connection will be set to ldap.oakland.edu (7) and Action will be set to GetDirectoryDataFromEmail. In Send Parameters, eMail is set to txtRouteTo. In the Return parameters, PrimaryAffilation, Affiliation, and FullName is set to the following targets relatively. Processhiddenaffilation, hiddenaffilation, hiddenEmailName.
Forms can only be approved by the supervisor or UTS. To make sure the forms are Approved only once to UTS. Following behavior is implemented.
Set Field behavior includes the following commands. In the simple branch, the txtUTS field is compared with the [email protected] email. If the UTS email matches. Then condition becomes true and in the set Field box, txtUTS is incremented with +1. Then it goes to simple branch with checks if the txtUTS is more than one. If it is more than one then it shows the error message. “You cannot route this form more than once to UTS.” if it is less than or equal to one then behavior moves to connect.
The next step is now to copy all the fields to the signature table – this happens for all the buttons.
Following fields are copied. 8 field are copied if the user has input comments that need to be transferred to the signature table.
Forms also can be viewed in the user's INBOX. The INBOX can be accessed from the forms menu (https://forms.oakland.edu) tab EForms Inbox. The following shows what an approval connection may look like.
DBTEST Connections
Once the DBTest Connections is made. All the other hidden fields should be cleared. Then copy fields can be used to copy the comments to hidden Comments and then clear the txtcomments.
Before doing a Submit Data. Show message box should be added, because if it is not added the signature page will be cleared on the submission.
Everything will remain same except changes in the notification message. The {field name} form was forwarded to you. Additionally. If required that form cannot be forwarded more than once to uts. Then the following behavior can be added.
Here first with simple branch it is checked that [email protected] = txtroute - if it does then set field is used increment the field number. In the next simple branch, it is compared with the txtUTS. To check If txtUTS is greater the 1 or not. If it is more than once then we can show the message “You cannot route this form more than once to UTS.” If it is less than 1, then use the connect to move forward to other behaviors.
Similar to approve button. Just change is the notification message. The {field name="txtemailnotification”} form has been disapproved.
Add set Field Where cbLock is set to ‘checked’. Also, Add copy Fields where following fields are copied.
In the unlock button, a simple branch will be needed to find if txthiddenuserId = txtpersonwholocked. If it is not a same then show the Message “Sorry, you cannot unlock the form since you don't have privileges”, clear the txtpersonwholocked, and set cbLock to checked.
