Skip to content

Conversation

@NarayanBavisetti
Copy link
Collaborator

@NarayanBavisetti NarayanBavisetti commented Dec 3, 2025

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

  • Refactor
    • Updated internal description field naming across the system for improved data structure consistency. This includes changes to how descriptions are stored, processed, and transmitted through the API, along with a corresponding database migration to support the updated field structure.

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

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 3, 2025

📝 Walkthrough

Walkthrough

This PR systematically renames the description field to description_json across the entire codebase, including database models, Django migrations, backend serializers and views, background tasks, frontend stores, and type definitions.

Changes

Cohort / File(s) Summary
Database Model & Migration
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
Adds Django migration renaming descriptiondescription_json on DraftIssue, Issue, and Page models. All three models update their field signatures and maintain JSONField type with default=dict.
Backend API Serializers
apps/api/plane/api/serializers/intake.py, apps/api/plane/api/serializers/issue.py, apps/api/plane/app/serializers/issue.py, apps/api/plane/app/serializers/page.py, apps/api/plane/space/serializer/issue.py
Updates serializer Meta.fields and Meta.exclude lists to reference description_json instead of description across IssueForIntakeSerializer, IssueSerializer, IssueFlatSerializer, PageSerializer, and PageBinaryUpdateSerializer.
Backend API Views
apps/api/plane/api/views/intake.py, apps/api/plane/app/views/intake/base.py, apps/api/plane/app/views/page/base.py, apps/api/plane/space/views/intake.py, apps/api/plane/space/views/issue.py
Intake and page creation/update flows now assign and retrieve description_json instead of description. Query projections and context keys updated accordingly.
Backend 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
Background job processing now fetches and assigns description_json when syncing description versions, copying S3 objects, and seeding workspace pages.
Backend Services & Type Definitions
apps/live/src/controllers/document.controller.ts, apps/live/src/extensions/database.ts, apps/live/src/services/page/core.service.ts
Document controller and database extension now yield/construct payloads with description_json. PageCoreService.updateDescriptionBinary signature updated to accept TDocumentPayload instead of TPageDescriptionPayload.
Frontend Type Definitions
packages/types/src/page/core.ts
Public types TPage and TDocumentPayload updated to use description_json property instead of description.
Frontend Stores & Utilities
apps/web/core/store/pages/base-page.ts, apps/web/core/hooks/use-page-fallback.ts, packages/editor/src/core/helpers/yjs-utils.ts
BasePage class and editor utilities now reference description_json in declarations, constructors, observables, JSON output, and conversion helper return values.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Poem

🐰 A field once called description, plain and bright,
Now wears the name description_json with delight!
Across the code, a rabbit hops with cheer,
From models to views, the rename's crystal clear. ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 41.18% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: renaming the description field to description_json across models.
Description check ✅ Passed The PR description includes all required sections: a detailed description explaining the rationale, and a type of change checkbox properly marked as 'Improvement'.
✨ 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 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.


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

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

@NarayanBavisetti NarayanBavisetti added the 🔄migrations Contains Migration changes label Dec 3, 2025
@NarayanBavisetti NarayanBavisetti marked this pull request as ready for review January 3, 2026 11:55
Copilot AI review requested due to automatic review settings January 3, 2026 11:55
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

name: observable.ref,
logo_props: observable.ref,
description: observable,
description_json: observable.ref,
Copy link

Copilot AI Jan 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,

Copilot uses AI. Check for mistakes.
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔄migrations Contains Migration changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants