Add Bike/Ped counter component and CPRG project tags

[chiaberry]

Associated issues

cityofaustin/atd-data-tech#25667

Testing

local

Steps to test:

Apply migrations.

in the app, navigate to a project's map tab. Add a new component and see that Counter is an option, with the work types "new" "modification" "maintenace/repair" as options.

Go to a project's summary page and add a new tag, put CPRG in the autocomplete and see the new tags as options.

alternately:

select * from moped_components mct where component_name = 'Counter'

select * from moped_component_work_types mcwt where component_id = 168

but replace the component_id with the id from your component in the first one. You should get three records with work type ids of 5, 6 and 7.

---

Ship list

• Code reviewed
• Product manager approved
• Product manager checked DB view dependencies
• [ ] Product manager added to QA test script if applicable

[netlify]

✅ Deploy Preview for atd-moped-main ready!

Name	Link
🔨 Latest commit	8fb16d7
🔍 Latest deploy log	https://app.netlify.com/projects/atd-moped-main/deploys/692eefcc2a71c00008ecc75a
😎 Deploy Preview	https://deploy-preview-1725--atd-moped-main.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mddilley]

Tested locally and this looks great! Thanks for adding, and TDM will be happy to have these available! 😎 🚢

[mddilley]

fwiw this reminded me to check with our robot friends about how we've been managing migrations for lookup values, and I came away with points that I think fit with what we've been doing so far:

• create "real" down migrations when changing schema or existing data
• not as important when adding lookup values since we can soft-delete later to phase out
• our local stack using prod data that tracks what migrations are applied already has generally kept us away from migration conflicts when releasing (i can only think of one time where we've had to manually handle migrations when releasing)

the one suggestion from the chat was trying to use syntax like this WHERE NOT EXISTS to make them idempotent so that, if we had to run the no-op down migration, we could run the up migration again without running into conflicts or re-creating things.

i don't think we need to change anything in this PR but wanted to check in with the team if we feel strongly about changing our practice in the future

[roseeichelmann]

test steps worked as expected ✔️