feat: add html_content to BoardOut schema #271
No reviewers
Labels
No labels
domain:backend
domain:devops
domain:frontend
status:approved
status:in-progress
status:needs-fix
status:qa
type:bug
type:devops
type:feature
No milestone
No project
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ldraney/pal-e-api!271
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "270-board-html-content"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Add
html_contentfield toBoardOutso the frontend can render board note content (User Stories, Architecture, Acceptance Criteria) above kanban columns.Changes
src/pal_e_docs/schemas.py— Addedhtml_content: str | None = NonetoBoardOutsrc/pal_e_docs/routes/boards.py— Populatedhtml_contentfromboard_note.html_contentin_board_to_out()Test Plan
GET /boards/{slug}returnshtml_contentwhen board note has content,nullotherwiseboard-gdocs-daily-mcp-remote(has content) andboard-pal-e-platform(empty)Review Checklist
ruff formatcleanruff checkcleanRelated Notes
Related
Closes #270
QA Review
Scope: 2 files, +2 lines. Adds
html_contentfield toBoardOutschema and populates it from the board note.Findings
Schema change --
html_content: str | None = Noneadded toBoardOut. DefaultNoneensures backward compatibility for all existing API consumers. Clean.Route helper --
html_content=board_note.html_content or Nonecorrectly coalesces empty strings toNoneso the frontend gets a clean falsy check. Clean.Lint --
ruff formatandruff checkboth pass.Tests -- No new test failures. 3 pre-existing failures on main (
test_create_board_returns_no_note_id,test_get_board_returns_no_note_id,test_existing_fields_preserved) are unrelated to this change (they assertnote_idnot in response, but the schema already includes it on main).No issues found.
VERDICT: APPROVED
PR #271 Review
DOMAIN REVIEW
Stack: Python / FastAPI / SQLAlchemy / Pydantic
This is a minimal 2-line change adding
html_contentto theBoardOutPydantic schema and populating it from the board note in_board_to_out().Schema addition (
schemas.py):html_content: str | None = None-- correct optional field withNonedefault. Backward-compatible for existing API consumers since the field was not previously present and defaults toNone.Route population (
routes/boards.py):html_content=board_note.html_content or None-- theor Nonecoercion converts empty-string""(the model default permodels.py:110) toNone, which is a clean API contract:nullmeans "no content" rather than exposing an empty string. This is a sound choice.html_contentis an established field on theNotemodel (Mapped[str]withdefault=""), so the attribute access is valid. No new queries, no N+1 risk -- the board note is already loaded in_board_to_out().No PEP 484 issues. The
str | Noneunion syntax is consistent with the existing codebase style (Python 3.10+).BLOCKERS
None.
While there are no dedicated tests asserting
html_contentappears inBoardOutresponses, this is a trivial pass-through of an existing model field with no new logic. The existingtest_existing_fields_preservedtest pattern could be extended, but the absence of a test for a single nullable pass-through field does not rise to blocker level. See nits.NITS
Test coverage for the new field: Consider extending
TestBoardNoteIntegration.test_existing_fields_preserved(attests/test_boards.py:1132) to assert"html_content" in data. A second test verifying that a board whose note has actual HTML content returns it (notnull) would complete coverage. Low risk but good hygiene.PR body "Related" section: References the companion PR (
forgejo_admin/pal-e-app#104) but does not reference a plan slug. If this work is tracked under a plan, the slug should be included per SOP.SOP COMPLIANCE
270-board-html-content)Closes #270; no plan slug present (may not be plan-tracked work)PROCESS OBSERVATIONS
Nonedefault. No migration needed. No breaking contract.pal-e-app#104) should be coordinated -- the frontend can deploy first (it would simply ignore the missing field) or after (it would start consuming the new field). No ordering dependency.VERDICT: APPROVED