fix(history): Remove duplicate history objects for entries#163
Merged
samoehlert merged 19 commits intomainfrom Nov 3, 2025
Merged
fix(history): Remove duplicate history objects for entries#163samoehlert merged 19 commits intomainfrom
samoehlert merged 19 commits intomainfrom
Conversation
…history entries on first try
…allows us to only have one historicalentry on initial entry.
…cted to home meant none of our messages showed up. this was because it loaded once quickly then again which is what the user would see
… expiration only. API only for now.
…hange something we don't own.
…but handle updating it on changes. also define some read only fields since users should not be allowed to change those things
crankynetman
changed the title
…rab so it stays in the validated_data
…nt and change wording for other scenario to make more sense
…te and create a helper for our client to easily get to hostname as the who
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 998d8dd |
…he route and actiontype in the view and passed it to the serializer
Collaborator
crankynetman
left a comment
crankynetman
left a comment
There was a problem hiding this comment.
Added a few comments inline
* main: ci: remove test that doesn't work on GH Actions (#170) fix(typo): use the correct key feat(gw_priority): this should allow us to choose which network is the "default gateway" of the macvlan address style(isort): fix ruff isort failure refactor(update): use the newest mozilla oidc package fix(oidc): fix oidc auth. i was overly complex and also misunderstanding the settings fix(login/out/redirect): edit the log{in|out}_urls and log{in|out}_redirect_urls to fix the local auth and hopefully the oidc fix(compose): use proper user for postgres healthcheck (#159) fix: move to bookworm (#166)
…e not required this also makes the scram_client experience better as it doesn't need to track entries. see https://github.com/esnet-security/SCRAM/pull/163/files#r2208200704
…he custom exception
i think we do want to fail on the method, not on the user permissions. doing a 403 suggests that sometimes you can change an entry, but we always want to block PUT/PATCH as the client should just do a normal post every time and SCRAM handles the logic on our end. We don't want the client to have to track these things.
crankynetman
approved these changes
Nov 3, 2025
Collaborator
crankynetman
left a comment
crankynetman
left a comment
There was a problem hiding this comment.
This looks great. This was a tricky one to track down, nicely done!!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #9
Closes #162
This removes the duplicate historicalentry we saw on initial creation. This also handles the comment on updates. This did require adding an update api view and serializer. The update stuff is only available on the API at the moment, we can add an update template for the WUI later if we want (likely).
As part of this change we fixed the messages getting swallowed. Sorry I can't
gitwell enough to fix that and add to another branch, but it was such a minor code change hopefully it's ok.Also, I did figure out that the
changed_byfield shown in the admin is actually the_historical_userfield, however, I don't think that matters. It's only a cosmetic thing in the admin panel as the API correctly shows thewhofield. Since that's the field we care about (as it's calculated both from API calls and the webUI) we can just use that field in our front end templates.