Add displayId virtual field to activity reports

[jasalisbury]

Description of change

Add a human friendly report ID field to activity reports

How to test

1. Pull down
2. Retrieve an activity report (curl http://localhost:3000/api/activity-reports/1). Display ID should look something like R01-AR-1

Issue(s)

• Assigning report IDs to Activity Reports HHS/Head-Start-TTADP#145

Checklist

• Meets issue criteria
• Code tested
• Meets accessibility standards (WCAG 2.1 Levels A, AA)
• Documentation updated
  • API methods
  • Boundary and Data Flow Diagrams
  • Architectural Decision Records written for major infrastructure decisions with the Nygard template
  • OSCAL templates completed when security controls are implemented or modified

[dcloud]

Codewise this looks fine, though I'm confused about the human-friendly identifiers. My (limited) understanding was that the 'R00-AR0' style identifier was used in SmartSheet and the plan was to use a different style for new identifiers. Further, old identifiers were going to be imported into a "legacy id" column and used to alias to the new id number. If we added this virtual field, wouldn't we be adding a third identifier that end users might see?

[jasalisbury]

Codewise this looks fine, though I'm confused about the human-friendly identifiers. My (limited) understanding was that the 'R00-AR0' style identifier was used in SmartSheet and the plan was to use a different style for new identifiers. Further, old identifiers were going to be imported into a "legacy id" column and used to alias to the new id number. If we added this virtual field, wouldn't we be adding a third identifier that end users might see?

I'm not 100% sure what the legacy ID will be used for. My understanding from this slack conversation https://gsa-tts.slack.com/archives/C017RJ4GEET/p1612903356126900 is the legacy ID will be used to pull up old activity reports. Thoughts @rahearn?

[rahearn]

the legacy ID will be used to pull up old activity reports

This is correct. The issue with the old reports is that every region had their own sheet, so there are duplicate numeric IDs. We can't just renumber them all when we import, because the old IDs may be referenced in narrative in other reports (a not-uncommon occurrence in the system in use last year).

I suppose we could get rid of the legacy id column if we were able to use a compound primary key to get around the uniqueness issues, but that seems like over-engineering the system to deal with just these reports that will become less and less of an issue as these imported reports are describe activities further and further in the past.

[rahearn]

This comment is relevant to this PR

[kryswisnaskas]

👍

[rahearn]

This code looks good, though it feels like this code should be accompanied by an api doc update and an update to remove the ID generation from the frontend code and use this field instead.

[jasalisbury]

This code looks good, though it feels like this code should be accompanied by an api doc update and an update to remove the ID generation from the frontend code and use this field instead.

I'll update the API docs. Frontend usage of the new field is happening in this PR

[rahearn]

I'll update the API docs. Frontend usage of the new field is happening in this PR

awesome, thanks!