Story 2375: Wagtail Integration for create a post#2526
Conversation
|
Warning Review limit reached
Next review available in: 44 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. 📝 WalkthroughWalkthroughChangesV3 Post Creation
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant V3CreateForm
participant V3AllTypesCreateView
participant PostPage
participant ContentTag
participant Workflow
V3CreateForm->>V3AllTypesCreateView: submit selected post type and fields
V3AllTypesCreateView->>PostPage: create draft with block content
V3AllTypesCreateView->>ContentTag: attach related library tags
V3AllTypesCreateView->>PostPage: save revision
V3AllTypesCreateView->>Workflow: start workflow
Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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: 4
🧹 Nitpick comments (1)
news/views.py (1)
524-529: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMap post types directly to block names.
The block instance is never used, triggering RUF059, while Ruff also requires the mutable class mapping to be declared as
ClassVar.Proposed cleanup
+from typing import ClassVar - _POST_BLOCK_MAP: dict[str, tuple[str, Block]] = { - "blog": BLOG_BLOCK, - "news": NEWS_BLOCK, - "link": LINK_BLOCK, - "video": VIDEO_BLOCK, + _POST_BLOCK_MAP: ClassVar[dict[str, str]] = { + "blog": BLOG_BLOCK[0], + "news": NEWS_BLOCK[0], + "link": LINK_BLOCK[0], + "video": VIDEO_BLOCK[0], } ... - block_config = self._POST_BLOCK_MAP.get(post_type, None) + block_name = self._POST_BLOCK_MAP.get(post_type) ... - if block_config is None or form_class is None: + if block_name is None or form_class is None: ... - block_name, block_class = block_configAlso applies to: 552-563
🤖 Prompt for 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. In `@news/views.py` around lines 524 - 529, Update the post-type mappings in the relevant view class to map each type directly to its block-name string instead of storing unused block instances, and annotate the mutable class-level mappings with ClassVar. Apply the same change to both _POST_BLOCK_MAP and the additional mapping around the referenced section, preserving all existing post-type keys and block names.Source: Linters/SAST tools
🤖 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 `@news/views.py`:
- Around line 580-582: Update the view flow around PostIndexPage.objects.first()
to explicitly handle a missing index_page before calling
index_page.add_child(...). Ensure fresh or misconfigured sites receive the
intended safe response or initialization behavior instead of dereferencing None,
while preserving the existing path when a PostIndexPage exists.
- Around line 596-603: Update the image handling in the form submission flow to
avoid using Image.objects.get_or_create with title=image.name, which can
associate an unrelated existing image. Create a fresh Wagtail Image for each
upload, or use an explicit file-content-based deduplication strategy if reuse is
required, then assign the resulting image to page.image.
- Around line 604-627: Update the tag assignment in the flow around
index_page.add_child and page.tags.add so TaggableManager receives the
ContentTag instance directly, or explicitly unpack the collection if retaining
plural handling; preserve the existing conditional behavior and ensure tagging
succeeds after page creation.
- Around line 586-588: In the page update flow, replace the assignment to the
read-only cached property page.publish_at with an assignment to page.go_live_at
using the cleaned publish_at value. Ensure this occurs before save_revision() so
the requested publish time is persisted on PostPage.
---
Nitpick comments:
In `@news/views.py`:
- Around line 524-529: Update the post-type mappings in the relevant view class
to map each type directly to its block-name string instead of storing unused
block instances, and annotate the mutable class-level mappings with ClassVar.
Apply the same change to both _POST_BLOCK_MAP and the additional mapping around
the referenced section, preserving all existing post-type keys and block names.
🪄 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: e130d60d-0c42-4ee0-911e-df1366e9b5e7
📒 Files selected for processing (2)
news/views.pypages/blocks.py
julhoang
left a comment
julhoang
left a comment
There was a problem hiding this comment.
Hi Jeremy! I think we're missing the image reduction task from the workflow. Would you mind adding it?
Accepted formats: PNG and JPEG. Maximum upload file size: 5MB. Any uploaded file larger 1MB should be reduced to <1MB before saving to S3, the reduction function is out of scope. Note: Please update the image limit in the copy from 1MB to 5MB
| @@ -392,11 +397,13 @@ def _v3_create_context(): | |||
| ], | |||
| "related_libraries_options": [ | |||
| ("", "Select"), | |||
There was a problem hiding this comment.
Should we remove this ("", "Select") option as well?
There was a problem hiding this comment.
I'd like to maintain the Select option, or otherwise have a "clear selection" option, just in case the post is actually unrelated to any library and one is selected in error.
2 participants
Issue: #2375
Summary & Context
Implements backend wagtail integration with the V3 create a post page. When creating a post, new pages are saved as revisions and submitted for moderation.
Changes
Entrymodels with the creation ofPostPagemodels on the V3 create a post pagePlease list any potential risks or areas that need extra attention during review/testing
Notes: The moderation queue will be upgraded in another ticket in order to only send pages to human moderation if they fail automated moderation. Additionally, we currently only bother running the summary and video thumbnail tasks if the page is set to live. This means that moderators will not see the description and thumbnail before the page is live.
Testing notes:
In order to see the moderation queue in action, the tester may want to set themselves as a moderation. This can be done through the cms at
Settings > User > Username, going to the group tab, checking the box next to moderator, and saving the model. This will cause them to get alerts when pages are sent to moderation as well as being able to see the moderation queue on the home page of the cms.Self-review Checklist
Summary by CodeRabbit
New Features
Bug Fixes