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

feat: track history of submission changes #1491

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

joeyAghion
Copy link
Contributor

@joeyAghion joeyAghion commented Jul 11, 2024

This is a "spike" into integrating paper_trail for lightweight tracking of submission changes (related to ONYX-1109). I followed the default setup instructions, and just overrode the user_for_paper_trail method for our 2 different use-cases (administrative requests, or API requests including via GraphQL). No user is tracked for logged-out updates, but that should be obvious from the submission data, I guess.

I don't want to bloat the repo for no reason, but if this sort of history is useful, we could consider a few further updates, neither difficult:

  • make the history available in the UI (in some raw form)
  • consider switching from YAML (the default) to JSON data formatting

Copy link
Contributor

@nickskalkin nickskalkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good to me, but here is what I don't fully understand. Once the submission is approved it has a corresponding my collection artwork (maybe this is not true for all submissions, but for all user-generated ones). And we already track artwork changes in gravity. Also, there are some fields in my collection artworks table, that do not exist in submissions (tier 2 information like framed metrics and some others). The question is - maybe it is enough just to track MyC artwork changes and expose it in some way for convection admins? (either Tale or even by using this recent addition)

At the same time I think that your approach is much simper from technical point of view.

@joeyAghion
Copy link
Contributor Author

Yes, fair point. I thought we were mostly discussing submission changes (like additional file uploads). We probably don't need both, but if we'll allow updates to submissions at all, this could be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants