Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allegations table addition for incidents #983

Open
michplunkett opened this issue Jul 23, 2023 · 8 comments
Open

allegations table addition for incidents #983

michplunkett opened this issue Jul 23, 2023 · 8 comments
Assignees

Comments

@michplunkett
Copy link
Collaborator

What issue are you seeing?

Add allegations for incidents.

@michplunkett michplunkett self-assigned this Jul 23, 2023
@michplunkett michplunkett changed the title Allegations table addition for Incidents allegations table addition for incidents Jul 23, 2023
@michplunkett
Copy link
Collaborator Author

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

@AetherUnbound
Copy link
Collaborator

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

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

@michplunkett
Copy link
Collaborator Author

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
Copy link
Collaborator Author

michplunkett commented Oct 22, 2024

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.

@michplunkett michplunkett self-assigned this Oct 22, 2024
@AetherUnbound
Copy link
Collaborator

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

@michplunkett
Copy link
Collaborator Author

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

@michplunkett michplunkett linked a pull request Oct 23, 2024 that will close this issue
3 tasks
@AetherUnbound
Copy link
Collaborator

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
Copy link
Collaborator Author

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.

@michplunkett michplunkett removed a link to a pull request Oct 29, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants