B-20647-INT add sac 80 character limit

[r-mettler]

B-20647

Summary

Set the SAC field character limit to 80 characters for HHG and NTS shipments.

Is there anything you would like reviewers to give additional scrutiny?
Also set backend validation so the SAC cannot be more than 80 characters. Please test using swagger by trying to create a a new Order. See instructions in test section.

Verification Steps for the Author

These are to be checked by the author.

• Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
• Have the Agility acceptance criteria been met for this change?

Verification Steps for Reviewers

These are to be checked by a reviewer.

• Has the branch been pulled in and checked out?
• Have the BL acceptance criteria been met for this change?
• Was the CircleCI build successful?
• Has the code been reviewed from a standards and best practices point of view?

Setup to Run the Code

• Instructions for starting storybook
• Instructions for starting the MilMove application
• Instructions for running tests

How to test

1. Access a shipment with HHG and/or NTS as Service Counselor that hasn't been approved yet
2. View the Orders for the HHG and/or NTS shipment
3. Try to enter more than 80 characters into the SAC field. Below is a sample string that is 90 characters, if you paste this into the SAC field then you should not see any 9's in the text field.

111111111122222222223333333333444444444455555555556666666666777777777788888888889999999999

4. Use swagger to try and create an Order with a SAC greater than 80 characters. This should fail with an unprocessable entity error.
5. Adjust the SAC to be less than 80 characters and verify you get no errors.

Sample for the body for POST create Order is below just update the SAC as needed.

{
"serviceMemberId": "eec4e65e-b328-4133-b822-c7eaba860ec9",
"issueDate": "2024-07-22",
"reportByDate": "2024-07-22",
"ordersType": "PERMANENT_CHANGE_OF_STATION",
"ordersTypeDetail": "HHG_PERMITTED",
"hasDependents": true,
"spouseHasProGear": true,
"newDutyLocationId": "62e795f4-61a8-4cca-b59d-028345c07b89",
"ordersNumber": "030-00362",
"tac": "F8J1",
"sac": "111111111122222222223333333333444444444455555555556666666666777777777788888888889999999999",
"departmentIndicator": "NAVY_AND_MARINES",
"grade": "E_1",
"originDutyLocationId": "929ba47a-2f7d-430e-9655-157a4c80303d"
}

Sample body for the PATCH update of the order (use the eTag and id from the successful result above.

{
"issueDate": "2024-07-22",
"reportByDate": "2024-07-22",
"ordersType": "PERMANENT_CHANGE_OF_STATION",
"ordersTypeDetail": "HHG_PERMITTED",
"newDutyLocationId": "62e795f4-61a8-4cca-b59d-028345c07b89",
"ordersNumber": "030-00362",
"tac": "F8J1",
"sac": "11111111112222222222333333333344444444445555555555666666666",
"departmentIndicator": "NAVY_AND_MARINES",
"grade": "E_1",
"originDutyLocationId": "929ba47a-2f7d-430e-9655-157a4c80303d"
}

Frontend

• There are no aXe warnings for UI.
• This works in Supported Browsers and their phone views (Chrome, Firefox, Edge).
• There are no new console errors in the browser devtools.
• There are no new console errors in the test output.
• If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.
• This change meets the standards for Section 508 compliance.

Backend

• Code follows the guidelines for Logging.
• The requirements listed in Querying the Database Safely have been satisfied.

Database

Any new migrations/schema changes:

• Follows our guidelines for Zero-Downtime Deploys.
• Have been communicated to #g-database.
• Secure migrations have been tested following the instructions in our docs.

Screenshots

[robot-mymove]

	Warnings
⚠️	This PR does not include changes to unit tests, even though it affects app code.

Generated by 🚫 dangerJS against b27d545

[ajlusk]

Tried and tried and could not input a SAC longer than 80 characters.

When I broke this down I was originally of the opinion that there should be some server-side validation of the length. Since >80 characters caused an issue with a connected system we might want to be a bit more sure nothing too long gets into the DB. But since SAC cannot be viewed or updated from the Prime API (as far as I can tell) frontend only validation is probably fine.

Found lots of questionable behavior unrelated to these changes along the way. I need to verify that behavior with a fresh, not pre-populated, move.

[ajlusk]

One of the odd behaviors mentioned above almost definitely has nothing to do with using pre-populated moves so I'll post it now. The SAC and TAC codes overflow from their cards poorly when they exceed 65ish characters. Not directly related to this ticket but small enough and related enough it could be fixed here.

[r-mettler]

One of the odd behaviors mentioned above almost definitely has nothing to do with using pre-populated moves so I'll post it now. The SAC and TAC codes overflow from their cards poorly when they exceed 65ish characters. Not directly related to this ticket but small enough and related enough it could be fixed here.

Looks like the app does this for every card if the text is long enough.

[ajlusk]

Intending to re-review due to the addition of server-side validation.

[ajlusk]

Issues mentioned above are fixed.

Existing orders with a SAC >80 characters are un-updatable and don't tell you why but I don't know that's within the scope of this ticket.