Story 2410: Legal Pages Wagtail Integration#2465
Conversation
julhoang
changed the title
julioest
left a comment
julioest
left a comment
There was a problem hiding this comment.
Ran the test plan and everything worked great, edits and reverse migration round-tripped cleanly too. Nice work, approving! ❇️
jlchilders11
left a comment
jlchilders11
left a comment
There was a problem hiding this comment.
Overall, this looks like a good implementation! One change I'd like to see for when we do the big switchover
|
|
||
| def get_v3_context_data(self, **kwargs): | ||
| return {"last_updated": "2024-02-22"} | ||
| from pages.models import LegalPage |
There was a problem hiding this comment.
So, the intent of the RoutableHomePage model is to allow us to rely on the Wagtail router, rather than manually grabbing pages and populating them like this.
So we can use this methodology for now for testing/flagged switchover purposes, but as part of the deployment we should remove this view and have the url instead point to wagtail. I'd like to see those switchover notes added as a note so it is not lost.
Concrete changes
urls.py - Add a commented out route change for ease of switchover.
# path("terms-of-use/", include(wagtail_urls)),There was a problem hiding this comment.
Hi @jlchilders11 ! I've added the inline TODO note to remove this manual grabbing after the V3 switchover. Would you mind helping me re-review this PR? 🙏
| return {"last_updated": "2024-02-17"} | ||
| from pages.models import LegalPage | ||
|
|
||
| return {"page": LegalPage.objects.live().filter(slug="privacy").first()} |
29dc2a1 to
9e354d6
Compare
5dc5260 to
b4947fa
Compare
|
Warning Review limit reached
Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@core/views.py`:
- Around line 499-502: Update V3Mixin.get_v3_context_data to preserve the base
context passed through **kwargs by merging those kwargs into the returned
context alongside the LegalPage value. Keep the existing legal page lookup and
legal_slug filtering unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 705c5579-d930-4b9c-807f-c8bd2d442f51
📒 Files selected for processing (12)
config/urls.pycore/views.pypages/migrations/0005_legalpage.pypages/migrations/0006_create_legal_pages.pypages/models.pystatic/css/v3/components.cssstatic/css/v3/header.cssstatic/css/v3/legal-page.cssstatic/css/v3/terms-of-use.csstemplates/v3/legal_page.htmltemplates/v3/privacy_policy.htmltemplates/v3/terms_of_use.html
💤 Files with no reviewable changes (4)
- templates/v3/terms_of_use.html
- templates/v3/privacy_policy.html
- static/css/v3/components.css
- static/css/v3/terms-of-use.css
4 participants
Issue: #2410
Summary & Context
Moves the Privacy Policy and Terms of Use pages into Wagtail so their content is editable in the CMS instead of hardcoded markdown, while keeping the pre-v3 markdown pages as a fallback until the v3 flag is fully rolled out.
Changes
Legal pages in Wagtail
LegalPagemodel (title + rich text body) that Wagtail's router serves directly; the visible "Last Updated" date comes from Wagtail's built-inlast_published_at, so republishing in the CMS updates it automatically.Consolidate legal templates and styles
privacy_policy.htmlandterms_of_use.htmltemplates with a singlelegal_page.htmldriven by the page's title and body.privacy-policy.cssandterms-of-use.cssinto onelegal-page.css.Serve the pages, with a fallback during v3 rollout
LegalPageView: when thev3flag is active it renders the Wagtail-backed page inlegal_page.html; when it's off it falls back to the legacy markdown page.TermsOfUseViewandPrivacyPolicyViewsubclass it and only set their slug.core/views.pyandconfig/urls.pyso the plan isn't lost.Header
Risks & Considerations
/privacy/and/terms-of-use/render two different ways depending on thev3waffle flag (Wagtail content vs. legacy markdown). Both paths need checking.Peer-Testing Guidelines
docker compose exec web python manage.py migrate— this seeds the Privacy and Terms of Use pages.v3flag on, visit http://localhost:8000/privacy/ and http://localhost:8000/terms-of-use/ and confirm the new design renders with a "Last Updated" date.v3flag off and reload both URLs — they should fall back to the legacy markdown pages.Screenshots
Self-review Checklist
Frontend
Summary by CodeRabbit
New Features
Style
Bug Fixes