Allow Facilities to save custom ids for Agents

Acceptance criteria:

• agents table stores the Custom ID for each agent
• A new API endpoint was added to allow Facilities to update the custom id for an agent

Time/effort estimate

2-4 hours

Implementation details

• Add a new column of type varchar(20) called custom_id to the agents table using a database migration.
• Add a unique index to the column custom_id
• Update schema/model for agents including the new field custom_id
• Create a new API endpoint responsible for updating the agent's custom id. This endpoint should validate the input and update the database accordingly.
  • The custom_id should accept chars: alphanumeric (case insensitive), hyphen, underscore and dot.
  • the custom_id should have a limit length between 5 and 20 chars (inclusive) RegExp suggestion: ^[A-Za-z0-9._-]{5,20}$
  • In case of invalid format, return Http Status 422 (Unprocessable Entity)
  • In case of existing custom_id, return Http Status 409 (Conflict)
  • In case of non-existing and valid custom_id, return Http Status 201 (Created)

Validate custom ids provided by Facilities

Acceptance criteria

• When a facility submits a custom id for an agent, the input should validate to ensure it meets the required format.
• If the input is invalid, an appropriate error message is returned to the facility.

Time/effort estimate

2-4 hours

Implementation details:

When submitting the form, validates the "Custom ID" field, accordingly to the format accepted by the API endpoint for updating custom ids:

• The custom id should has a limit length between 5 and 20 chars (inclusive)
• The custom id should accept only alphanumeric, dash, dot and underscore chars. RegExp suggestion: ^[A-Za-z0-9._-]{5,20}$
• The custom id should be unique in the database

In case of errors display an error message:

• "Custom ID is required", in case the field is empty
• "Custom ID accepts between 5 and 20 chars", if the limits have been exceeded
• "Custom ID accepts only alphanumeric, dash, dot and underscore chars", if the field does not comply with the established format.

After submitting the form:

• Display a SUCCESS toast message "Agent ID updated successfully", in case of HTTP response status 200
• Display an error next to the field "This Custom ID is already linked to another Agent", in case of HTTP response status 409 (Conflict). Refocus the "Custom ID" field.

In case of HTTP Response Status 422 (Unprocessable Entity), the field is not matching the valid format. This error should not be returned, since we are validating the format in the client app. Suggestion: Reuse the validation mechanism between client and server.

Update report generation logic

Update the report generation function to use the custom id when defined. Fall back to the internal database id when the custom id is not defined. Ensure that previously generated reports are still valid, handling reports generated with the internal database id.

Acceptance criteria

• generateReport function is updated to use custom id if available, and db internal id if not, accepting both when generating the report
• Previously generated reports are still valid/usable
• The system can handle reports generated with custom ids
• The system can handle reports generated with database internal ids

Time/effort cost estimate

2 hours

Implementation details

• Update generateReport function to look up the custom id for an agent and use it when generating the report.
• Add a check if no custom id is available for an agent, fall back to using the internal database id.
• Write tests to make sure previously generated reports and new reports with internal ids can still be used.