[WEB-5537]refactor: rename IssueUserProperty to ProjectUserProperty and update related references

[pablohashescobar]

Description

• rename IssueUserProperty to ProjectUserProperty
• add fields sort_order and preferences to ProjectUserProperty
• migration script for migrating data from ProjectMembers to ProjectUserProperty
• change references of IssueUserProperty to ProjectUserProperty

Type of Change

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

Test Scenarios

• project workitem grouping and filtering
• project sorting in the sidebar

References

WEB-5537

---

Note

Renames IssueUserProperty to ProjectUserProperty across backend, adds preferences and sort_order with data migrations, updates related endpoints and member flows, and adds allowed_rate_limit to APIToken.

• Models & Migrations
  • Rename IssueUserProperty → ProjectUserProperty (table to project_user_properties), update relations/constraints and serializer names.
  • Add preferences and sort_order to ProjectUserProperty; migrate values from ProjectMember (bulk update).
  • Add APIToken.allowed_rate_limit and migrate existing non-service tokens to null workspace.
  • Remove IssueUserProperty model; expose ProjectUserProperty from db.models.project.
• API & Endpoints
  • Replace IssueUserDisplayPropertyEndpoint with ProjectUserDisplayPropertyEndpoint at workspaces/<slug>/projects/<project_id>/user-properties/ (partial update via serializer; creates if missing).
  • Update imports/usages in issue/project views, serializers, and URLs to use ProjectUserProperty.
• Project membership & seeding
  • On project create/member add/invite accept/seed: create ProjectUserProperty records; compute sort_order using member’s workspace min where applicable.
  • ProjectMember.save now auto-creates corresponding ProjectUserProperty with derived sort_order.
  • Management command create_project_member now targets ProjectUserProperty.
• Tests
  • Contract tests updated to assert creation of ProjectUserProperty for project members.

^{Written by Cursor Bugbot for commit d75efb3. This will update automatically on new commits. Configure here.}

Summary by CodeRabbit

• New Features

  • Per-project user preferences now include navigation settings and persistent sort order.

• Improvements

  • Member ordering and onboarding produce more consistent member lists.
  • UI tab preferences persist at the project level for consistent navigation across sessions.
  • Invitation and member join flows align with project-level preferences.

• Database Migrations

  • Migrations consolidate existing per-user project properties, add preferences and sort-order fields, and migrate prior values.

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

[makeplane]

Linked to Plane Work Item(s)

• [WEB-5537] Change IssueUserProperty to ProjectUserProperty

This comment was auto-generated by Plane

[coderabbitai]

📝 Walkthrough

Walkthrough

Replaces IssueUserProperty with ProjectUserProperty: removes the old model, adds ProjectUserProperty (preferences, sort_order), updates models, views, serializers, URLs, tasks, CLI, migrations, tests, and frontend types/hooks; includes data migrations to transfer existing values.

Changes

Cohort / File(s)	Summary
Database models & exports apps/api/plane/db/models/issue.py, apps/api/plane/db/models/project.py, apps/api/plane/db/models/__init__.py	Removes IssueUserProperty; adds ProjectUserProperty (fields: preferences, sort_order, JSON defaults); updates exports and ProjectMember.save to create/use ProjectUserProperty. Schema/table and model location changed.
Migrations apps/api/plane/db/migrations/0114_*.py, apps/api/plane/db/migrations/0115_*.py	0114 renames table/model and adds fields/constraints; 0115 migrates preferences/sort_order from members to properties and adjusts API tokens. Contains RunPython data migrations.
Views & API logic apps/api/plane/api/views/project.py, apps/api/plane/app/views/project/..., apps/api/plane/app/views/issue/...	Replaces imports/usages of IssueUserProperty with ProjectUserProperty; removes some property creation during project creation; renames IssueUserDisplayPropertyEndpoint → ProjectUserDisplayPropertyEndpoint. Check project creation, invite, and member flows.
Serializers, URLs & public exports apps/api/plane/app/serializers/issue.py, apps/api/plane/app/serializers/__init__.py, apps/api/plane/app/urls/issue.py, apps/api/plane/app/views/__init__.py	Renames IssueUserPropertySerializer → ProjectUserPropertySerializer; updates URL to use ProjectUserDisplayPropertyEndpoint; updates module-level exports.
Background tasks & CLI apps/api/plane/bgtasks/workspace_seed_task.py, apps/api/plane/db/management/commands/create_project_member.py	Seed and CLI now bulk-create / get_or_create ProjectUserProperty; removed some sort_order computation in management command.
Member flows & invites apps/api/plane/app/views/project/invite.py, apps/api/plane/app/views/project/member.py	Bulk_create now creates ProjectUserProperty records; post-join member creation uses project_id (not workspace_id); new min-based sort_order logic via ProjectUserProperty. Review sorting and property-sync logic.
Tests & frontend types/hooks apps/api/plane/tests/contract/app/test_project_app.py, apps/web/core/components/navigation/use-tab-preferences.ts, packages/types/src/view-props.ts, packages/types/src/project/projects.ts	Tests updated to expect ProjectUserProperty; frontend hook switched to use project user properties and updated preferences payload; new IProjectUserPropertiesResponse added; removed ProjectPreferences type.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐇 I hopped from Issue to Project with a twitch of my whiskers,
New fields tucked in pockets, sort orders like whisker-kissers.
Migrations that hum, serializers that sing,
Preferences now bundled — a neat little thing.
A carrot for the code, and a happy small spring.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% 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 IssueUserProperty to ProjectUserProperty and updating references throughout the codebase.
Description check	✅ Passed	The description covers all required template sections with sufficient detail: lists key changes (rename, new fields, migrations), identifies the type of change (Improvement and Code refactoring), describes test scenarios, and provides references to the issue.

✨ 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 2ce67a1 and ffb017f.

📒 Files selected for processing (1)

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Enable TypeScript strict mode and ensure all files are fully typed

Files:

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.ts

🧠 Learnings (1)

📓 Common learnings

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.

🧬 Code graph analysis (1)

apps/web/core/components/navigation/use-tab-preferences.ts (3)

apps/web/core/services/project/project.service.ts (2)

• getProjectUserProperties (95-101)
• updateProjectUserProperties (103-113)

apps/web/core/components/navigation/tab-navigation-utils.ts (2)

• DEFAULT_TAB_KEY (9-9)
• TTabPreferences (2-5)

apps/space/core/store/publish/publish.store.ts (1)

• workspaceSlug (93-95)

⏰ 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: check:types
• GitHub Check: check:lint
• GitHub Check: Analyze (javascript)

🔇 Additional comments (4)

apps/web/core/components/navigation/use-tab-preferences.ts (4)

24-38: LGTM!

The store access changes align well with the backend refactoring from IssueUserProperty to ProjectUserProperty. The nested navigation preferences structure matches the expected API contract, and the fallback values are appropriate.

---

40-48: LGTM!

The memoization dependencies are correct, and the loading state logic properly handles the case where preferences haven't been fetched yet.

---

53-63: LGTM!

The nested preferences structure correctly matches the expected API contract. Preserving existing pages preferences with a fallback prevents unintentional data loss.

---

69-88: LGTM!

The async error handling with .then()/.catch() is correct. The return; on line 79 is unnecessary but harmless.

---

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.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

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

35-39: New allowed_rate_limit field is consistent with migration; consider minor cleanups

The allowed_rate_limit CharField with default "60/min" looks fine and matches the migration; this should be safe for existing tokens. You may also want to (optionally) add help_text clarifying the expected format and fix the existing typo "API Tokems" in verbose_name_plural while you’re in this model.

apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (1)

1-38: Migration sequence and new fields look consistent with the model changes

The migration cleanly renames the IssueUserProperty table/model to ProjectUserProperty and adds the allowed_rate_limit, preferences, and sort_order fields in line with the model definitions. If you want extra long‑term safety, you could inline a simple dict default for preferences in this migration instead of importing get_default_preferences, but it’s not strictly required.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8db95d9 and 6a09e51.

📒 Files selected for processing (16)

• apps/api/plane/api/views/project.py (3 hunks)
• apps/api/plane/app/serializers/issue.py (2 hunks)
• apps/api/plane/app/urls/issue.py (1 hunks)
• apps/api/plane/app/views/issue/base.py (3 hunks)
• apps/api/plane/app/views/project/base.py (3 hunks)
• apps/api/plane/app/views/project/invite.py (2 hunks)
• apps/api/plane/app/views/project/member.py (3 hunks)
• apps/api/plane/bgtasks/workspace_seed_task.py (2 hunks)
• apps/api/plane/db/management/commands/create_project_member.py (2 hunks)
• apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (1 hunks)
• apps/api/plane/db/migrations/0114_auto_20251201_0857.py (1 hunks)
• apps/api/plane/db/models/__init__.py (1 hunks)
• apps/api/plane/db/models/api.py (1 hunks)
• apps/api/plane/db/models/issue.py (0 hunks)
• apps/api/plane/db/models/project.py (1 hunks)
• apps/api/plane/tests/contract/app/test_project_app.py (3 hunks)

💤 Files with no reviewable changes (1)

• apps/api/plane/db/models/issue.py

🧰 Additional context used

🧠 Learnings (3)

📚 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/app/views/project/member.py
• apps/api/plane/app/serializers/issue.py
• apps/api/plane/api/views/project.py
• apps/api/plane/tests/contract/app/test_project_app.py
• apps/api/plane/bgtasks/workspace_seed_task.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/api/views/project.py
• apps/api/plane/app/views/issue/base.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

🧬 Code graph analysis (14)

apps/api/plane/app/views/project/member.py (1)

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

• Project (64-158)
• ProjectUserProperty (317-348)

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

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

• ProjectUserProperty (317-348)

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

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

• ProjectUserProperty (317-348)

apps/api/plane/db/management/commands/create_project_member.py (1)

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

• ProjectUserProperty (317-348)

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

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

• IssueUserDisplayPropertyEndpoint (718-735)

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

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

• ProjectUserProperty (317-348)

apps/api/plane/app/views/project/base.py (3)

• create (238-299)
• create (501-508)
• create (578-606)

apps/api/plane/db/migrations/0114_auto_20251201_0857.py (2)

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

• ProjectMember (191-235)
• ProjectUserProperty (317-348)

apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (1)

• Migration (8-38)

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

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

• ProjectUserProperty (317-348)

apps/api/plane/tests/contract/app/test_project_app.py (1)

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

• ProjectUserProperty (317-348)

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

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

• ProjectUserProperty (317-348)

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

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

• get_default_filters (43-54)
• get_default_display_filters (57-66)
• get_default_display_properties (69-84)

apps/api/plane/app/views/project/base.py (2)

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

• ProjectUserProperty (317-348)

apps/api/plane/app/views/project/member.py (1)

• create (42-150)

apps/api/plane/app/views/project/invite.py (1)

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

• ProjectUserProperty (317-348)

apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (2)

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

• Migration (31-42)

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

• get_default_preferences (60-61)

⏰ 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). (4)

• GitHub Check: Agent
• GitHub Check: Cursor Bugbot
• GitHub Check: Lint API
• GitHub Check: Analyze (javascript)

🔇 Additional comments (22)

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

211-217: Comment rename correctly reflects underlying model

The updated ## ProjectUserProperty comments around the user-properties/ route align with the new model name and keep the URL behavior unchanged.

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

48-56: Public model surface correctly switched to ProjectUserProperty

Exporting ProjectUserProperty from .project (with IssueUserProperty no longer present) correctly aligns the public API with the new model.

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

16-41: Model import updated correctly to ProjectUserProperty

Switching the import in plane.db.models from the old property model to ProjectUserProperty keeps this serializer file aligned with the new model layout.

---

349-353: IssueUserPropertySerializer now bound to ProjectUserProperty

Pointing the serializer’s Meta.model to ProjectUserProperty matches the refactor and stays compatible with existing views that use this serializer. The read_only_fields list still matches the new model’s base fields, so no further changes seem necessary.

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

24-37: Project creation flow now correctly seeds ProjectUserProperty

Importing and creating ProjectUserProperty for the creator (and distinct project lead) keeps per-user project properties in sync with the new model and respects the unique (user, project) constraint. The conditional on project_lead still prevents duplicate records for the same user.

Also applies to: 245-266

apps/api/plane/db/management/commands/create_project_member.py (1)

6-12: Management command now seeds ProjectUserProperty instead of IssueUserProperty

Updating the import and using ProjectUserProperty.objects.get_or_create(user=user, project=project) keeps this command aligned with the new model while preserving idempotent behavior.

Also applies to: 69-71

apps/api/plane/tests/contract/app/test_project_app.py (1)

6-13: Tests correctly updated to assert ProjectUserProperty creation

Switching the import and expectations from IssueUserProperty to ProjectUserProperty matches the refactor: you now assert a property for the creator and two properties when a distinct project lead is set, which aligns with the updated create flow.

Also applies to: 80-87, 116-121

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

23-23: LGTM!

The import correctly references the renamed ProjectUserProperty model.

---

121-160: LGTM!

The bulk creation correctly uses ProjectUserProperty instead of IssueUserProperty. The new fields preferences and sort_order are not explicitly set, which is acceptable as they have sensible defaults defined in the model.

apps/api/plane/app/views/issue/base.py (3)

54-54: LGTM!

Import correctly updated to ProjectUserProperty.

---

720-729: LGTM!

The patch method correctly uses ProjectUserProperty.objects.get() and accesses fields that exist in the new model definition. Note that the serializer is still named IssueUserPropertySerializer, which appears to be intentional as it's not part of this refactor's scope.

---

732-735: LGTM!

The get method correctly uses ProjectUserProperty.objects.get_or_create() with appropriate fields matching the model's unique constraints.

apps/api/plane/app/views/project/member.py (3)

16-16: LGTM!

Import statement correctly includes ProjectUserProperty.

---

121-127: LGTM!

ProjectUserProperty instantiation correctly sets the required fields. The new fields preferences and sort_order will use their default values, consistent with the pattern used elsewhere in the codebase.

---

132-132: LGTM!

bulk_create correctly uses ProjectUserProperty with appropriate parameters including ignore_conflicts=True to handle the unique constraint on user and project.

apps/api/plane/api/views/project.py (3)

21-21: LGTM!

Import correctly updated to ProjectUserProperty.

---

220-220: LGTM!

ProjectUserProperty creation for the requesting user correctly sets project_id and user. The new fields will use their default values.

---

231-234: LGTM!

ProjectUserProperty creation for the project lead is correctly implemented with appropriate conditional logic. Using user_id as a keyword argument is valid.

apps/api/plane/db/migrations/0114_auto_20251201_0857.py (2)

5-28: LGTM!

The data migration correctly copies preferences and sort_order from ProjectMember to ProjectUserProperty for matching user-project pairs. The implementation is efficient using dictionary-based lookups and bulk updates with an appropriate batch size.

---

31-42: LGTM!

The migration structure is correct with appropriate dependency on the previous migration and a no-op reverse operation, which is standard for data migrations.

apps/api/plane/app/views/project/invite.py (2)

27-27: LGTM!

Import correctly updated to ProjectUserProperty.

---

163-174: LGTM!

The bulk creation of ProjectUserProperty is correctly implemented with appropriate fields and ignore_conflicts=True to handle the unique constraint on user and project.

[sriramveeraghanta]

@pablohashescobar Update the ProjectUserProperty Serializers to support updating the additional properties.

[Copilot]

Pull request overview

This PR refactors the IssueUserProperty model to ProjectUserProperty, reflecting its broader scope beyond issue-specific properties. The refactoring includes adding preferences and sort_order fields migrated from ProjectMember, and also adds allowed_rate_limit to the APIToken model.

Key changes:

• Renamed IssueUserProperty to ProjectUserProperty and moved from issue.py to project.py
• Added preferences and sort_order fields to ProjectUserProperty, populated via data migration from ProjectMember
• Updated all references across views, serializers, tests, management commands, and background tasks

Reviewed changes

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

Show a summary per file

File	Description
apps/api/plane/db/models/issue.py	Removed IssueUserProperty model definition
apps/api/plane/db/models/project.py	Added ProjectUserProperty model with additional fields
apps/api/plane/db/models/init.py	Updated import from IssueUserProperty to ProjectUserProperty
apps/api/plane/db/models/api.py	Added allowed_rate_limit field to APIToken
apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py	Migration to rename model, alter table, and add new fields
apps/api/plane/db/migrations/0114_alter_projectuserproperty_options_and_more.py	Data migration from ProjectMember to ProjectUserProperty
apps/api/plane/app/serializers/issue.py	Updated IssueUserPropertySerializer to use ProjectUserProperty model
apps/api/plane/app/views/issue/base.py	Updated references to use ProjectUserProperty
apps/api/plane/app/views/project/base.py	Updated project creation to use ProjectUserProperty
apps/api/plane/app/views/project/member.py	Updated member addition to use ProjectUserProperty
apps/api/plane/app/views/project/invite.py	Updated invite acceptance to use ProjectUserProperty
apps/api/plane/api/views/project.py	Updated API project creation to use ProjectUserProperty
apps/api/plane/bgtasks/workspace_seed_task.py	Updated seed task to use ProjectUserProperty
apps/api/plane/db/management/commands/create_project_member.py	Updated management command to use ProjectUserProperty
apps/api/plane/app/urls/issue.py	Updated comments to reflect rename
apps/api/plane/tests/contract/app/test_project_app.py	Updated tests to assert ProjectUserProperty creation

---

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

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a09e51 and e43d9b6.

📒 Files selected for processing (3)

• apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (1 hunks)
• apps/api/plane/db/migrations/0114_alter_projectuserproperty_options_and_more.py (1 hunks)
• apps/api/plane/db/models/project.py (1 hunks)

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

• apps/api/plane/db/models/project.py

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

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.

🧬 Code graph analysis (2)

apps/api/plane/db/migrations/0114_alter_projectuserproperty_options_and_more.py (2)

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

• ProjectMember (191-235)
• ProjectUserProperty (317-348)

apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (1)

• Migration (8-54)

apps/api/plane/db/migrations/0113_alter_issueuserproperty_table.py (2)

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

• Migration (31-39)

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

• get_default_preferences (60-61)

⏰ 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 (python)
• GitHub Check: Agent
• GitHub Check: Cursor Bugbot

[cursor]

This is the final PR Bugbot will review for you during this billing cycle

Your free Bugbot reviews will reset on December 20

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f75d40f and d874227.

📒 Files selected for processing (5)

• apps/api/plane/app/serializers/__init__.py (1 hunks)
• apps/api/plane/app/serializers/issue.py (2 hunks)
• apps/api/plane/app/urls/issue.py (2 hunks)
• apps/api/plane/app/views/__init__.py (1 hunks)
• apps/api/plane/app/views/issue/base.py (3 hunks)

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

• apps/api/plane/app/serializers/issue.py
• apps/api/plane/app/views/issue/base.py

🧰 Additional context used

🧠 Learnings (1)

📚 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/app/serializers/__init__.py

🧬 Code graph analysis (3)

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

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

• ProjectUserPropertySerializer (349-353)

apps/api/plane/app/views/__init__.py (1)

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

• ProjectUserDisplayPropertyEndpoint (718-735)

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

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

• ProjectUserDisplayPropertyEndpoint (718-735)

⏰ 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: Analyze (javascript)
• GitHub Check: Cursor Bugbot

🔇 Additional comments (2)

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

55-55: LGTM!

The serializer rename correctly reflects the model rename from IssueUserProperty to ProjectUserProperty.

apps/api/plane/app/views/__init__.py (1)

118-118: LGTM!

The public export correctly reflects the endpoint rename from IssueUserDisplayPropertyEndpoint to ProjectUserDisplayPropertyEndpoint, maintaining consistency with the model rename.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

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

718-745: Endpoint now supports updating new fields; consider minor cleanups

The renamed ProjectUserDisplayPropertyEndpoint now uses ProjectUserPropertySerializer with partial=True, so preferences and sort_order (and other writable fields) can be updated via PATCH, which addresses the earlier review concern. You could optionally:

• Replace the explicit try/except + create in patch with a single get_or_create call (to mirror get and reduce duplication).
• Rename issue_property to project_user_property or user_property for clarity post‑refactor.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d874227 and 280c3ce.

📒 Files selected for processing (1)

• apps/api/plane/app/views/issue/base.py (3 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 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/app/views/issue/base.py

🧬 Code graph analysis (1)

apps/api/plane/app/views/issue/base.py (2)

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

• ProjectUserPropertySerializer (349-353)
• create (194-269)
• create (580-583)

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

• ProjectUserProperty (317-348)

⏰ 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: Cursor Bugbot
• GitHub Check: Analyze (javascript)

🔇 Additional comments (1)

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

37-38: Imports correctly updated to ProjectUserProperty model/serializer

The imports for ProjectUserPropertySerializer and ProjectUserProperty are consistent with the refactor and are used appropriately in this module; no issues from this change set.

Also applies to: 54-59

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

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

221-234: Consider using get_or_create() to prevent IntegrityError in edge cases.

The ProjectMember.save() method uses .create() when creating the associated ProjectUserProperty. While the if self._state.adding check ensures this only runs for new members, edge cases could still cause issues:

1. Race conditions: If two concurrent requests create the same project member, both might attempt to create ProjectUserProperty, causing one to fail with an IntegrityError.
2. Manual creation: If ProjectUserProperty is created manually (e.g., in migrations or data scripts) before ProjectMember is saved, the subsequent save will fail.

Using get_or_create() would make this code more robust:

ProjectUserProperty.objects.get_or_create(
    workspace_id=self.project.workspace_id,
    project=self.project,
    user=self.member,
    defaults={
        'sort_order': (min_sort_order - 10000 if min_sort_order is not None else 65535),
    }
)

🔎 Proposed refactor using get_or_create

         if self._state.adding and self.member:
             # Get the minimum sort_order for this member in the workspace
             min_sort_order_result = ProjectUserProperty.objects.filter(
                 workspace_id=self.project.workspace_id, user=self.member
             ).aggregate(min_sort_order=models.Min("sort_order"))
             min_sort_order = min_sort_order_result.get("min_sort_order")
 
             # create project user property with project sort order
-            ProjectUserProperty.objects.create(
+            ProjectUserProperty.objects.get_or_create(
                 workspace_id=self.project.workspace_id,
                 project=self.project,
                 user=self.member,
-                sort_order=(min_sort_order - 10000 if min_sort_order is not None else 65535),
+                defaults={
+                    'sort_order': (min_sort_order - 10000 if min_sort_order is not None else 65535),
+                }
             )

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3d7212b and da31afa.

📒 Files selected for processing (9)

• apps/api/plane/api/views/project.py
• apps/api/plane/app/views/__init__.py
• apps/api/plane/app/views/issue/base.py
• apps/api/plane/app/views/project/base.py
• apps/api/plane/app/views/project/member.py
• apps/api/plane/bgtasks/workspace_seed_task.py
• apps/api/plane/db/models/__init__.py
• apps/api/plane/db/models/issue.py
• apps/api/plane/db/models/project.py

💤 Files with no reviewable changes (1)

• apps/api/plane/db/models/issue.py

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

• apps/api/plane/app/views/project/base.py
• apps/api/plane/app/views/issue/base.py
• apps/api/plane/app/views/project/member.py

🧰 Additional context used

🧠 Learnings (4)

📚 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/views/project.py
• apps/api/plane/bgtasks/workspace_seed_task.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/api/views/project.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/views/project.py
• apps/api/plane/app/views/__init__.py
• apps/api/plane/db/models/project.py
• apps/api/plane/bgtasks/workspace_seed_task.py
• apps/api/plane/db/models/__init__.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

🧬 Code graph analysis (4)

apps/api/plane/api/views/project.py (1)

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

• ProjectUserProperty (336-367)

apps/api/plane/app/views/__init__.py (1)

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

• ProjectUserDisplayPropertyEndpoint (726-753)

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

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

• get_default_filters (43-54)
• get_default_display_filters (57-66)
• get_default_display_properties (69-84)

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

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

• ProjectUserProperty (336-367)

⏰ 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 (7)

apps/api/plane/app/views/__init__.py (1)

117-117: LGTM! Export correctly reflects the endpoint rename.

The updated export from IssueUserDisplayPropertyEndpoint to ProjectUserDisplayPropertyEndpoint is consistent with the broader refactoring to rename IssueUserProperty to ProjectUserProperty. The implementation in apps/api/plane/app/views/issue/base.py correctly uses the new model and serializer.

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

56-56: LGTM! Clean export update.

The addition of ProjectUserProperty to the project module exports correctly reflects the model rename and relocation from the issue module. The public API surface has been updated consistently.

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

21-21: LGTM! Import updated correctly.

The import change from IssueUserProperty to ProjectUserProperty aligns with the model rename across the codebase.

---

220-229: LGTM! Explicit ProjectUserProperty creation correctly removed.

The removal of explicit ProjectUserProperty.objects.create() calls is correct. Since ProjectMember.save() now automatically creates the corresponding ProjectUserProperty entry (as implemented in apps/api/plane/db/models/project.py lines 221-234), these manual creations are no longer needed. Both the creator and project lead will have ProjectUserProperty records created automatically when their ProjectMember records are created.

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

24-24: LGTM! Import updated correctly.

The import change from IssueUserProperty to ProjectUserProperty is consistent with the model rename.

---

124-163: LGTM! Bulk create correctly uses ProjectUserProperty.

The bulk creation of ProjectUserProperty instances for workspace seed data is correct. Since this is a bulk operation that bypasses ProjectMember.save(), the manual creation is appropriate. The fields passed (project, user_id, workspace_id, display_filters, display_properties, created_by_id) align with the new model definition.

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

336-367: LGTM! ProjectUserProperty model definition is correct.

The new ProjectUserProperty model is well-defined with appropriate fields, constraints, and metadata. The unique constraint ensures one property record per user-project pair, and the sort_order field enables custom project ordering in the UI.

Note: A past review comment flagged a potential circular import issue with the imports on line 337. While that concern is being tracked separately, the model definition itself is correct.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

apps/api/plane/db/migrations/0115_auto_20260105_0836.py (1)

31-39: API token migration seems unrelated to the core PR objective.

This migration updates API token workspace associations, which appears unrelated to the ProjectUserProperty refactor that is the focus of this PR. While the code itself is correct (the filter clause can use user__is_bot to traverse relationships, and the update only touches workspace_id which is directly on APIToken), consider whether this belongs in a separate migration or PR for better separation of concerns.

Note: A similar concern was raised in a past review but was marked as addressed. The current code is syntactically valid Django ORM.

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

14-49: Migration structure looks correct.

The migration properly handles the model rename from IssueUserProperty to ProjectUserProperty with the following operations in the correct order:

1. Table rename to project_user_properties
2. Model rename
3. New fields added (preferences, sort_order)
4. Model options and constraints updated

The past review concern about syntax errors between the AddField and AlterModelOptions operations (line 32) has been addressed—the comma separator is present, making this valid Python syntax. The only minor issue is trailing whitespace on line 32, which doesn't affect functionality.

Optional: Clean up trailing whitespace

         migrations.AddField(
             model_name='projectuserproperty',
             name='sort_order',
             field=models.FloatField(default=65535),
-        ),        
+        ),
         migrations.AlterModelOptions(

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b39c769 and d3a50b7.

📒 Files selected for processing (2)

• apps/api/plane/db/migrations/0114_projectuserproperty_delete_issueuserproperty_and_more.py
• apps/api/plane/db/migrations/0115_auto_20260105_0836.py

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

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.

📚 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/0115_auto_20260105_0836.py
• apps/api/plane/db/migrations/0114_projectuserproperty_delete_issueuserproperty_and_more.py

🧬 Code graph analysis (2)

apps/api/plane/db/migrations/0115_auto_20260105_0836.py (3)

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

• ProjectMember (204-254)
• ProjectUserProperty (336-367)

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

• APIToken (19-44)

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

• Migration (8-50)

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

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

• get_default_preferences (60-61)

⏰ 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: check:lint
• GitHub Check: check:types
• GitHub Check: Analyze (javascript)

🔇 Additional comments (1)

apps/api/plane/db/migrations/0115_auto_20260105_0836.py (1)

5-28: The migration will not fail due to missing fields on ProjectMember.

ProjectMember has both preferences (added in migration 0040) and sort_order (added in migration 0039) fields defined in the model, so the query on line 10 is valid.

However, the function name move_issue_user_properties_to_project_user_properties is misleading—it copies data FROM ProjectMember TO ProjectUserProperty, not from IssueUserProperty. Consider renaming to copy_projectmember_properties_to_projectuserproperty or similar for clarity.

[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/web/core/components/navigation/use-tab-preferences.ts (1)

98-108: Fix async error handling in handleHideTab and handleShowTab.

Both functions call the async updatePreferences without awaiting it inside a try-catch block. This means the try-catch cannot catch any errors from the Promise, as it only covers synchronous code. Any errors will become unhandled promise rejections, and the error toasts will never display.

Compare with handleToggleDefaultTab (lines 72-87), which correctly uses .then().catch() to handle the async operation.

🔎 Proposed fix for both functions

Fix for handleHideTab:

  const handleHideTab = (tabKey: string) => {
    const newPreferences = {
      ...tabPreferences,
      hiddenTabs: [...tabPreferences.hiddenTabs, tabKey],
    };
-   try {
-     updatePreferences(newPreferences);
-   } catch (error) {
-     console.error("Error hiding tab:", error);
-     setToast({
-       type: TOAST_TYPE.ERROR,
-       title: "Error!",
-       message: "Failed to hide tab. Please try again later.",
-     });
-   }
+   updatePreferences(newPreferences)
+     .catch((error) => {
+       console.error("Error hiding tab:", error);
+       setToast({
+         type: TOAST_TYPE.ERROR,
+         title: "Error!",
+         message: "Failed to hide tab. Please try again later.",
+       });
+     });
  };

Fix for handleShowTab:

  const handleShowTab = (tabKey: string) => {
    const newPreferences = {
      ...tabPreferences,
      hiddenTabs: tabPreferences.hiddenTabs.filter((key) => key !== tabKey),
    };
-   try {
-     updatePreferences(newPreferences);
-   } catch (error) {
-     console.error("Error showing tab:", error);
-     setToast({
-       type: TOAST_TYPE.ERROR,
-       title: "Error!",
-       message: "Something went wrong. Please try again later.",
-     });
-   }
+   updatePreferences(newPreferences)
+     .catch((error) => {
+       console.error("Error showing tab:", error);
+       setToast({
+         type: TOAST_TYPE.ERROR,
+         title: "Error!",
+         message: "Something went wrong. Please try again later.",
+       });
+     });
  };

Also applies to: 118-128

🧹 Nitpick comments (1)

apps/web/core/components/navigation/use-tab-preferences.ts (1)

79-79: Optional: Remove unnecessary explicit return.

The explicit return statement doesn't affect control flow or behavior here, as it's the last statement in the .then() callback and the returned value is unused.

🔎 Proposed simplification

        setToast({
          type: TOAST_TYPE.SUCCESS,
          title: "Success!",
          message: "Default tab updated successfully.",
        });
-       return;
      })

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d3a50b7 and 2ce67a1.

📒 Files selected for processing (3)

• apps/web/core/components/navigation/use-tab-preferences.ts
• packages/types/src/project/projects.ts
• packages/types/src/view-props.ts

💤 Files with no reviewable changes (1)

• packages/types/src/project/projects.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/view-props.ts
• apps/web/core/components/navigation/use-tab-preferences.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Enable TypeScript strict mode and ensure all files are fully typed

Files:

• packages/types/src/view-props.ts
• apps/web/core/components/navigation/use-tab-preferences.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/view-props.ts
• apps/web/core/components/navigation/use-tab-preferences.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/view-props.ts
• apps/web/core/components/navigation/use-tab-preferences.ts

🧠 Learnings (1)

📓 Common learnings

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.

🧬 Code graph analysis (2)

packages/types/src/view-props.ts (1)

packages/types/src/project/projects.ts (1)

• IProjectMemberNavigationPreferences (108-111)

apps/web/core/components/navigation/use-tab-preferences.ts (3)

apps/web/core/services/project/project.service.ts (2)

• getProjectUserProperties (95-101)
• updateProjectUserProperties (103-113)

apps/web/core/components/navigation/tab-navigation-utils.ts (2)

• DEFAULT_TAB_KEY (9-9)
• TTabPreferences (2-5)

apps/space/core/store/publish/publish.store.ts (1)

• workspaceSlug (93-95)

⏰ 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 (5)

apps/web/core/components/navigation/use-tab-preferences.ts (3)

26-26: LGTM! Store access correctly refactored.

The migration from project member preferences to project user properties is well-executed. The nested structure (preferences.navigation.default_tab and preferences.navigation.hide_in_more_menu) aligns with the new data model described in the PR objectives.

Also applies to: 36-38

---

43-46: LGTM! Improved memoization.

The dependency array now tracks the specific derived values (defaultTab, hideInMoreMenu) rather than the entire storePreferences object, preventing unnecessary recomputations when unrelated preferences change.

---

54-62: LGTM! Correct update structure.

The update payload correctly spreads existing preferences before setting the navigation sub-object, ensuring other preference fields aren't inadvertently cleared. The structure aligns with the new ProjectUserProperty model.

packages/types/src/view-props.ts (2)

1-1: LGTM: Correct use of type-only import.

The import uses import type as recommended for type-only imports that are erased during compilation.

---

198-206: The preferences field structure correctly matches the backend ProjectUserPropertySerializer. The IProjectMemberNavigationPreferences type includes default_tab (string) and hide_in_more_menu (string[]), which aligns with the default structure returned by get_default_preferences(). No type mismatches exist.

[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 (2)

apps/web/core/components/navigation/use-tab-preferences.ts (2)

93-108: Unhandled Promise rejection: missing await or .catch().

The try-catch block won't catch errors from updatePreferences() because it's an async function returning a Promise. Without await, any rejection becomes an unhandled Promise rejection and the error toast will never display.

This is inconsistent with handleToggleDefaultTab which correctly uses .then()/.catch().

🔎 Proposed fix using async/await

-  const handleHideTab = (tabKey: string) => {
+  const handleHideTab = async (tabKey: string) => {
     const newPreferences = {
       ...tabPreferences,
       hiddenTabs: [...tabPreferences.hiddenTabs, tabKey],
     };
     try {
-      updatePreferences(newPreferences);
+      await updatePreferences(newPreferences);
     } catch (error) {
       console.error("Error hiding tab:", error);
       setToast({
         type: TOAST_TYPE.ERROR,
         title: "Error!",
         message: "Failed to hide tab. Please try again later.",
       });
     }
   };

---

113-128: Same issue: unhandled Promise rejection.

Same problem as handleHideTab — the try-catch won't catch the Promise rejection from updatePreferences().

🔎 Proposed fix using async/await

-  const handleShowTab = (tabKey: string) => {
+  const handleShowTab = async (tabKey: string) => {
     const newPreferences = {
       ...tabPreferences,
       hiddenTabs: tabPreferences.hiddenTabs.filter((key) => key !== tabKey),
     };
     try {
-      updatePreferences(newPreferences);
+      await updatePreferences(newPreferences);
     } catch (error) {
       console.error("Error showing tab:", error);
       setToast({
         type: TOAST_TYPE.ERROR,
         title: "Error!",
         message: "Something went wrong. Please try again later.",
       });
     }
   };

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2ce67a1 and ffb017f.

📒 Files selected for processing (1)

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Enable TypeScript strict mode and ensure all files are fully typed

Files:

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.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:

• apps/web/core/components/navigation/use-tab-preferences.ts

🧠 Learnings (1)

📓 Common learnings

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.

🧬 Code graph analysis (1)

apps/web/core/components/navigation/use-tab-preferences.ts (3)

apps/web/core/services/project/project.service.ts (2)

• getProjectUserProperties (95-101)
• updateProjectUserProperties (103-113)

apps/web/core/components/navigation/tab-navigation-utils.ts (2)

• DEFAULT_TAB_KEY (9-9)
• TTabPreferences (2-5)

apps/space/core/store/publish/publish.store.ts (1)

• workspaceSlug (93-95)

⏰ 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: check:types
• GitHub Check: check:lint
• GitHub Check: Analyze (javascript)

🔇 Additional comments (4)

apps/web/core/components/navigation/use-tab-preferences.ts (4)

24-38: LGTM!

The store access changes align well with the backend refactoring from IssueUserProperty to ProjectUserProperty. The nested navigation preferences structure matches the expected API contract, and the fallback values are appropriate.

---

40-48: LGTM!

The memoization dependencies are correct, and the loading state logic properly handles the case where preferences haven't been fetched yet.

---

53-63: LGTM!

The nested preferences structure correctly matches the expected API contract. Preserving existing pages preferences with a fallback prevents unintentional data loss.

---

69-88: LGTM!

The async error handling with .then()/.catch() is correct. The return; on line 79 is unnecessary but harmless.