eForms Approval Template - MITA1 · 2011-12-29 · Unclassified eForms Approval Template 01....

Malta Information Technology Agency, Gattard House, National Road, Blata l-Bajda HMR 9010 Malta Telephone: (+356) 21234710 Facsimile: (+356) 21234701

Web Site: www.mita.gov.mt

eForms Approval Template

Date: <date>

Version: 0.1 Unit: eGov Architecture Department: eGov DEO

Unclassified

Unclassified eForms Approval Template

Page i

Document Control Information

01. Document reference

eForms-TMP-Documentation-v0.1.doc

02. Document type

Procedure

03. Security classification

Unclassified

04. Synopsis

Document brief description

05. Document control

Author Change controller Distribution controller

<Enter Author> <Enter Name> <Enter Position / Department>

<Enter Name and Position or Team>

This document may be viewed and/or downloaded from the IMS On-Line, which maintains the latest issues of all documents and forms.

06. Authorisation

Issuing authority Approval authority

Signature / Date Signature / Date

<Enter Name> <Enter Position / Department>

<Enter Name> <Enter Position / Department>

07. Modification history

Version Date Comments

Draft 0.1 dd/mm/yyyy Draft version for internal review

Version 1.0 dd/mm/yyyy First version for release

08. Acknowledgements

09. References

10. Distribution list

<To be filled as applicable according to the security classification of the document / report>


Table of Contents

DOCUMENT CONTROL INFORMATION .................................................................................................................................. I

TABLE OF CONTENTS.............................................................................................................................................................1

01. INTRODUCTION ..........................................................................................................................................................2

02. SCOPE .........................................................................................................................................................................3

03. DEFINITIONS ...............................................................................................................................................................4

04. APPROVAL FORM.......................................................................................................................................................5

05. NAMING CONVENTIONS ............................................................................................................................................6

06. LAYOUT NEED ............................................................................................................................................................7

06.1 INITIAL PAGES ............................................................................................................................................................7 06.1.1 E-Form Template Features .............................................................................................................................7

06.2 APPROVAL STAGE.......................................................................................................................................................7 06.2.1 Read-Only Fields.............................................................................................................................................7

06.2.1.1 Common page for Vetting, Approval or Committee.......................................................................................................7 06.2.1.2 Payment Details.............................................................................................................................................................9 06.2.1.3 History............................................................................................................................................................................9 06.2.1.4 Submit..........................................................................................................................................................................11

06.2.2 Navigation......................................................................................................................................................12 06.2.3 Menu Structure ..............................................................................................................................................12

06.2.3.1 Form Sections..............................................................................................................................................................12 06.2.3.2 For Office Use..............................................................................................................................................................12

06.2.4 Specific uses of rectangle..............................................................................................................................12 06.2.5 Lightbox .........................................................................................................................................................12

07. REQUIRED HIDDEN FIELDS ....................................................................................................................................13

07.1 MAIN FORM ..............................................................................................................................................................13

08. LOCALISATION..........................................................................................................................................................15

09. ERROR LOGGING .....................................................................................................................................................16

10. INTERACTION WITH MITA COMPONENT ...............................................................................................................17

10.1 COMMON CLASSES....................................................................................................................................................17 10.1.1 Approval.java.................................................................................................................................................17

11. APPLICATION STATUS.............................................................................................................................................18

Populating the Status ......................................................................................................................................................19 11.1.1.1 Declaring it through the form processing.....................................................................................................................19 11.1.1.2 Declaring it on the server-side JavaScript ...................................................................................................................20 11.1.1.3 Declaring it in the process not on the form..................................................................................................................20

12. MITA EXTERNAL JAVASCRIPT ................................................................................................................................22

12.1 AVAILABLE SERVER - SIDE SCRIPTS...........................................................................................................................22 12.1.1 Payment Details ............................................................................................................................................22 12.1.2 History ...........................................................................................................................................................22 12.1.3 Form Title ......................................................................................................................................................23 12.1.4 Populating the Process Status ......................................................................................................................23

13. FURTHER ASSISTANCE...........................................................................................................................................25


01. Introduction

EForms are currently being implemented as part of the eGovernment Services. Each form is to be evaluated after filled in by the applicant. At the evaluation stage the form will be vetted before being approved or rejected. In order to process the forms, a set of form pages have been created meant to be used for office use only. This document highlights the common components and features of these form pages and guides developers on how to use them within a context of creating a form using a standardized Approval Template. These guidelines provide instructions, explanations as well as code snippets.


02. Scope

This document describes the e-Form approval template features. One of these features is the page itself, which consists of an aggregation of form fields, hidden fields, as well as specific buttons, which, in turn, automate a number of other features. Other sections, as specified in the Table of Contents, will also be examined. One important thing to notice is the naming conventions, which are to be tackled according to the template components. Besides the template layout and its components this document will guide the developer throughout the use of the Logger functionality as well as provide a clearer idea of the role localisation plays when template components are constructed. In addition, both as libraries and external JavaScripts will be explained.


03. Definitions

Term Description

Administrator A person responsible for the management of all or part of a service, system or resource according to the level of permissions assigned.

Backend An application used to change web content and configure services.

Branding The specification for layout and design, look and feel, usability and functionality to be followed by every Government of Malta website.

Citizen Any user who is a natural person, including an e-Citizen.

Configuration A set of attributes and parameters required for a service to work.

Criteria A set of values to be used to select a set of data.

CSS Cascading Style Sheets are files that determine the look of HTML websites.

e-Citizen A Maltese National ID card holder who has acquired an e-ID login profile and who may therefore make use of the online eGovernment services.

e-ID The eGovernment electronic logging ID system.

e-Forms The platform used to deliver eServices to the Government of Malta.

e-Mail Electronic mail is a method of exchanging digital messages in text or HTML formats with attachments over a network.

eGov DEO The eGovernment Direction, Execution and Operations Department is responsible for the delivery of government information and services, and interaction, within government entities, with the public, and with other external entities, over electronic means.

eGovernment Electronic Government, usually used in the context of e-Government services, referring to those services which the Government can provide through an electronic medium such as Internet, mobile etc.

GMICT Government of Malta ICT.

Government The Government of Malta.

Government Entities Authorities, Corporations, Agencies and commercial public sector entities in which the Government has a majority shareholding and which are not listed on the stock exchange.

HTML Hypertext Markup Language defines the structure and layout of a web document through the use of tags and attributes.

ICT Information and Communication Technologies.

LiquidOffice Platform provided by Autonomy which caters for the creation of the eForms and process workflows

MITA Malta Information Technology Agency, the Contracting Authority for the purposes of the Public Contracts Regulations.

Parameter A value that can be varied (usually within configuration) to change the behaviour of a service or function.

Parameter Store Data repository for parameters that need to be localized.

Profile The set of details/particulars required by a system for an item.


04. Approval Form

After an eForm is submitted it needs to be approved; verified by an approver of the government’s authority hence ensuring that all the information has been filled in correctly and that all the data required by the form had been attached correctly. Otherwise the application will be rejected or returned to the user. This stage is called the vetting stage and it logically follows the applicant’s application form, which is still available in the approval form for the approver to peruse. This section can be found under the For Office Use form section. In this document, this page will be referred to as the Approval Stage in the template. Please note, however, that this page can be used for other required stages as well.


05. Naming Conventions

Each component within each eForm page is to be named according to naming conventions to enhance uniformity and automation. More details about the naming conventions of the profile fields can be found in the document named Naming Conventions and Considerations for eForms Development. Further details about the naming conventions of the side menu buttons and the previous and next buttons can be found in the e-Forms Application Template document in section 04 Naming Conventions Section.


06. Layout Need

06.1 Initial Pages

The first four pages of the eForm Approval template are the same as the ones which are presented in the application form template presented to the user. More details about the layout characteristics of the eForm template are to be found in the e-Forms Application Template document under section 05 Layout. 06.1.1 E-Form Template Features

Details about the page features of the initial pages of the Approval Template can be found in the e-Forms Application Template document. 06.2 Approval Stage

As mentioned in Section 04, this page in the Approval Template is generic and, hence, can be used to cater for any required back-office stage, such as Vetting, Approval or Committee. The pages which are to be discussed in this section reflect the status of the application. For example if the application has completed the vetting stage then the approval page and its components are to be loaded. If the application is at the approval stage then, once the application is approved, the process status will be updated to reflect the next status, such as Committee. Because of this progression, when the same approval form is opened in the Committee Stage, the Approval page will automatically be loaded with its titles reflecting the new stage, i.e. Committee. 06.2.1 Read-Only Fields

There are a number of fields pertaining to the approval process which must be set to read-only in order not to let the back-office user amend these. These fields are explained further in the following sections. In the examples that follow, please assume a process that has three approval stages; Vetting, Approval and Committee. 06.2.1.1 Common page for Vetting, Approval or Committee

The vetting stage is the first stage of the approval process. At this stage certain read-only fields will be filled in automatically. Please take a look at the figure below to note the fields that are meant to be filled in automatically. The reason why some fields are read-only is due to the fact that certain fields are just needed for information purposes while they must not to be amended. The figure below shows all the read only fields that need to be present within this page. The read-only fields are the following: - Submission Reference

This reference number is an auto-generated number by e-Forms and will be set to the next sequential number available. The value in this field is set when the e-Form is first opened.

- Date Received This field is to hold the date and time when the eForm has reached the most recent stage in the work flow.

- File Reference The value in this field is to be filled by the Vetting Officer or following approval depending on the work flow requirements. Please note that there are three (3) kinds of references which are:

1. Automatically generated after the submission of the form. 2. Inputted during vetting stage


3. Inputted during assessment stage (e.g. to latch on to a licensing system) - Process Status

This is to hold the current process status.

- Form Submitted through This feature is an enhancement which is meant to be implemented in the future.

- Form Submitted on behalf of An applicant can fill in an e-Form on behalf of oneself or on behalf of someone else. This feature is an enhancement which is meant to be implemented in the future.

- Officer The field is to hold the vetting officer’s name. This value is to be auto populated from the currently logged in user’s profile.

- Date The value in this field is to be auto-populated using the current date and time.

Often, apart from approving or rejecting a form, the back-office user would need to insert comments to accompany his actions. For this reason, three comment fields where added to the template; - The Remarks sent to the Applicant - Internal Remarks - Approval conditions. Please note that the “Approval Conditions” text field is not visible when the process is in the Vetting Stage. However, this becomes available when the process enters the Approval Stage.

Comments, at each stage, can be inserted both for internal and external use. Internal comments are comments which are meant to be handled internally and which can consist of personal comments, suspicions, provisos, and so on. These comments are not meant to be sent to the applicant. When an applicant needs to be informed of any decision made, in cases when the form is not accepted because of lack of information, the external comments (Remarks to be sent to Applicant) can be used.


This is done so that the applicant would know whether the application has been approved or the reasons why it had been rejected. These comments will automatically be inserted by the process in the user’s Application Form Comments page. 06.2.1.2 Payment Details

This page displays the payment details of a payment made by the Applicant with regards to the Application in question. This would be required by the back-office users to ascertain that a payment was successfully made. Please note that all of the fields shown in the figure below are set to read-only since they are only to be viewed just for information purposes. They should not be amended. The read-only fields are the following: - Date (of payment) - Amount (paid in €(Euro)) - Transaction Reference - Submission Ref - Payment (Payment can be done using one of two methods)

1. If payment is done through myBills by Card then the read only fields will be the following: • Cardholder Name • Masked Number complaint to PCI DSS (first 6 and last 4 digits will be shown)

2. If payment is done through cheque then the read only fields will be the following:

• Clearing bank name • Cheque number

06.2.1.3 History

This page holds a historic record of all the remarks inserted in this form during any stage of the process. The page is to contain the following fields: - Vetting Internal Remarks


This field is to contain all the remarks (both internal and those shown to the applicant) entered by the back-end users in a chronological order (newest first). Entries will be appended to the previous information with no over-writing.

- Remarks History This field is to contain only the remarks that are available to the applicant in a chronological order (newest first). All this data is to be duplicated as a subset in the Remarks field. Entries will be appended to previous information with no overwriting.

- Approval Remarks sent to the applicant This field is to be shown only at the Approval and the Committee stages. Entries are to be appended to previous information; no over writing and are to be shown in a chronological order (newest first).

Since the History page is used only for recording purposes, the fields in this page should all be set to read-only. The data in each and every field is to be obtained from the data inputted in the three (3) text fields found in section 06.2.1 Vetting Stage. A sample of what data the Vetting Internal Remarks and the Remarks History fields are to hold is shown below: Date Time Stage Back-office user’s name&surname Translated action 28/09/2011, 10.28am, At Vetting, Lindsay Sultana, Approved Comments:

“Approval with the following conditions: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum semper est id enim dapibus euismod. Ut nulla sapien, laoreet sed rhoncus et, imperdiet vitae libero. Mauris non urna neque. Nam luctus mauris et diam posuere tristique. Suspendisse nunc metus, hendrerit eget interdum vitae, varius a nunc. Proin a malesuada


A sample of what data the Approval Remarks sent to Applicant field is to hold is shown below. Please note that the text in green is just to help in the readability of the document. The headings are not to be shown in the e-Form

Date Time Stage Back-office user’s name&surname Translated action 28/09/2011, 10.28am, At Vetting, Lindsay Sultana, Approved

Comments:

“Approval Conditions are the following:

App 1

App 2”

06.2.1.4 Submit

This is the final section of the vetting stage. In this section the amount in Euro to be paid by the applicant is deciphered while the final decision whether the application is to be approved or not is finally taken. The approver is to choose the result of the vetting process using the drop down list found below. Please note that the options in the drop down list are to be controlled according to the stage of the process. The Total Amount Due in the Submit page should display the total amount which the Applicant should have paid/ will pay for the application. This is different from the payment field on the Payment page as it displays the amount that should be paid whereas the payment field displays the amount which was paid in the last payment made. These two amounts may not be the same since there may be instances where a payment may be made after an application has been approved rather than before.


06.2.2 Navigation

Each and every form is to be set to paged rather than continuous. Navigation through these pages can be carried out in two ways. More details about how the navigation between pages is to be implemented can be found in the e-Forms Application Template document under section 05.2 Page Layout. 06.2.3 Menu Structure

06.2.3.1 Form Sections

Navigation through this eForm can be performed using the Menu Buttons found on the left-hand side Menu of each form named Form Sections (the menu is shown on the right). More details including code snippets about the Menu Structure can be found in the e-Forms Application Template document under section 05.2 Page Layout. 06.2.3.2 For Office Use

A thing to be noted is the fact that the Help section is not present when the Form Section named For Office use is to be selected. Instead the user is to be presented by another menu named For Office Use which is meant to handle all the different stages of the approval. As shown on the menu on the left, the stages differ from the For Office Use to the Submit. Please note that when the “For Office Use” button is clicked, the button on each of the side menus is highlighted to respect the naming convention. The button on the right menu has the the following naming convention: btnBoMenuPg<current page><field name>

In the case of the “For Office Use” buttons situated on the approval page, the button on the left menu is called btnMenuPg5OfficeUse while the button on the right menu is called btnBoMenuPg5OfficeUse. 06.2.4 Specific uses of rectangle

Details about how the rectangle is being used within the e-Form Template can be found in the eForm Application Template document under section 05.5 Specific Use of Rectangle. Please note that there are two scenarios mentioned when the rectangle is to be used i.e. the Help section as well as the Form Section Menu. In this template i.e. the approval template the Help section is not to be displayed since another menu (For Office Use) is to be displayed instead. Hence in this template the rectangle is to be used just for the menu items. 06.2.5 Lightbox

This template supports inline frames and Lightbox features through the use of Fancybox and JQuery. Namely, the attachments page (ASP version) should be loaded in an iFrame. More details about how this feature is implemented can be found in the e-Forms Application Template document under section 05.7 Lightbox.


07. Required Hidden Fields

07.1 Main Form

Hidden Field Name

Description

Initial Value

hdnApplicantType Used to determine whether the

form is being filled in by the applicant himself, by a professional on behalf of the applicant, by an agent on behalf of the applicant, etc..

hdnLoginType Used to distinguish between the different groups of users in the AD (ex: eID, CORP, LO, ..)

hdnProcessID Needs to be manually set in each application form to the WebFormProcessID. Is used to retrieve all the relevant form info from DB.

Initial Value should be set to WebFormProcessID

hdnEmailAddress Used to store the contact email address (as stored in the Service Property table)

hdnProcessName Used to store the process name (as stored in the Service Property table)

hdnAmountDue Stores the amount due, to be used in the payment form later on in the process

hdnProcessStatus Stores the current status of the process (ex: vetting, approval, committee, returned to applicant, etc..) Value is set from code behind on submit.

hdnThankYouPage Stores thank you page URL Should be mapped to ‘_IISThankYouPageURL’ profile field

hdnFullEventID Stores the full event ID (set from the process)

hdnRole applicant/approving officer Initial value should be set to ‘C’ hdnStage Attachment Stage Initial value should be set to ‘C’ hdnURLAttach Stores attachments URL Should be mapped to

‘_IISAttachmentURL’ profile field hdnUsernameAttach Stores attachment username hdnSessionAttach Stores attachment session ID hdnLanguage Stores the language code for the

user’s selected language Should be mapped to the ‘languageCode’ profile field

hdnLocalizedFields Stores a comma delimited list of fields that have been localized in order for these not to be localized again at a later stage

hdnProviderKey Stores the provider key of the form’s provider

Should be set to the supplied provider key

hdnInvalidFields Stores the list of invalid fields along with the localized error message.

This field is automatically populated using the Validation Task.

hdnReserved01 Hidden field reserved for future


requirements hdnReserved02 Hidden field reserved for future

requirements

hdnReserved03 Hidden field reserved for future requirements













hdnAutoSaveInterval Hidden field containing the time interval for the AutoSave functionality

hdnPDFPath Hidden field containing the name of the PDF file generated for preview

hdnReturnFromAttachmentPage

Hidden field containing the page index of the page following the Attachments page

1

hdnLastCommentToUser

Hidden Field containing the last comment sent by the approval authority to the user

hdnFormVersionNo Hidden Field containing the Form’s Version No.

1.0

hdnProgressStatusStructure

Hidden Field containing the movement of status from the process


08. Localisation

Details about how the localisation is implemented within the e-Form templates are to be found in section 07 Localisation found in the e-Forms Application Template document.


09. Error Logging

Details about how the error logging is implemented within the eForm templates can be obtained from the e-Forms Application Template document in section 09 Error Logging.


10. Interaction with MITA component

10.1 Common classes

10.1.1 Approval.java

Public Method

Parameters Required

Description

localizeApprovalPageByStatus()

JSForm form, String status, String[ ] fieldsToLocalize

Localizes the approval page’s fields according to the process status and the applican’ts selected language.

getFormSubmitActionTranslation()

String submitItemText, JSForm form, String agentName

Retrieves the translation relate to the action in the Submission Action List

updateProcessStatus() JSForm form, String action, String jsonCriteria

Updates the process status using the progress structure

updateProcessStatus() JSForm form, String newStatus

Updates the process status, giving the new process

setFieldHistoricValue() JSForm form, String mainField, String historyField, boolean lastComment, String currentUser, String status, String translatedAction

Sets the contents of the text field in the history field

getPaymentInfo() JSForm form, String agentName

Retrieves the payment details and returns them to the caller


11. Application Status

For an eForm to be approved, the form must be evaluated through a process which varies according to the business logic pertaining to the form being built. For illustration purposes, a very simple process was built in order to demonstrate how the different stages that the form goes through interact with one another.

When a user submits the form, this progresses to the Vetting Stage where it can be approved, returned to the applicant for more information or rejected. If the application is rejected, the rejection message is to be sent back to the applicant. The applicant will then have to restart the application process from the beginning.

If the application is approved from the vetting stage, and all requested data items (such as mandatory attachments) are inputted accordingly, then the application will be sent to a work queue for further checking. These process stages are illustrated in the figure below.


If, instead of being approved, the application is sent back to the applicant, then the applicant will have the opportunity to add the missing details and resubmit the form or else to withdraw the form. This process is illustrated in the figure below. If the applicant would choose the prior then the application will be sent to the vetting stage again. These process stages mentioned are illustrated in the figure below.

Please note that the process defined in the illustrations above is just a simple basic process which will be tackled in a more complex way in the backend code of the whole process. Populating the Status

The application status can be populated using one of three methods. All of the methods are to be explained below. 11.1.1.1 Declaring it through the form processing

The first method which can be used is to declare the status through the process. This process identifies at which stage the form has arrived. It is to be found in the field named “hdnProgressStatusStructure”. The code of the function to be called is to be found below. Note how value of the hidden field stored in the form is implemented.

Code how to declare the application status through form processing function CSForm_OnSubmit() { try { var subItem = CSForm.getSelectedSubmitAction(); // update the process status. This can be done here or in the process. Approval.updateProcessStatus(CSForm, subItem.getValue(), CSForm.getField("hdnProgressStatusStructure").getValue()); //Set History Comments setHistoryAndDecisionLog(subItem.getDisplay()); //store localized field names so that next time we don't localize them again Localization.storeLocalizedFields(CSForm); } catch (e) { // call the script error handling method serverErrorHandler(e); } }


11.1.1.2 Declaring it on the server-side JavaScript

The other method which might be implemented is by configuring the status by default. This is to be configured using the “progressStatusOptions”. This variable is to be declared on the server-side script as shown in the code below.

Code how to declare the variable progressStatusOptions // progress status 0 = Proceed with Approval // progress status 1 = Send the application back to user var progressStatusOptions = { '1':{'Vetting':'appli cation', 'Approval':'appl ication1', 'Committee':'App roved'}, '0':{'Committee':'app lication2', 'Approval':'Comm ittee', 'Vetting':'Appro val', '':'Vetting', 'application':'V etting', 'application1':' Approval'} };

After the declaration the variable is used in case the hidden field value as obtained from the form is found to be empty. The code of how the “progressStatusOptions” variable is being used can be found in the code below. This code is found in the CSForm_OnOpen(). Code how to set the value of the hidden field by the variable progressStatusOptions extracted

from the function named initializeForm() // set the progress status structure. The structure might have been populated from // the process if (CSForm.getField("hdnProgressStatusStructure").g etValue().length == 0) { CSForm.getField("hdnProgressStatusStructure").setVa lue(progressStatusOptions); }

11.1.1.3 Declaring it in the process not on the form

If when loading the form the hidden field hdnProgressStatusStructure is to be found empty then the default value in the progressStatusOptions is to be evaluated. Otherwise if it is not empty the default value from the process is to be taken. Code how to declare the application status in the process void enteredActive(State state) { AssignmentList al = thisTask.evaluateAssignmentIn struction(); thisTask.setAssignment(al); /* * This is an alternative method to declaring the pr ogressStatusOptions. A hidden field should * be added to the Approval template to hold the pro cess status structure */ // progress status 0 = Proceed with Approval // progress status 1 = Send the application back to user String progressStatusOptions = "{"+ "'1':{'Vetting':'appl ication'," + "'Approval':'app lication1'," + "'Committee':'Ap proved'}," +


"'0':{'Committee':'ap plication2'," + "'Approval':'Com mittee'," + "'Vetting':'Appr oval'," + "'':'Vetting'," + "'application':' Vetting'," + "'application1': 'Approval'}" + "}"; thisProcess.setFieldValue("hdnProgressStatusStruc ture", progressStatusOptions); }


12. MITA External Javascript

12.1 Available Server - Side Scripts

12.1.1 Payment Details

The user can submit payments in different methods i.e. bank transfer, send a cheque, pay online or using internet banking service. The code implementation of these payment methods can be found in the function named populatePaymentInfo() . The bank transfer option code implementation is shown below.

Code how to handle a payment by bank transfer extracted from populatePaymentInfo() if (paymentType === '1') { // bank transfer fieldsHiddenArr = ["lblInternetBanking", "l blIBClearingBank",

"lblIBPaymentRefNo", "lblOnlinePayment", "lblPaymentByCheque", "lblTransactionType", "lblCardNo", "lblChequeNo", "lblChequeClearingBank", "txtTransa ctionType", "txtCardNo", "txtChequeClearingBank", "txtChequeNo", "txtIBClearingBank", "txtIBPaymentRefNo"];

fieldsVisibleArr = ["lblBTPaymentRefNo", "lblBankTransfer", "lblBTClearingBank", "txtBTClearingBank", "txtBTPaymentRefNo"];

CSForm.getField("txtBTClearingBank").setVal ue(paymentInfo.bank || ""); CSForm.getField("txtBTPaymentRefNo").setVal ue(paymentInfo.paymentId || ""); }

Please note that two (2) arrays are being used i.e. the fieldsHiddenArr and the fieldsVisibleArr . The first array i.e. fieldsHiddenArr is created to hold all the hidden fields needed within the payment page according to the payment method. The other array i.e. fieldsVisibleArr had been created to hold all the visible fields which belong to the payment method. Finally the fields are being viewed or hidden according to how they were initially set. CSForm = FormUtils.setFieldsHidden(CSForm, fieldsHi ddenArr, true); CSForm = FormUtils.setFieldsHidden(CSForm, fieldsVi sibleArr, false);

12.1.2 History

The text boxes found in the History Page are to be filled in according to the data inputted in the For Office Use page. This is implemented as shown below.

Code how to retrieve the comments/remarks and place them in the fields in the History Page function setHistoryAndDecisionLog(submitItemText) {

var currentUser = FormUtils.getCurrentLoggedInUser( CSServer); var submitAction = Approval.getFormSubmitActionTran slation(submitItemText,

CSForm, "eForms"); var subItem = CSForm.getField('hdnProcessStatus').g etValue();


Approval.setFieldHistoricValue(CSForm, "txtRemarks" , "txtExternalRemarksH", true, currentUser, subItem, submitAction); Approval.setFieldHistoricValue(CSForm, "txtInternal Remarks", "txtInternalRemarksH", false, currentUser, subItem, submitAction); Appro val.setFieldHistoricValue(CSForm, "txtApprovalCondi tions", "txtApprovalConditionsH", false, currentUser, subIt em, submitAction);

}

12.1.3 Form Title

Each eForm is allocated a title. E-Form Titles can be obtained making use of either of two methods. The first method would be to obtain the titles provided by the parameter stores located at MITA. The other method would be to access the data from the database as initialised by the Loqus group. The function which is to be used in order to access the database is to be found below.

Code how to retrieve the form title function getTitlesFromDB() { try { var result = FormUtils.getServicePropertyTitle( CSForm, "eforms"); CSForm.getField("lblFormTtlApproval").setValue( result); CSForm.getField("lblFormTtlHistory").setValue(r esult); CSForm.getField("lblFormTtlSubmit").setValue(re sult); CSForm.getField("lblFormTtlPaymentDetails").set Value(result); } catch (e) { // call the script error handling method serverErrorHandler(e); } }

12.1.4 Populating the Process Status

The process status is to be populated using the hidden field named hdnProcessStatus. The code implementation in order to populate the process status is the following.

Code how to populate the process status function setProcessStatus() { var subItem = CSForm.getField('hdnProcessStatus '); CSForm.getField("txtProcessStatus").setValue(CSForm .getField("hdnProcessStatus").getValue().toUpperCase()); CSForm.getField('txtOfficer').setValue(CSServer.get CurrentUser().getDisplayName()); CSForm.getField('txtDate').setValue(Utils.getCu rrentDateTime()); // insert the statuses pertaining to your proce ss. Set the visibility of the fields depending on the current // status. Use the following switch as a templa ted example. switch (subItem.getValue())


{ case 'Vetting': // set other fields not used in vetting as read only FormUtils.setFieldsHidden(CSForm, ["txt ApprovalConditions", "lblApprovalConditions", "lblApprovalRemarksH", "txtApprovalRema rksH"], true); break case 'Committee': CSForm.getField('txtDate').setReadOnly( false); break } //localize the Approval page according to the s tatus of the form var fieldsToLocalizeArray = ["lblOfficer", "lbl Date", "lblRemarks", "lblInternalRemarks", "lblApprovalConditions", "lbl FormTtlApproval"]; CSForm = Approval.localizeApprovalPageByStatus( CSForm, subItem.getValue(), fieldsToLocalizeArray); }

The value of the drop down list is stored in a hidden field named hdnProcessStatus hence the hidden field is to be populated from the form. This value is to be kept in the variable subItem. The status would help us know where is the form standing i.e. either approval stage or vetting stage.


13. Further Assistance

If you have a question about this eForms Component guide, or you encounter an issue, please

contact us on [email protected].

eForms Approval Template - MITA1 · 2011-12-29 · Unclassified eForms Approval Template 01....

Documents

Transcript of eForms Approval Template - MITA1 · 2011-12-29 · Unclassified eForms Approval Template 01....