[WEB-5845] chore: changing description field to description json #8230
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit 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. 📝 WalkthroughWalkthroughThis pull request systematically renames the Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~40 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
📜 Recent review detailsConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (1)📚 Learning: 2025-12-23T14:18:32.899ZApplied to files:
🔇 Additional comments (1)
✏️ Tip: You can disable this entire section by setting 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 |
…re-description-field-migration
…re-description-field-migration
…iption-field-migration
There was a problem hiding this comment.
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
descriptiontodescription_jsonin 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.
| name: observable.ref, | ||
| logo_props: observable.ref, | ||
| description: observable, | ||
| description_json: observable.ref, |
There was a problem hiding this comment.
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.
| description_json: observable.ref, | |
| description_json: observable, |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.descriptionfield does not exist.The migration at
apps/api/plane/db/migrations/0077_draftissue_cycle_user_timezone_project_user_timezone_and_more.py:54attempts to accessissue.description, which does not exist in the Issue model. The Issue model only hasdescription_json,description_html,description_stripped, anddescription_binaryfields.This will cause an
AttributeErrorwhen 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
descriptionfield but the DraftIssue model definesdescription_json.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
apps/api/plane/api/serializers/intake.pyapps/api/plane/api/serializers/issue.pyapps/api/plane/api/views/intake.pyapps/api/plane/app/serializers/issue.pyapps/api/plane/app/serializers/page.pyapps/api/plane/app/views/intake/base.pyapps/api/plane/app/views/page/base.pyapps/api/plane/bgtasks/copy_s3_object.pyapps/api/plane/bgtasks/issue_description_version_sync.pyapps/api/plane/bgtasks/issue_description_version_task.pyapps/api/plane/bgtasks/page_version_task.pyapps/api/plane/bgtasks/workspace_seed_task.pyapps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.pyapps/api/plane/db/models/draft.pyapps/api/plane/db/models/issue.pyapps/api/plane/db/models/page.pyapps/api/plane/space/serializer/issue.pyapps/api/plane/space/views/intake.pyapps/api/plane/space/views/issue.pyapps/live/src/controllers/document.controller.tsapps/live/src/extensions/database.tsapps/live/src/services/page/core.service.tsapps/web/core/hooks/use-page-fallback.tsapps/web/core/store/pages/base-page.tspackages/editor/src/core/helpers/yjs-utils.tspackages/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}: Useconsttype parameters for more precise literal inference in TypeScript 5.0+
Use thesatisfiesoperator to validate types without widening them
Leverage inferred type predicates to reduce the need for explicitisreturn types in filter/check functions
UseNoInfer<T>utility to block inference for specific type arguments when they should be determined by other arguments
Utilize narrowing inswitch(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 legacyexperimentalDecorators
Useusingdeclarations for explicit resource management with Disposable pattern instead of manual cleanup (TypeScript 5.2+)
Usewith { type: "json" }for import attributes; avoid deprecatedassertsyntax (TypeScript 5.3/5.8+)
Useimport typeexplicitly when importing types to ensure they are erased during compilation, respectingverbatimModuleSyntaxflag
Use.ts,.mts,.ctsextensions inimport typestatements (TypeScript 5.2+)
Useimport 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 newSetmethods likeunion,intersection, etc., when available (TypeScript 5.5+)
UseObject.groupBy/Map.groupBystandard methods for grouping instead of external libraries (TypeScript 5.4+)
UsePromise.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 viasuperin classes (TypeScript 5....
Files:
packages/types/src/page/core.tspackages/editor/src/core/helpers/yjs-utils.tsapps/web/core/hooks/use-page-fallback.tsapps/live/src/services/page/core.service.tsapps/web/core/store/pages/base-page.tsapps/live/src/extensions/database.tsapps/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.tspackages/editor/src/core/helpers/yjs-utils.tsapps/web/core/hooks/use-page-fallback.tsapps/live/src/services/page/core.service.tsapps/web/core/store/pages/base-page.tsapps/live/src/extensions/database.tsapps/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.tspackages/editor/src/core/helpers/yjs-utils.tsapps/web/core/hooks/use-page-fallback.tsapps/live/src/services/page/core.service.tsapps/web/core/store/pages/base-page.tsapps/live/src/extensions/database.tsapps/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.tspackages/editor/src/core/helpers/yjs-utils.tsapps/web/core/hooks/use-page-fallback.tsapps/live/src/services/page/core.service.tsapps/web/core/store/pages/base-page.tsapps/live/src/extensions/database.tsapps/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.pyapps/api/plane/bgtasks/issue_description_version_task.pyapps/api/plane/api/serializers/issue.pyapps/api/plane/app/serializers/page.pyapps/api/plane/space/views/intake.pyapps/api/plane/app/serializers/issue.pyapps/api/plane/bgtasks/workspace_seed_task.pyapps/api/plane/app/views/page/base.pyapps/api/plane/bgtasks/issue_description_version_sync.pyapps/api/plane/db/migrations/0114_rename_description_draftissue_description_json_and_more.pyapps/api/plane/db/models/draft.pyapps/api/plane/db/models/page.pyapps/api/plane/bgtasks/copy_s3_object.pyapps/api/plane/space/views/issue.pyapps/api/plane/bgtasks/page_version_task.pyapps/api/plane/api/serializers/intake.pyapps/api/plane/api/views/intake.pyapps/api/plane/app/views/intake/base.pyapps/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.pyapps/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=todescription_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/typescorrectly 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
TDocumentPayloadtype annotation enhances type safety, and the field rename fromdescriptiontodescription_jsoncorrectly aligns with the type definition and PR objective.
80-84: LGTM: Payload type annotation and field rename are correct.Consistent with the
fetchDocumentchanges, the explicit type and field rename maintain type safety and align with theTDocumentPayloadinterface.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_jsoninstead ofdescription, matching the return type ofconvertHTMLDocumentToAllFormatswhich returnsTDocumentPayloadwith thedescription_jsonfield.apps/api/plane/bgtasks/page_version_task.py (1)
31-31: LGTM: PageVersion creation now references the correct field.The change from
page.descriptiontopage.description_jsoncorrectly 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 usedescription_json.The Issue creation in the intake POST flow correctly uses
description_jsonfrom the request payload, consistent with the repository-wide field rename.
371-371: LGTM! Intake issue update payload usesdescription_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 exposedescription_json.The serializer field list correctly reflects the model field rename from
descriptiontodescription_json.apps/api/plane/space/serializer/issue.py (1)
196-196: LGTM! Space API IssueFlatSerializer updated to exposedescription_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 usedescription_json.The version update logic correctly assigns
issue.description_jsonto the version record, and the field is properly included in thesave()call'supdate_fieldslist (lines 28-36).apps/api/plane/app/views/page/base.py (1)
131-131: LGTM! Page creation context updated to usedescription_json.The serializer context correctly references
description_jsonwith 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
descriptiontodescription_jsonis correctly applied in both the batch query.only()clause and theIssueDescriptionVersionobject instantiation.Also applies to: 95-95
apps/api/plane/api/serializers/issue.py (1)
68-68: LGTM! Serializer exclusion updated correctly.The
excludelist now properly referencesdescription_jsoninstead ofdescription, 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 referencedescription_jsoninstead ofdescription.apps/api/plane/db/models/page.py (1)
28-28: LGTM! Model field renamed correctly.The field rename from
descriptiontodescription_jsonis properly implemented, preserving theJSONFieldtype and all attributes (default=dict, blank=True). This change is supported by the migration0114_rename_description_draftissue_description_json_and_more.pymentioned 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-documentendpoint (apps/live/src/controllers/document.controller.ts) returnsdescription_jsonanddescription_binaryin 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
descriptiontodescription_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
TDocumentPayloadfrom@plane/types, which promotes type consistency across the codebase and includesdescription_jsonas the new field name.
100-100: LGTM! Method signature aligned with type changes.The method signature correctly uses
TDocumentPayloadwhich includesdescription_jsoninstead of the deprecateddescriptionfield.apps/api/plane/space/views/intake.py (2)
143-143: LGTM! Field reference updated correctly.The
createmethod now correctly usesdescription_jsonfrom 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_jsonas 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
TPagetype now usesdescription_jsonwith 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
TDocumentPayloadtype now correctly usesdescription_json(requiredobjecttype), 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
descriptiontodescription_jsonpreserves 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_jsonfrom context (line 61) and passes it toPage.objects.create(line 71), consistent with the field rename. The flow fordescription_binaryanddescription_htmlremains 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_jsoninstead ofdescription. TheJSONFieldtype 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.refconfiguration 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
updatePageDescriptionnow usesdescription_json(line 62) instead ofdescription, 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_jsonin the payload structure. TheTDocumentPayloadtype definition inpackages/types/src/page/core.tsalready includesdescription_jsonas 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
RenameFieldoperations to rename thedescriptionfield todescription_jsonfor 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:
- All code references to the old
descriptionfield have been updated across serializers, views, models, and client code.- The migration has been tested in a staging environment before production deployment.
- 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_jsonJSONField is correctly defined with appropriate parameters. Django's JSONField handles thedefault=dictsafely by creating new dict instances for each model instance.
NarayanBavisetti
requested review from
Prashant-Surya,
dheeru0198 and
sriramveeraghanta
NarayanBavisetti
changed the title
|
Linked to Plane Work Item(s) This comment was auto-generated by Plane |
…iption-field-migration
…iption-field-migration
There was a problem hiding this comment.
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
📒 Files selected for processing (4)
apps/api/plane/api/serializers/intake.pyapps/api/plane/api/serializers/issue.pyapps/api/plane/api/views/intake.pyapps/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.pyapps/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
descriptiontodescription_json.
636-636: LGTM!The field mapping maintains API backward compatibility by exposing
description_jsonunder thedescriptionkey 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
descriptionwhile internally mapping to the newdescription_jsonmodel field. Therequired=False, allow_null=Truesettings are appropriate for optional description content.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
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
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.