city-of-bloomington / utilities_forms Goto Github PK

By doing SFTP, it leaves the connection information deferred until runtime. Moving the form hosting from server to server will be easier without having to always declare new NFS mounts.

Would it be reasonable to drop the encryption for the confirmation number counter? The file is outside of the web directory now.

This is the only thing that's being encrypted, and it only contains an integer counter. Confirmation numbers consist of this integer, plus a randon 4 digit number.

I'm supposing we don't want the Confirmation Number to be guessable. Does OnBase stipulate any requirements for the Confirmation Number? Or, is it only ever used in the web forms, and OnBase just saves the posted Confirmation Number (whatever it is) as a key?

When we push a release to production, users report problems that are related to the old version of javascript code. Because the CSS and Javascript filenames never change, the browsers hold onto their cached versions.

It is difficult to explain to each and ever citizen how to clear their cache when we push a new release. We should add a build step that appends a version number onto the CSS and JS files. That way, when we release a new version, the filenames will be different, and people will not be using a cached version.

It would be nice for developers to receive emails when unexpected errors occur in production.

We should wire this application up to skidder, so we can subscribe to the error logs.

Citizens should be able to choose any date they like.

For the individual customer contract, when a "Street Dir." is left as a "N/A" value and then "Same as above is" selected for the Mailing Address, "N/A" ends up in the string for the mailing address. For example:

21 N/A TEST STREET

We want the forms to match the rest of the site they're being hosted on.

Utilities wants to require a file upload for the Name Change Request form

A new version of Master Address is almost ready to launch. It includes a major rewrite of the web services, which are not backwards compatilible. We'll need to update the addressChooser to work with the new Master Address web services.

One big change is that the subunits will no longer be included in an address search. You will need to do a seperate web service call to see if there are subunits at an address.

The newly added notice of a service fee charge on the Request for Disconnect form is no longer desired.

We are moving to a new payment system and will no longer be using AquaPay.

The import process for OnBase is leaving behind HTML files.

All the other files (dips and images) look like they are being cleaned up correctly.

Write a Dockerfile, so we can run this in a container

On individual customer contracts, the Telephone_Number field used in the web form is not getting mapped correctly by Get_Mapped_Name. The function returns NULL when you ask it to map that field.

I think this results in the Telephone_Number not being submitted to OnBase.

On the AquaPay form we want to make the "Name of your Authorizing Authority" field a required field.

Currently, way file extensions are checked will break when the user includes more than one period in the filename.

Also the forms processing code is using filenames the user provided as paths on the server hard drive. This is a security risk, we must not ever use user provided strings.

We should ignore the user's filename and only use server-generated strings for anything written to the hard drive.

Instead of…“Your application is being processed. If required, please upload further documentation by accessing this link:”…it should read as

…“Your application is being processed. If notified by a Customer Service Representative, please upload further documentation by accessing this link:”

We would like to have valid addresses saved in OnBase. Then, OnBase could integrate with other systems at the city, using the standardized address.

Users will need to choose their address from the list of valid addresses in our Master Address system. We would need to build a multi-step address search and choose process into the web forms.

Currently the only form validation is done client-side in javascript. We should write server-side code to do all the validation as well, since we don't trust the user and their browser.

I would like to request your assistance in adding a question to the Ind Customer Contract, with 3 options for answers. This would not correspond to anything in OnBase, but allow us to set up initial billing for customers and highlight the electronic bill option we have. It could go in order after the question "Are you a new customer to City of Bloomington Utilities *" and read:

How would you like to receive your monthly bill from us? (please provide e-mail address above if choosing e-mail bill option)

_mail _e-mail _both

I just noticed these errors are being thrown. Where do these keys come from? Should all forms have these fields?

PHP Notice: Undefined index: OBKey__225_2 in /srv/sites/utilities_forms/public/forms.processor.php on line 21, referer: https://bloomington.in.gov/utilities_forms/index.php?form=namechange
PHP Notice: Undefined index: OBKey__225_3 in /srv/sites/utilities_forms/public/forms.processor.php on line 22, referer: https://bloomington.in.gov/utilities_forms/index.php?form=namechange
PHP Notice: Undefined index: OBKey__225_4 in /srv/sites/utilities_forms/public/forms.processor.php on line 23, referer: https://bloomington.in.gov/utilities_forms/index.php?form=namechange
PHP Notice: Undefined index: OBKey__225_5 in /srv/sites/utilities_forms/public/forms.processor.php on line 24, referer: https://bloomington.in.gov/utilities_forms/index.php?form=namechange

The form is throwing this error when there is no conf number to show in the form.

Should there always be a conf_num for this form?

Error on line 25 of file /srv/sites/utilities_forms/forms/supplementary_docs.inc:
Undefined index: conf_num

We've decided to not even ask for social security numbers. That way, we don't have to save them anywhere, and won't be on the hook for them leaking out.

The forms that I've seen that ask for SSNs are:

• aquapay
• namechange
• individualcustomercontract

The utilities department would like a new form for renting out the hydrant meters.

The file upload for Supplementary Supporting Identification does not give the user any indication of the size limit for the upload. If the user attempts to upload a file that's too big, the server stops the upload and abandons the request.

The form needs to display to users what the size limit is for files they upload. The current size limit is 10MB.

There's currently no handling for file writing and file transfer errors. What do we want to do, or show the user, when PHP cannot write to the hard drive and/or transfer files over the network?

The current forms have javascript that prevents typing in more characters than are allowed for the zip code and telephone number fields. However, when you click on the input to begin typing, it puts the cursor on the exact space where you click.

Often, users click on the input, and start typing, but run up against the max length because they started on the third space of the zip code or telephone number, instead of the beginning of the input.

These inputs and their javascript should be replaced with HTML5 input types. All browsers now support standardized input for general numbers as well as telephone numbers. Users are much more used to the standard input methods provided by their own personal browsers.

The original chooser only populated Street (number, direction, and name). Other features, like the "Same as above" feature expect to be able to read a zip code, which is not currently populated.

During the address lookup process the form address chooser should go ahead and populate all the possible form fields that can be derived from the master address data.

This application currently SFTPs the files to the old OnBase server. We plan to have the new OnBase server create an NFS mount for us to use. We will need to update the php code to copy the files to particular place on the web server's file system.....instead of SFTPing the files to OnBase.

We need to update the wording on the forms again. It's mentioned on the Aquapay form and the Request for Disconnect form.

When the forms are saved in OnBase, and loaded from there, the addressChooser.js is 404.

In e7565aa we changed the urls to all be full URLs, since OnBase was not doing any web hosting. Any relative urls would 404.

Right now, everythings all in the web directory. We need to seperate the web exposable stuff from all the internal files.

We should create a public directory which would include index.php, the assets, and probably the vendor libraries.

There's currently a hard-coded dependence on the URLs for various things in forms and the form processing. We need to extract those out into configuration, or have them be dynamically determined.