Data validation on form inputs

[rmroot]

Each of the data input forms should have validation hooked up to it. That would most likely entail converting the forms from template driven forms to reactive forms using Angular's form builder. Using services to build the forms will allow validation checks throughout the application and better messaging for the user on missing or invalid data.

Best approach will probably be to break down the PR's work by type:

• Company
• Facility
• Assessment
• Project

A table created for clarification about input field validations. This will be shared through email and individual meetings to ensure agreements across the team. NEB-tool_Input_Form_Validation_Clarification_Table_06-07.xlsx

[rmroot]

I started the groundwork for converting the contacts form from a template driven form to a reactive form. I've added the service that can be re-used for contact validation. Going to handoff to @RLiNREL for him to run with as a first issue. Work was done on branch: issue-65

We will probably want to convert this issue to an epic and create separate issues for each form that needs to be done. We can discuss.

Some additional notes on the changes I made:

• The Form Group object return by the service has the validation for the form in it and has an "invalid" property that can be used to check that data input is valid. I have an example of this being used to disable the next button and show an alert exclamation point in the form. We will want to replicate this sort of behavior in the sidebar as well.
• I did the name for the form and the rest of the data can be added by Roy
• While going through these I think it's a good time to evaluate the data members for each form, make sure that we have ranges for validation and the correct data present.
• Form service: company-contacts-form.service.ts
• Form component: company-contacts-form.component.ts

[RLiNREL]

Copy over the updates and comments from #113 (which will be closed)

Kristina's comment:

For the input field:

• Number Type: no limit to decimal places
• String Type: string length should be > 200 for notes.

For the required option (two -tier):

• Must have: red error and disable to next step
• Should have: yellow warning and use default value if there is no input (such as cost and saving in assessment)

For display results:

• Limit to 2-3 decimal places

Jordan's comment:

• The underlying code base should support Latin1, Double-Byte and any other character sets that will make it possible to be translated in other languages than English.
• Support UTF-8 (Latin1, Double-Byte, other languages)

The NEB tool shall have fields for each KPI in which qualitative and/or historical information, e.g., past energy audits and results, can be entered. Each field should have enough character space to accommodate up to 500 words.

• No limit for qualitative and/or historical information. "Google says that text contains on average 5 characters per word, so we’re talking 2500 characters minimum. Let’s be safe and go with ~10,000 characters. I would advocate to not impose any arbitrary limit other than those necessary for UI or performance reasons."

Sarah's comment:

To add validation for ROI calculations and other inputs to quantify NEBs later

Change logs:

1. Removed max length for notes input field
2. Updated string input fields length, 1-100 for short text (company name, team member name, etc.) and 1-255 for longer text (street name, email, etc.)
3. Removed decimal places limit for number input type
4. Updated phone number pattern for US and international
5. Added a suggested column for inputs that are not required/unavailable at the beginning (default=0) but should be updated for accurate evaluation/reporting, such as costs and savings