[WEB-5845] chore: changing description field to description json

[NarayanBavisetti]

Description

This PR renames the existing description field to description_json in both the Work Item and Page models. This change is required to introduce our new generic Description model, which will later expose a foreign key through the description field. Updating the existing key prevents naming conflicts and keeps the API consistent and readable. After this change, clients should start using description_json for the raw description data. The change is not backward compatible.

Type of Change

• Improvement (change that would cause existing functionality to not work as expected)

Summary by CodeRabbit

Release Notes

• Refactor
  • Updated description field naming conventions across the application for consistency. API consumers may see changes in field names within requests and responses.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Walkthrough

This pull request systematically renames the description field to description_json across database models, serializers, views, background tasks, and frontend code. A Django migration handles the schema change for DraftIssue, Issue, and Page models. Backward compatibility is maintained in intake serializers to accept both field names.

Changes

Cohort / File(s)	Summary
Core Model Definitions apps/api/plane/db/models/issue.py, apps/api/plane/db/models/page.py, apps/api/plane/db/models/draft.py	Renamed JSONField from description to description_json in Issue, Page, and DraftIssue models. Updated log_issue_description_version method to reference the renamed field.
Database Migration apps/api/plane/db/migrations/0117_rename_description_draftissue_description_json_and_more.py	Django migration applying RenameField operations to three models: draftissue, issue, and page.
API Serializers – Intake apps/api/plane/api/serializers/intake.py	Added new description JSONField (source: description_json) to IssueForIntakeSerializer. Updated Meta.fields to include description_json with deprecation note on description.
API Serializers – Issues apps/api/plane/api/serializers/issue.py	Modified IssueSerializer to exclude description_json instead of description. Added read-only description JSONField to IssueExpandSerializer (source: description_json).
App Serializers apps/api/plane/app/serializers/issue.py, apps/api/plane/app/serializers/page.py	IssueFlatSerializer: replaced description with description_json in fields. PageSerializer and PageBinaryUpdateSerializer: switched to use description_json in create/update flows.
Space Serializers apps/api/plane/space/serializer/issue.py	IssueFlatSerializer: replaced serialized field from description to description_json.
Intake Views apps/api/plane/api/views/intake.py, apps/api/plane/app/views/intake/base.py, apps/api/plane/space/views/intake.py	Updated issue creation/update to derive data from description_json instead of description. Intake serializer handles both field names for backward compatibility.
Page Views apps/api/plane/app/views/page/base.py	Changed serializer context key from description to description_json in PageViewSet.create.
Issue Views apps/api/plane/space/views/issue.py	Replaced selected field in query projection from description to description_json.
Background Tasks apps/api/plane/bgtasks/copy_s3_object.py, apps/api/plane/bgtasks/issue_description_version_sync.py, apps/api/plane/bgtasks/issue_description_version_task.py, apps/api/plane/bgtasks/page_version_task.py, apps/api/plane/bgtasks/workspace_seed_task.py	Updated all background task code to reference description_json instead of description when fetching, creating, or updating related model instances.
Live App Services apps/live/src/controllers/document.controller.ts, apps/live/src/extensions/database.ts, apps/live/src/services/page/core.service.ts	Document controller now returns description_json in payload. Database extension uses typed TDocumentPayload and renamed field in fetch/store operations. PageCoreService updated to accept TDocumentPayload instead of deprecated TPageDescriptionPayload.
Web App State & Hooks apps/web/core/hooks/use-page-fallback.ts, apps/web/core/store/pages/base-page.ts	BasePage class renamed property from description to description_json (constructor, observable, asJSON). use-page-fallback hook updated to pass description_json to updatePageDescription.
Shared Type Definitions & Utilities packages/types/src/page/core.ts, packages/editor/src/core/helpers/yjs-utils.ts	Updated TPage and TDocumentPayload types to use description_json instead of description. convertHTMLDocumentToAllFormats utility returns payloads with renamed field in both rich and document branches.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~40 minutes

Poem

🐰 A field renamed from dusk to dawn,
Description becomes JSON-strong!
Through models and views, from web to live,
This rabbit hops to help it thrive! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 38.89% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly and concisely describes the main change: renaming the description field to description_json across the codebase.
Description check	✅ Passed	The PR description fully addresses the template requirements with a detailed explanation of changes, clearly identifies the change type (Improvement), and provides clear context for the breaking change.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bc8321e and 64bd217.

📒 Files selected for processing (2)

• apps/api/plane/api/serializers/intake.py
• apps/api/plane/db/migrations/0117_rename_description_draftissue_description_json_and_more.py

🚧 Files skipped from review as they are similar to previous changes (1)

• apps/api/plane/api/serializers/intake.py

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-12-23T14:18:32.899Z

Learnt from: dheeru0198
Repo: makeplane/plane PR: 8339
File: apps/api/plane/db/models/api.py:35-35
Timestamp: 2025-12-23T14:18:32.899Z
Learning: Django REST Framework rate limit strings are flexible: only the first character of the time unit matters. Acceptable formats include: "60/s", "60/sec", "60/second" (all equivalent), "60/m", "60/min", "60/minute" (all equivalent), "60/h", "60/hr", "60/hour" (all equivalent), and "60/d", "60/day" (all equivalent). Abbreviations like "min" are valid and do not need to be changed to "minute". Apply this guidance to any Python files in the project that configure DRF throttling rules.

Applied to files:

• apps/api/plane/db/migrations/0117_rename_description_draftissue_description_json_and_more.py

🔇 Additional comments (1)

apps/api/plane/db/migrations/0117_rename_description_draftissue_description_json_and_more.py (1)

1-28: LGTM! Migration structure is correct.

The RenameField operations are the appropriate choice for this schema change—they preserve existing data, are reversible, and translate to fast metadata-only operations in PostgreSQL.

Since this is a breaking change (as noted in PR objectives), ensure the migration is deployed atomically with the corresponding code changes that reference description_json to avoid field name mismatches during the transition.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR renames the description field to description_json across the codebase for Work Item (Issue/DraftIssue) and Page models. This is a breaking change that prepares the system for introducing a new generic Description model, which will later use the description field name as a foreign key relationship.

• Comprehensive field rename from description to description_json in database models
• Updated all type definitions, serializers, views, and API endpoints to use the new field name
• Included Django migration to rename database columns
• Modified frontend stores, services, and type definitions to reflect the change

Reviewed changes

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/types/src/page/core.ts	Updated type definitions for TPage and TDocumentPayload to use description_json
packages/editor/src/core/helpers/yjs-utils.ts	Updated document conversion functions to return description_json
apps/web/core/store/pages/base-page.ts	Updated BasePage class property and observable decorator (potential issue with decorator change)
apps/web/core/hooks/use-page-fallback.ts	Updated page description update call to use description_json
apps/live/src/services/page/core.service.ts	Replaced custom type with TDocumentPayload and updated method signature
apps/live/src/extensions/database.ts	Updated payload construction to use description_json
apps/live/src/controllers/document.controller.ts	Updated response destructuring and JSON response to use description_json
apps/api/plane/space/views/issue.py	Updated issue values list to include description_json
apps/api/plane/space/views/intake.py	Updated intake issue creation and update to use description_json
apps/api/plane/space/serializer/issue.py	Updated serializer fields to include description_json
apps/api/plane/db/models/page.py	Renamed model field from description to description_json
apps/api/plane/db/models/issue.py	Renamed model field and updated version logging to use description_json
apps/api/plane/db/models/draft.py	Renamed model field from description to description_json
apps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.py	Django migration to rename fields in database
apps/api/plane/bgtasks/workspace_seed_task.py	Updated page creation to use description_json
apps/api/plane/bgtasks/page_version_task.py	Updated page version creation to use description_json
apps/api/plane/bgtasks/issue_description_version_task.py	Updated version update logic to use description_json
apps/api/plane/bgtasks/issue_description_version_sync.py	Updated batch sync to use description_json
apps/api/plane/bgtasks/copy_s3_object.py	Updated S3 object copy logic to use description_json
apps/api/plane/app/views/page/base.py	Updated page creation context to use description_json
apps/api/plane/app/views/intake/base.py	Updated intake partial update to use description_json
apps/api/plane/app/serializers/page.py	Updated serializer create/update methods to use description_json
apps/api/plane/app/serializers/issue.py	Updated IssueCreateSerializer fields to use description_json
apps/api/plane/api/views/intake.py	Updated intake issue creation and update to use description_json
apps/api/plane/api/serializers/issue.py	Updated IssueSerializer exclusions to use description_json
apps/api/plane/api/serializers/intake.py	Updated IntakeIssueSerializer fields to use description_json

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The observable decorator for description_json has been changed from observable to observable.ref. This change affects how MobX tracks changes to this field. With observable.ref, only reassignments of the entire object will trigger reactions, but changes to properties within the object will not be tracked. If the description_json object is mutated in place elsewhere in the codebase, those changes will no longer trigger UI updates. Consider whether this change is intentional - if the description_json object is never mutated in place and is only ever replaced entirely, observable.ref is appropriate. Otherwise, you should keep it as observable to maintain deep reactivity.

Suggested change

	description_json: observable.ref,
	description_json: observable,

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/api/plane/db/models/issue.py (1)

816-838: Fix critical migration error: issue.description field does not exist.

The migration at apps/api/plane/db/migrations/0077_draftissue_cycle_user_timezone_project_user_timezone_and_more.py:54 attempts to access issue.description, which does not exist in the Issue model. The Issue model only has description_json, description_html, description_stripped, and description_binary fields.

This will cause an AttributeError when the migration runs. Update line 54 from:

description=issue.description,

to use the correct field name that exists in the Issue model (likely issue.description_json).

Additionally, verify that the DraftIssue field definition in the migration matches the actual model—the migration creates a description field but the DraftIssue model defines description_json.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3d5e427 and b8844b2.

📒 Files selected for processing (26)

• apps/api/plane/api/serializers/intake.py
• apps/api/plane/api/serializers/issue.py
• apps/api/plane/api/views/intake.py
• apps/api/plane/app/serializers/issue.py
• apps/api/plane/app/serializers/page.py
• apps/api/plane/app/views/intake/base.py
• apps/api/plane/app/views/page/base.py
• apps/api/plane/bgtasks/copy_s3_object.py
• apps/api/plane/bgtasks/issue_description_version_sync.py
• apps/api/plane/bgtasks/issue_description_version_task.py
• apps/api/plane/bgtasks/page_version_task.py
• apps/api/plane/bgtasks/workspace_seed_task.py
• apps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.py
• apps/api/plane/db/models/draft.py
• apps/api/plane/db/models/issue.py
• apps/api/plane/db/models/page.py
• apps/api/plane/space/serializer/issue.py
• apps/api/plane/space/views/intake.py
• apps/api/plane/space/views/issue.py
• apps/live/src/controllers/document.controller.ts
• apps/live/src/extensions/database.ts
• apps/live/src/services/page/core.service.ts
• apps/web/core/hooks/use-page-fallback.ts
• apps/web/core/store/pages/base-page.ts
• packages/editor/src/core/helpers/yjs-utils.ts
• packages/types/src/page/core.ts

🧰 Additional context used

📓 Path-based instructions (4)

**/*.{ts,tsx,mts,cts}

📄 CodeRabbit inference engine (.github/instructions/typescript.instructions.md)

**/*.{ts,tsx,mts,cts}: Use const type parameters for more precise literal inference in TypeScript 5.0+
Use the satisfies operator to validate types without widening them
Leverage inferred type predicates to reduce the need for explicit is return types in filter/check functions
Use NoInfer<T> utility to block inference for specific type arguments when they should be determined by other arguments
Utilize narrowing in switch(true) blocks for control flow analysis (TypeScript 5.3+)
Rely on narrowing from direct boolean comparisons for type guards
Trust preserved narrowing in closures when variables aren't modified after the check (TypeScript 5.4+)
Use constant indices to narrow object/array properties (TypeScript 5.5+)
Use standard ECMAScript decorators (Stage 3) instead of legacy experimentalDecorators
Use using declarations for explicit resource management with Disposable pattern instead of manual cleanup (TypeScript 5.2+)
Use with { type: "json" } for import attributes; avoid deprecated assert syntax (TypeScript 5.3/5.8+)
Use import type explicitly when importing types to ensure they are erased during compilation, respecting verbatimModuleSyntax flag
Use .ts, .mts, .cts extensions in import type statements (TypeScript 5.2+)
Use import type { Type } from "mod" with { "resolution-mode": "import" } for specific module resolution contexts (TypeScript 5.3+)
Use new iterator methods (map, filter, etc.) if targeting modern environments (TypeScript 5.6+)
Utilize new Set methods like union, intersection, etc., when available (TypeScript 5.5+)
Use Object.groupBy / Map.groupBy standard methods for grouping instead of external libraries (TypeScript 5.4+)
Use Promise.withResolvers() for creating promises with exposed resolve/reject functions (TypeScript 5.7+)
Use copying array methods (toSorted, toSpliced, with) for immutable array operations (TypeScript 5.2+)
Avoid accessing instance fields via super in classes (TypeScript 5....

Files:

• packages/types/src/page/core.ts
• packages/editor/src/core/helpers/yjs-utils.ts
• apps/web/core/hooks/use-page-fallback.ts
• apps/live/src/services/page/core.service.ts
• apps/web/core/store/pages/base-page.ts
• apps/live/src/extensions/database.ts
• apps/live/src/controllers/document.controller.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Enable TypeScript strict mode and ensure all files are fully typed

Files:

• packages/types/src/page/core.ts
• packages/editor/src/core/helpers/yjs-utils.ts
• apps/web/core/hooks/use-page-fallback.ts
• apps/live/src/services/page/core.service.ts
• apps/web/core/store/pages/base-page.ts
• apps/live/src/extensions/database.ts
• apps/live/src/controllers/document.controller.ts

**/*.{js,jsx,ts,tsx,json,css}

📄 CodeRabbit inference engine (AGENTS.md)

Use Prettier with Tailwind plugin for code formatting, run pnpm fix:format

Files:

• packages/types/src/page/core.ts
• packages/editor/src/core/helpers/yjs-utils.ts
• apps/web/core/hooks/use-page-fallback.ts
• apps/live/src/services/page/core.service.ts
• apps/web/core/store/pages/base-page.ts
• apps/live/src/extensions/database.ts
• apps/live/src/controllers/document.controller.ts

**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{js,jsx,ts,tsx}: Use ESLint with shared config across packages, adhering to max warnings limits per package
Use camelCase for variable and function names, PascalCase for components and types
Use try-catch with proper error types and log errors appropriately

Files:

• packages/types/src/page/core.ts
• packages/editor/src/core/helpers/yjs-utils.ts
• apps/web/core/hooks/use-page-fallback.ts
• apps/live/src/services/page/core.service.ts
• apps/web/core/store/pages/base-page.ts
• apps/live/src/extensions/database.ts
• apps/live/src/controllers/document.controller.ts

🧠 Learnings (7)

📚 Learning: 2025-07-23T18:18:06.875Z

Learnt from: NarayanBavisetti
Repo: makeplane/plane PR: 7460
File: apps/api/plane/app/serializers/draft.py:112-122
Timestamp: 2025-07-23T18:18:06.875Z
Learning: In the Plane codebase serializers, workspace_id is not consistently passed in serializer context, so parent issue validation in DraftIssueCreateSerializer only checks project_id rather than both workspace_id and project_id. The existing project member authentication system already validates that users can only access projects they belong to, providing sufficient security without risking breaking functionality by adding workspace_id validation where the context might not be available.

Applied to files:

• apps/api/plane/space/serializer/issue.py

📚 Learning: 2025-12-23T14:18:32.899Z

Learnt from: dheeru0198
Repo: makeplane/plane PR: 8339
File: apps/api/plane/db/models/api.py:35-35
Timestamp: 2025-12-23T14:18:32.899Z
Learning: Django REST Framework rate limit strings are flexible: only the first character of the time unit matters. Acceptable formats include: "60/s", "60/sec", "60/second" (all equivalent), "60/m", "60/min", "60/minute" (all equivalent), "60/h", "60/hr", "60/hour" (all equivalent), and "60/d", "60/day" (all equivalent). Abbreviations like "min" are valid and do not need to be changed to "minute". Apply this guidance to any Python files in the project that configure DRF throttling rules.

Applied to files:

• apps/api/plane/space/serializer/issue.py
• apps/api/plane/bgtasks/issue_description_version_task.py
• apps/api/plane/api/serializers/issue.py
• apps/api/plane/app/serializers/page.py
• apps/api/plane/space/views/intake.py
• apps/api/plane/app/serializers/issue.py
• apps/api/plane/bgtasks/workspace_seed_task.py
• apps/api/plane/app/views/page/base.py
• apps/api/plane/bgtasks/issue_description_version_sync.py
• apps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.py
• apps/api/plane/db/models/draft.py
• apps/api/plane/db/models/page.py
• apps/api/plane/bgtasks/copy_s3_object.py
• apps/api/plane/space/views/issue.py
• apps/api/plane/bgtasks/page_version_task.py
• apps/api/plane/api/serializers/intake.py
• apps/api/plane/api/views/intake.py
• apps/api/plane/app/views/intake/base.py
• apps/api/plane/db/models/issue.py

📚 Learning: 2025-10-29T09:17:54.815Z

Learnt from: NarayanBavisetti
Repo: makeplane/plane PR: 7905
File: apps/api/plane/app/views/search/base.py:241-276
Timestamp: 2025-10-29T09:17:54.815Z
Learning: In apps/api/plane/app/views/search/base.py, the `filter_intakes` method uses `Issue.objects` (base manager) instead of `Issue.issue_objects` (custom manager) because the custom manager filters out all intake statuses, which would prevent querying pending and snoozed intake issues.

Applied to files:

• apps/api/plane/space/views/intake.py
• apps/api/plane/api/serializers/intake.py

📚 Learning: 2025-09-12T07:29:36.083Z

Learnt from: dheeru0198
Repo: makeplane/plane PR: 7625
File: apps/api/plane/bgtasks/workspace_seed_task.py:95-98
Timestamp: 2025-09-12T07:29:36.083Z
Learning: In the Plane codebase, workspace seed data should have project features (cycle_view, module_view, issue_views_view) enabled by default, even when regular project creation has these features disabled. This provides users with a complete demo experience in the seeded workspace.

Applied to files:

• apps/api/plane/bgtasks/workspace_seed_task.py

📚 Learning: 2025-10-01T15:30:17.605Z

Learnt from: lifeiscontent
Repo: makeplane/plane PR: 7888
File: packages/propel/src/avatar/avatar.stories.tsx:2-3
Timestamp: 2025-10-01T15:30:17.605Z
Learning: In the makeplane/plane repository, avoid suggesting inline type imports (e.g., `import { Avatar, type TAvatarSize }`) due to bundler compatibility issues. Keep type imports and value imports as separate statements.

Applied to files:

• apps/live/src/extensions/database.ts

📚 Learning: 2025-11-25T10:18:05.172Z

Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/typescript.instructions.md:0-0
Timestamp: 2025-11-25T10:18:05.172Z
Learning: Applies to **/*.{ts,tsx,mts,cts} : Use `with { type: "json" }` for import attributes; avoid deprecated `assert` syntax (TypeScript 5.3/5.8+)

Applied to files:

• apps/live/src/extensions/database.ts

📚 Learning: 2025-11-25T10:18:05.172Z

Learnt from: CR
Repo: makeplane/plane PR: 0
File: .github/instructions/typescript.instructions.md:0-0
Timestamp: 2025-11-25T10:18:05.172Z
Learning: Applies to **/*.{js,mjs,cjs} : Use `import` tags in JSDoc for cleaner type imports in JavaScript files when working in a mixed codebase (TypeScript 5.5+)

Applied to files:

• apps/live/src/extensions/database.ts

🧬 Code graph analysis (7)

apps/api/plane/space/views/intake.py (1)

apps/api/plane/space/views/issue.py (2)

• get (72-207)
• get (593-769)

apps/live/src/services/page/core.service.ts (1)

packages/types/src/page/core.ts (1)

• TDocumentPayload (66-70)

apps/api/plane/db/models/draft.py (1)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

apps/api/plane/db/models/page.py (1)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

apps/live/src/extensions/database.ts (1)

packages/types/src/page/core.ts (1)

• TDocumentPayload (66-70)

apps/api/plane/db/models/issue.py (1)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

apps/live/src/controllers/document.controller.ts (1)

packages/editor/src/core/helpers/yjs-utils.ts (1)

• convertHTMLDocumentToAllFormats (206-240)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: CodeQL analysis (javascript-typescript)
• GitHub Check: Build packages
• GitHub Check: Analyze (javascript)

🔇 Additional comments (33)

apps/api/plane/space/views/issue.py (1)

747-747: LGTM: Field rename applied correctly in query projection.

The update from "description" to "description_json" in the .values() call is consistent with the PR's field rename objective and aligns with the migration renaming the database column.

apps/api/plane/bgtasks/workspace_seed_task.py (1)

362-362: LGTM: Seed data correctly uses renamed field.

The parameter change from description= to description_json= with the default value of {} is appropriate for the JSON field type and aligns with the Page model's field rename.

apps/live/src/extensions/database.ts (3)

2-10: LGTM: Import organization and type import follow TypeScript best practices.

The addition of import type { TDocumentPayload } from @plane/types correctly uses explicit type imports, and the comment-based organization improves code readability.

---

40-44: LGTM: Payload type annotation and field rename are correct.

The explicit TDocumentPayload type annotation enhances type safety, and the field rename from description to description_json correctly aligns with the type definition and PR objective.

---

80-84: LGTM: Payload type annotation and field rename are correct.

Consistent with the fetchDocument changes, the explicit type and field rename maintain type safety and align with the TDocumentPayload interface.

apps/live/src/controllers/document.controller.ts (1)

30-39: LGTM: Response payload correctly uses renamed field.

The destructuring and response both correctly reference description_json instead of description, matching the return type of convertHTMLDocumentToAllFormats which returns TDocumentPayload with the description_json field.

apps/api/plane/bgtasks/page_version_task.py (1)

31-31: LGTM: PageVersion creation now references the correct field.

The change from page.description to page.description_json correctly updates the source field reference to match the renamed Page model field, ensuring version history captures the right data.

apps/api/plane/api/views/intake.py (2)

185-185: LGTM! Intake issue creation updated to use description_json.

The Issue creation in the intake POST flow correctly uses description_json from the request payload, consistent with the repository-wide field rename.

---

371-371: LGTM! Intake issue update payload uses description_json.

The restricted update payload for guest users correctly references description_json, maintaining consistency with the field rename.

apps/api/plane/app/serializers/issue.py (1)

56-56: LGTM! IssueFlatSerializer updated to expose description_json.

The serializer field list correctly reflects the model field rename from description to description_json.

apps/api/plane/space/serializer/issue.py (1)

196-196: LGTM! Space API IssueFlatSerializer updated to expose description_json.

The space module serializer correctly mirrors the field rename, maintaining consistency across API modules.

apps/api/plane/bgtasks/issue_description_version_task.py (1)

22-22: LGTM! Background task updated to use description_json.

The version update logic correctly assigns issue.description_json to the version record, and the field is properly included in the save() call's update_fields list (lines 28-36).

apps/api/plane/app/views/page/base.py (1)

131-131: LGTM! Page creation context updated to use description_json.

The serializer context correctly references description_json with an appropriate default value, consistent with the Page model field rename.

apps/api/plane/bgtasks/issue_description_version_sync.py (1)

62-62: LGTM! Field rename is consistent.

The update from description to description_json is correctly applied in both the batch query .only() clause and the IssueDescriptionVersion object instantiation.

Also applies to: 95-95

apps/api/plane/api/serializers/issue.py (1)

68-68: LGTM! Serializer exclusion updated correctly.

The exclude list now properly references description_json instead of description, aligning with the model field rename.

apps/api/plane/app/views/intake/base.py (1)

397-397: LGTM! Field reference updated consistently.

The dictionary key, get() parameter, and fallback attribute all correctly reference description_json instead of description.

apps/api/plane/db/models/page.py (1)

28-28: LGTM! Model field renamed correctly.

The field rename from description to description_json is properly implemented, preserving the JSONField type and all attributes (default=dict, blank=True). This change is supported by the migration 0114_rename_description_draftissue_description_json_and_more.py mentioned in the PR.

apps/api/plane/bgtasks/copy_s3_object.py (1)

144-144: No action needed—the external service has been properly updated. The /convert-document endpoint (apps/live/src/controllers/document.controller.ts) returns description_json and description_binary in its response payload, which matches the expectations in copy_s3_object.py line 144-145.

apps/api/plane/api/serializers/intake.py (1)

20-20: LGTM! Field name updated to match model changes.

The serializer field list correctly reflects the rename from description to description_json. This aligns with the broader migration to JSON-based description storage.

apps/live/src/services/page/core.service.ts (2)

2-2: LGTM! Consolidated to shared type definition.

The import now uses TDocumentPayload from @plane/types, which promotes type consistency across the codebase and includes description_json as the new field name.

---

100-100: LGTM! Method signature aligned with type changes.

The method signature correctly uses TDocumentPayload which includes description_json instead of the deprecated description field.

apps/api/plane/space/views/intake.py (2)

143-143: LGTM! Field reference updated correctly.

The create method now correctly uses description_json from the request payload with an appropriate default value of {} for empty JSON objects.

---

204-204: LGTM! Partial update logic uses new field name.

The partial update correctly references issue.description_json as a fallback when the field is not provided in the request. This assumes the migration (0114_rename_description_draftissue_description_json_and_more.py) has been applied, which should be enforced by Django's migration order.

packages/types/src/page/core.ts (2)

11-11: LGTM! Type definition updated consistently.

The TPage type now uses description_json with the same type signature (object | undefined), maintaining backward compatibility in type structure while reflecting the field name change.

---

69-69: LGTM! Payload type updated consistently.

The TDocumentPayload type now correctly uses description_json (required object type), which aligns with the model changes and maintains type safety for document update operations.

apps/api/plane/db/models/draft.py (1)

42-42: LGTM! Model field renamed correctly.

The field rename from description to description_json preserves the field type (JSONField) and constraints (blank=True, default=dict). This aligns with the broader migration to JSON-based description storage across the codebase.

apps/api/plane/app/serializers/page.py (2)

57-102: LGTM! PageSerializer.create correctly updated to use description_json.

The create method now reads description_json from context (line 61) and passes it to Page.objects.create (line 71), consistent with the field rename. The flow for description_binary and description_html remains unchanged.

---

169-221: LGTM! PageBinaryUpdateSerializer correctly updated to use description_json.

The serializer field definition (line 174) and update logic (lines 217-218) now operate on description_json instead of description. The JSONField type is appropriate for JSON data.

apps/web/core/store/pages/base-page.ts (1)

83-83: LGTM! BasePage class correctly updated to use description_json.

The property has been renamed consistently across:

• Property declaration (line 83)
• Constructor initialization (line 120)
• MobX observable configuration (line 145)
• JSON serialization (line 220)

The observable.ref configuration is appropriate for the object type.

Also applies to: 120-120, 145-145, 220-220

apps/web/core/hooks/use-page-fallback.ts (1)

59-63: LGTM! usePageFallback correctly updated to use description_json.

The payload passed to updatePageDescription now uses description_json (line 62) instead of description, consistent with the field rename across the codebase.

packages/editor/src/core/helpers/yjs-utils.ts (1)

206-240: LGTM! convertHTMLDocumentToAllFormats correctly updated to return description_json.

Both the "rich" and "document" variant branches return description_json in the payload structure. The TDocumentPayload type definition in packages/types/src/page/core.ts already includes description_json as an object field, confirming the implementation is properly typed and consistent.

apps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.py (1)

1-28: LGTM! Migration correctly renames description to description_json.

The migration uses RenameField operations to rename the description field to description_json for three models: DraftIssue, Issue, and Page. Models have been verified to use the new field names, and serializers automatically expose all model fields. This is the appropriate approach for a field rename, as it preserves existing data and is automatically reversible.

Ensure that:

1. All code references to the old description field have been updated across serializers, views, models, and client code.
2. The migration has been tested in a staging environment before production deployment.
3. API consumers are notified of this breaking change.

apps/api/plane/db/models/issue.py (1)

131-131: LGTM - Field definition follows Django conventions.

The description_json JSONField is correctly defined with appropriate parameters. Django's JSONField handles the default=dict safely by creating new dict instances for each model instance.

[makeplane]

Linked to Plane Work Item(s)

• [WEB-5845] Migrate description to description_json field in work item and page

This comment was auto-generated by Plane

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/api/plane/api/serializers/intake.py`:
- Around line 22-23: Fix the typo "Depricated" → "Deprecated" in the fields list
comment and remove the duplicate mapping that causes the same model data to be
exposed twice: drop the "description" entry that uses source="description_json"
(leave only "description_json"), or alternatively change the mapping so each
field maps to a distinct model attribute; ensure only one field writes to the
underlying model field to avoid conflicting deserialization between description
and description_json.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c3fdd1e and bc8321e.

📒 Files selected for processing (4)

• apps/api/plane/api/serializers/intake.py
• apps/api/plane/api/serializers/issue.py
• apps/api/plane/api/views/intake.py
• apps/api/plane/db/migrations/0116_rename_description_draftissue_description_json_and_more.py

🚧 Files skipped from review as they are similar to previous changes (2)

• apps/api/plane/api/views/intake.py
• apps/api/plane/db/migrations/0116_rename_description_draftissue_description_json_and_more.py

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2025-07-23T18:18:06.875Z

Learnt from: NarayanBavisetti
Repo: makeplane/plane PR: 7460
File: apps/api/plane/app/serializers/draft.py:112-122
Timestamp: 2025-07-23T18:18:06.875Z
Learning: In the Plane codebase serializers, workspace_id is not consistently passed in serializer context, so parent issue validation in DraftIssueCreateSerializer only checks project_id rather than both workspace_id and project_id. The existing project member authentication system already validates that users can only access projects they belong to, providing sufficient security without risking breaking functionality by adding workspace_id validation where the context might not be available.

Applied to files:

• apps/api/plane/api/serializers/issue.py

📚 Learning: 2025-12-23T14:18:32.899Z

Learnt from: dheeru0198
Repo: makeplane/plane PR: 8339
File: apps/api/plane/db/models/api.py:35-35
Timestamp: 2025-12-23T14:18:32.899Z
Learning: Django REST Framework rate limit strings are flexible: only the first character of the time unit matters. Acceptable formats include: "60/s", "60/sec", "60/second" (all equivalent), "60/m", "60/min", "60/minute" (all equivalent), "60/h", "60/hr", "60/hour" (all equivalent), and "60/d", "60/day" (all equivalent). Abbreviations like "min" are valid and do not need to be changed to "minute". Apply this guidance to any Python files in the project that configure DRF throttling rules.

Applied to files:

• apps/api/plane/api/serializers/issue.py
• apps/api/plane/api/serializers/intake.py

🧬 Code graph analysis (2)

apps/api/plane/api/serializers/issue.py (1)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

apps/api/plane/api/serializers/intake.py (3)

apps/api/plane/utils/exporters/schemas/base.py (1)

• JSONField (127-140)

apps/api/plane/api/serializers/issue.py (15)

• Meta (65-68)
• Meta (326-329)
• Meta (340-360)
• Meta (371-383)
• Meta (394-406)
• Meta (437-442)
• Meta (463-475)
• Meta (486-496)
• Meta (507-529)
• Meta (542-554)
• Meta (576-578)
• Meta (591-592)
• Meta (605-606)
• Meta (617-619)
• Meta (651-662)

apps/api/plane/db/models/issue.py (2)

• Meta (168-172)
• Issue (100-242)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Build packages
• GitHub Check: Analyze (javascript)

🔇 Additional comments (3)

apps/api/plane/api/serializers/issue.py (2)

68-68: LGTM!

The exclude list correctly reflects the model field rename from description to description_json.

---

636-636: LGTM!

The field mapping maintains API backward compatibility by exposing description_json under the description key for clients consuming the expand serializer. The read-only designation is appropriate for this context.

apps/api/plane/api/serializers/intake.py (1)

16-17: LGTM!

The field mapping correctly handles backward compatibility by allowing clients to continue sending description while internally mapping to the new description_json model field. The required=False, allow_null=True settings are appropriate for optional description content.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}