`allegations` table addition for `incidents`

[michplunkett]

What issue are you seeing?

Add allegations for incidents.

[michplunkett]

From @AetherUnbound, we need all of the various allegation formats.

[AetherUnbound]

Our allegations usually have the following format (here's an example):

• Allegation name
• Officer name
• Badge #
• Disposition
• Incident Type
• Finding

[michplunkett]

Hey @AetherUnbound! Would it make sense for each allegation to have a FK link to an officer? Should that FK be a non-null field? For incident type, do we have a set of values you'd like to keep them locked to?

[michplunkett]

Well, something like this makes initial sense to me:

incidents (current schema)
- id 
- created_at
- created_by
- last_updated_at
- last_updated_by
- date
- time
- description
- department_id (FK)
- report_number
- date
- location_id

allegations
- id
- incident_id (FK)
- officer_id (FK)
- created_at
- created_by
- last_updated_at
- last_updated_by
- disposition
- discipline
- type
- finding

We'd likely need a list of strings for valid values of disposition, discipline, type, and finding. Otherwise, this feels like a very straight-forward thing to put in the platform.

[AetherUnbound]

Ooo this is great, I'll take a look and respond tomorrow!

[michplunkett]

I updated the incidents table to its current schema. This will be a lot less lifting than I thought it'd be.

[AetherUnbound]

I think that works! As long as it's not unique to incident_id and officer_id (as an officer may have multiple allegations from a single incident), I think it'll work great.

We'd likely need a list of strings for valid values of disposition, discipline, type, and finding. Otherwise, this feels like a very straight-forward thing to put in the platform.

The thing is, I could see this being different per-department based on their approach for handling allegations. I don't want to base the values exclusively off of Seattle PD's approach. Do you think these could be open string fields for now, and then we could change our approach to how we enter them? Something like, a dropdown of available options to select from with the option to insert an arbitrary value 🤔

[michplunkett]

There isn't a unique constraint on it, we're good there!

With the current structure, it may be easier to just leave them as empty fields and let people enter things in them as they like. I think pre-populating them would require a different structure.