Create table permission history 37

[dmartin4820]

Fixes #37

What changes did you make?

• create permission_history model
• register permission_history in admin
• add permission_history endpoints
• add permission_history seed data
• add api and model tests for permission_history creation

[del9ra]

Code looks mostly good! I just have one question: why did you use CASCADE instead of PROTECT for the history table? Wouldn't we lose data if a user is deleted?

created_by and updated_by should be integers according to the issue.

[dmartin4820]

Code looks mostly good! I just have one question: why did you use CASCADE instead of PROTECT for the history table? Wouldn't we lose data if a user is deleted?

created_by and updated_by should be integers according to the issue.

@del9ra The CASCADE instead of PROTECT can be fixed easily. It should be PROTECT and I originally misunderstood how it worked at first but it's clearer now.

For created_by and updated_by, I stuck with foreign keys based on @fyliu 's comment but there isn't really a confirmation from others on whether there is an explicit reason for it being an integer. The best reason I found was that making it a foreign key provides more functionality that I might be currently unaware of. One thing being that it allows us to specify on_delete if made a foreign key using Django. With an integer those same protections aren't there.

I can submit a change once resolved

[ExperimentsInHonesty]

Code looks mostly good! I just have one question: why did you use CASCADE instead of PROTECT for the history table? Wouldn't we lose data if a user is deleted?
created_by and updated_by should be integers according to the issue.

@del9ra The CASCADE instead of PROTECT can be fixed easily. It should be PROTECT and I originally misunderstood how it worked at first but it's clearer now.

For created_by and updated_by, I stuck with foreign keys based on @fyliu 's comment but there isn't really a confirmation from others on whether there is an explicit reason for it being an integer. The best reason I found was that making it a foreign key provides more functionality that I might be currently unaware of. One thing being that it allows us to specify on_delete if made a foreign key using Django. With an integer those same protections aren't there.

I can submit a change once resolved

We talked about this during the 2025-11-20 team meeting and the created_by and updated_by are FKs to the user table. The issue has been updated.