Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #634 +/- ##
=======================================
Coverage 63.22% 63.22%
=======================================
Files 387 387
Lines 41608 41608
Branches 5371 5371
=======================================
Hits 26307 26307
Misses 13615 13615
Partials 1686 1686
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0c6707f2b1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
…orts Trimming the DB to a single plan and running dumpdata left behind data that is not scoped to the retained plan, leaking other clients' content into the export. Add three cleanups to the trim command: - delete_orphaned_translation_data() (always): sweep wagtail_localize rows whose translated object no longer exists. The trim deletes inside mute_signals(post_delete), which suppresses wagtail_localize's own cleanup_translation_on_delete handler, so this mirrors it after the fact. - delete_orphaned_plan_pages() (always): delete PlanRootPage trees (any locale) and their Sites not belonging to a retained plan. Plan.delete() uses a bulk PageQuerySet.delete() that leaves a deleted plan's translated locale-tree pages (and Site) behind as live orphans. - prune_unused_common_indicators() (behind --prune-shared-reference-data): delete common indicators not linked to a retained plan or a surviving indicator, then empty frameworks. Extract the deletion-summary printing into helpers to keep handle() under the complexity limits.
bbliem
force-pushed
the
feature/trim-db-single-tenant-export-cleanup
branch
from
July 3, 2026 12:16
0c6707f to
7ebc4bf
Compare
Contributor
|
Some merge conflicts to be resolved |
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
2 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.
Trimming the DB to a single plan and running dumpdata left behind data that is not scoped to the retained plan, leaking other clients' content into the export. Add three cleanups to the trim command:
Extract the deletion-summary printing into helpers to keep handle() under the complexity limits.
While this removes some data that should not be in single-tenant exports, it is not sufficient. When I tested this with a churned client's data, there were still several records included that belonged to some other tenant for one reason or another. For cases like this, where we hand off data to customers, we need to be extra sure that we do not include data from other customers. A destructively_trim_db -> dumpdata approach seems to risky to me. Therefore, for data hand-off cases like this, I decided to go with a constructive approach that reuses some code from the copying app in order to only export data that is in fact reachable from the tenant's plan. There is a different PR for this: #632
✅ Pre-Merge Checklist
Type of Change
Testing