-
Notifications
You must be signed in to change notification settings - Fork 3
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
CAN History Part 2 #3386
CAN History Part 2 #3386
Conversation
…ack to can_history_trigger_func
… into history trigger
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇 looking good, tested locally and here is what I observed:
- ✅ CAN budget added
- ✅ CAN budget edited
- ✅ CAN Funding Received added
- ❌ CAN Funding Received edited
- ✅ CAN Funding Received deleted
- ✅ CAN Nickname edited (after small delay)
- ✅ CAN Description edited (after small delay)
@fpigeonjr Do you mean that editing funding received did not create an event in the history log? |
yes that is correct. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested locally and works as expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Great job @rajohnson90 and @Santi-3rd
🎉 This PR is included in version 1.41.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
What changed
In this PR we have added the majority of the remaining CAN History events designed by UX.
The largest part of this change was the events for updates. Updates are handled by taking the model before and after the update, serializing them, and passing them to a utility function in the ops/utils/events.py. This utility function performs a diff of the root level properties on these objects and places them into a dictionary of changes along with a few other properties required by all update changes.
Once the changes have been collected by the utility function and passed to the OpsEvent, the other biggest change is the handling of updates in the can_messages.py file. For CAN Updates, we iterate over the list of keys in the change dictionary and create a CAN History message for each changed property that we have designed around. Primarily right now this is the nickname and description of a CAN, but also portfolio. Portfolio may be moved to a different function later as it seems like the only time we expect the managing portfolio for a CAN to change is during the yearly CANBACs import.
CAN Funding and CAN Budget only check for changes to the funding received and budget respectively.
Issue
OPS-3276
How to test
Screenshots
If relevant, e.g. for a front-end feature
Definition of Done Checklist