[WEB-4757] fix: remove project view from workspace level group by options#7634
[WEB-4757] fix: remove project view from workspace level group by options#7634sriramveeraghanta merged 1 commit intopreviewfrom
Conversation
WalkthroughAdjusted workspace-level determination in apps/web/core/components/issues/issue-layouts/utils.tsx: removed PROJECT_VIEW from the set and added TEAM_PROJECT_WORK_ITEMS and WORKSPACE_DRAFT to the inclusion check for isWorkspaceLevel. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Pull Request Linked with Plane Work Items Comment Automatically Generated by Plane |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/core/components/issues/issue-layouts/utils.tsx (1)
68-76: Make membership check more maintainable (and simplify boolean)Two small improvements:
- Replace the array literal with a Set constant to avoid re-allocation and centralize scope definitions.
- Drop the unnecessary ternary; includes(...) already returns boolean.
Minimal nit to simplify return:
export const isWorkspaceLevel = (type: EIssuesStoreType) => [ EIssuesStoreType.PROFILE, EIssuesStoreType.GLOBAL, EIssuesStoreType.TEAM, EIssuesStoreType.TEAM_VIEW, EIssuesStoreType.TEAM_PROJECT_WORK_ITEMS, EIssuesStoreType.WORKSPACE_DRAFT, ].includes(type) - ? true - : false; + ;Optional refactor to a Set for stability and reuse:
+const WORKSPACE_SCOPES = new Set<EIssuesStoreType>([ + EIssuesStoreType.PROFILE, + EIssuesStoreType.GLOBAL, + EIssuesStoreType.TEAM, + EIssuesStoreType.TEAM_VIEW, + EIssuesStoreType.TEAM_PROJECT_WORK_ITEMS, + EIssuesStoreType.WORKSPACE_DRAFT, +]); + -export const isWorkspaceLevel = (type: EIssuesStoreType) => - [ - EIssuesStoreType.PROFILE, - EIssuesStoreType.GLOBAL, - EIssuesStoreType.TEAM, - EIssuesStoreType.TEAM_VIEW, - EIssuesStoreType.TEAM_PROJECT_WORK_ITEMS, - EIssuesStoreType.WORKSPACE_DRAFT, - ].includes(type) - ? true - : false; +export const isWorkspaceLevel = (type: EIssuesStoreType) => WORKSPACE_SCOPES.has(type);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
apps/web/core/components/issues/issue-layouts/utils.tsx(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: NarayanBavisetti
PR: makeplane/plane#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.
⏰ 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: Build and lint web apps
- GitHub Check: Build and lint web apps
- GitHub Check: Analyze (javascript)
🔇 Additional comments (2)
apps/web/core/components/issues/issue-layouts/utils.tsx (2)
74-76: Correct scope fix: Project View no longer treated as workspace-levelRemoving PROJECT_VIEW from workspace-level and adding TEAM_PROJECT_WORK_ITEMS and WORKSPACE_DRAFT aligns scope semantics. This should fix label grouping by ensuring Project View pulls projectLabels instead of workspaceLabels. Good change.
68-76: No regressions found in workspace-level logic for PROJECT_VIEWAll checks confirm that PROJECT_VIEW remains project-scoped and that label/assignee sources align with isWorkspaceLevel everywhere:
• isWorkspaceLevel’s array excludes PROJECT_VIEW, so any
isWorkspaceLevel(storeType)call returns false for PROJECT_VIEW.
• All components usingisWorkspaceLevel(storeType)correctly passisWorkspaceLevel(storeType)—there are no divergent helpers treating PROJECT_VIEW as workspace-level.
• Filter roots and label dropdowns for PROJECT_VIEW consistently use projectLabels, never workspaceLabels (e.g. in project-view-root.tsx).
• TEAM_PROJECT_WORK_ITEMS and WORKSPACE_DRAFT remain in the workspace-level set and their label scoping follows isWorkspaceLevel (workspaceLabels), with no unintended project-scoped assumptions.No changes required.
Description
Grouping by labels isn’t working in project views. This issue arose because project views were considered as workspace-level grouping options. We were attempting to retrieve workspaceLabelIds from the store instead of relying on projectLabelIds.
Type of Change
Summary by CodeRabbit