Draft
Conversation
776f17a to
28d3c18
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #2084 +/- ##
===========================================
- Coverage 92.74% 92.59% -0.16%
===========================================
Files 1238 1248 +10
Lines 48017 47831 -186
===========================================
- Hits 44535 44289 -246
- Misses 3482 3542 +60 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
57a12e5 to
86b0c5d
Compare
49a233b to
6ea3da5
Compare
895ef33 to
fe2c214
Compare
fe2c214 to
e6e1148
Compare
54951c9 to
a661b54
Compare
The ElasticsearchConfigTest overwrites the settings with an invalid host for testing purposes. The settings are cached and affect subsequent tests (depending on the order in which they are run).
This commit restructures the application to improve modularity and clarity:
1. App Renames (use domain language):
- 'ssd' → 'mijn_uitkeringen'
- 'plans' → 'mijn_samenwerkingen'
- 'pdc' → 'onderwerpen'
- 'openzaak' → 'mijn_aanvragen'
2. CMS Integration Decentralization:
- Move CMS integrations from centralized cms/ module to respective apps
- Each app now owns its CMS configuration (mijn_uitkeringen,
mijn_samenwerkingen, onderwerpen, mijn_aanvragen, accounts)
- Standalone CMS apps (banner, footer, extensions) moved to core
3. Code Organization:
- Flatten core/cms/plugins/ directory structure
- Move shared CMS utilities (context processors, helpers) to core
- Consolidate inbox and profile CMS apps under accounts
The changes are purely structural (file movements, renaming). No migrations,
and no changes to database schemas.
CMS plugin models have been moved to new Django apps (core plugins,
mijn_aanvragen_cms, and profile), but we maintain the legacy 'plugins'
app_label to prevent ContentType duplication.
Django automatically creates new ContentType instances when app labels
change, which would break existing GenericForeignKey references (in
FeedItemData and TimelineLog). By keeping app_label='plugins', we avoid
this issue and maintain compatibility with existing data.
Affected models (8 total):
- LinkPluginConfig, LinkConfig (→ link_plugin)
- TextPluginConfig (→ text_plugin)
- UserFeedPluginConfig (→ userfeed_plugin)
- VideoPlayerPluginConfig (→ videoplayer_plugin)
- TakenPluginConfig, ZakenPluginConfig (→ mijn_aanvragen_cms)
- UserAppointments (→ profile)
The goal is safe deployment without data migration. Natural app labels
can be adopted later with proper ContentType migration.
Move old CMS plugin migrations (0001-0012) to _legacy/cms/plugins/ folder
to establish a legacy app that will continue managing plugin models.
The legacy 'plugins' app preserves migration history for database tables
created by migrations 0001-0012. All plugin models continue to be managed
by this app (with app_label='plugins') to prevent ContentType duplication.
Models managed by legacy plugins app (8 total):
- VideoPlayerPluginConfig
- UserFeedPluginConfig
- TextPluginConfig
- LinkPluginConfig
- LinkConfig
- UserAppointments
- TakenPluginConfig
- ZakenPluginConfig
Model code is organized in separate directories, but migrations remain
centralized in _legacy/cms/plugins/. A follow-up migration would be
needed to use natural app labels and have the migrations managed by the
apps themselves.
CMS templates are moved to their app template folders, and template names are updated to be uniform and recognizable (e.g. 'status_inner.html' -> 'aanvragen_detail.html') for the mijn_aanvragen detail template. The tempate which overrides Django's default flatpage template (flatpages/default.html) is deleted because it is no longer used (flatpages have been migrated to CMS).
a661b54 to
568a6e3
Compare
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
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.
Summary
Refactoring of all code related to CMS:
coreopenzaak->mijn_aanvragen,plans->mijn_samenwerkingenetc)cms/pluginsare preserved because they contain the logic for creating DB tables and are needed on fresh installs. They are moved into_legacy, a new module specifically for code that's only retained for compatibility.git-blame-ignore-revsNote
When moving plugins out of the old
cmsmodule, a choice had to be made how to handle existing DB tables and migrations. I chose a conservative approach: new migrations for the relevant plugins are created, but the original DB tables are preserved, and the plugin models contain references to the original tables. A "transition migration" tells Django that the models have been moved. This means the refactoring is not 100% "clean", but on the other hand: no data migration is needed, and the old migrations are moved out of the way into_legacy.Issue References
Closes #2081
Checklist