Numeric-only inputs

[jamesatheyDDS]

Addresses #374.

Checklist

I have…

• [x] run the application locally (bin/rails server) and verified that my changes behave as expected.
• [x] run static code analysis (bin/rubocop) and vulnerability scan (bin/brakeman) against my changes.
• [x] run the test suite (bin/rake spec) and verified that all tests pass.
• [x] summarized below my changes and noted which issues (if any) this pull request fixes or addresses.
• [x] thoroughly outlined below the steps necessary to test my changes.
• [x] attached screenshots illustrating relevant behavior before and after my changes.
• [x] tested my changes in a modern desktop browser, Internet Explorer 11, and a modern mobile browser.
• [x] read, understand, and agree to the terms described in CONTRIBUTING.md.

Summary of Changes

This pull request sets the apporpriate attributes on the PPM Estimator and Weight Estimator forms so that mobile browsers will get the numeric-only keyboard when entering quantities, ZIP codes, dates, and weights.

Testing

To verify the changes proposed in this pull request…

1. clone this repo,
2. git checkout numeric-only-inputs,
3. set up development dependencies according to CONTRIBUTING.md,
4. run bin/rails server, and
5. load up http://localhost:3000 in the Web browser of your choice.

Screenshots

PPM Estimator - zip code field - before (iOS Safari)


PPM Estimator - zip code field - after (iOS Safari)


Weight Estimator - quantity field - before (iOS Safari)


Weight Estimator - quantity field - after (iOS Safari)


[jgarber623-gov]

Regarding ZIP entry, a few questions:

• Will these changes prevent users from entering postal codes that aren't entirely numeric (thinking OCONUS off-base postal codes, specifically)?
• ...and/or do we support calculations in regions where postal codes aren't entirely numeric (and five-digit based on the constraints)?
• Do these form fields that are now of type="number" continue to function with leading-zero ZIP codes (e.g. 08904)? I vaguely remember having an issue where browsers won't POST all five digits if the leading digits are zero.

[jamesatheyDDS]

@jgarber623-gov

Will these changes prevent users from entering postal codes that aren't entirely numeric (thinking OCONUS off-base postal codes, specifically)?...and/or do we support calculations in regions where postal codes aren't entirely numeric (and five-digit based on the constraints)?

The estimator does not support OCONUS locations at all at the moment. The constraint was 5 digits before this PR as well, this just lets iOS and Android browsers detect that the field is numeric correctly.

Do these form fields that are now of type="number" continue to function with leading-zero ZIP codes (e.g. 08904)?

I just tested the ZIP code 06511 with both Chrome and IE11, and it worked in both browsers.