[3rdmike]

Description

Please provide a summary of the change and the issue fixed. Please include relevant context. List dependency changes.

Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Documentation update

How Has This Been Tested?

• New unit tests
• New integrated tests
• New component tests
• New end-to-end tests
• New user flow tests
• No new tests are required
• Manual tests (description below)
• Updated existing tests

Checklist

• I have read the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have already been accepted and merged

Further comments

Currently I plan to use them to show the address change request status and flat file transfer status, so we don't need to build Admin UI. This will be an useful addition to the pgAdmin work Brady started last week.

[github-actions]

🚀 Deployments Available

• Frontend
• Backend

[Harry0589]

In the flat-file status view, a batch can appear to finish before it starts. generateAll() captures one timestamp for all partners and writes it to generated_at. Each batch gets its created_at later. Could we set generated_at when the worker saves the completed file and add a regression test that checks generated_at >= generation_started_at?

[Harry0589]

In the request status view, a draft saved Monday and submitted Friday keeps Monday’s received_at. An operator filtering that column for Friday’s submissions would miss the request. Could we expose a separate submitted_at using the earliest operation created_at, as AddressChangeService.list() does, and cover a draft submitted on a later date in the view tests?

[3rdmike]

Generation code now captures generated_at after file content and checksum generation, immediately before saving. updated_at uses that same timestamp.
The shared job timestamp remains responsible for file naming and date.
Added a two-partner regression test with simulated delays, verifying generated_at >= generation_started_at and distinct completion times.

[3rdmike]

I’ll add submitted_at using the earliest operation creation time, matching AddressChangeService.list(). I’ll keep received_at unchanged and test a Monday draft submitted Friday, including a Friday submission-date filter.