feat: nixpkgsissue activity log view #126
No reviewers
Labels
No labels
automation
backend
bug
contributor experience
data
deployment
documentation
duplicate
good first issue
help wanted
nice to have
notifications
package maintainer
performance
skin
tech debt
user story
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-community/nix-security-tracker#126
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/activity-log-app"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
feat: nixpkgsissue activity log view
Improve the messy representation of the different
pghistory
event tables:log_nixpkgsissue
in the PostgreSQL backend and introduce an unmanaged modelNixpkgsIssueLogView
to display a list of changes per timestamp and user.NixpkgsIssueLogView
in thepghistory
app to declutter the log reporting from the already crowdedshared
section.If performance starts being problematic for the
log_nixpkgsissue
view, we canmake it a materialized view and add a trigger to update its contents on
shared.nixpkgsissue
and it's m2m relationships updates.
NOTE: This PR includes #101
Can we add a comment on why this is not managed by the ORM?
Looks mostly good to me, I am just thinking about the GDPR considerations with the activity log, it's a good idea to make the cascade do nothing in case of deletion, but I wonder if we ought to implement a soft delete operation and bake in GDPR stuff in there directly.
I pasted the wrong commit message in the PR description. I'll add similar comments in the model + the fact that Django doesn't seem to support multi table proxy models (which would be the equivalent of VIEW tables in ORM).
@RaitoBezarius the cascade does nothing because it prevents Django from trying to delete content from a postgres
VIEW
, which would just yield an error (it's read-only after all).The data is collected from other
auth
andpghistory
tables so we have to double check there what exactly we want to do on user deletion. There's also the default Djangoadmin
table, which registers less finegrained changes made by users.I'll make an issue to not to forget about looking into this.
fixed
comment added
Please don't merge yet. Working on some other functionality I noticed a mistake on the way I set the migration file in this PR.
I'll take this out of draft as soon as I push the fix.
The PR is in a mergeable state again.
rebased with latest changes
@RaitoBezarius if you can reconfirm that you are ok with this approach after the rebases, this is ready to be merged.
Towards https://github.com/Nix-Security-WG/nix-security-tracker/issues/169
We have activity log for suggestions with #366. If we were to reintroduce activity logs for issues, it should be based on top of what was implemented there.
Pull request closed