[WEB-4857]fix: applied filters root update

[vamsikrishnamathala]

Description

Show save filter view option only in project context by adding store type check, ensuring the feature appears exclusively when both editing permissions are granted and the store type is PROJECT

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Improvement (change that would cause existing functionality to not work as expected)
• Code refactoring
• Performance improvements
• Documentation update

Screenshots and Media (if applicable)

Test Scenarios

References

Summary by CodeRabbit

• Bug Fixes
  • The “Save Filter” option now appears only when editing is allowed in Project views.
  • It is no longer shown in non-Project contexts (e.g., Epic), ensuring context-appropriate visibility.
  • Default behavior for Project views remains unchanged.

[coderabbitai]

Walkthrough

Conditional rendering tightened in ProjectAppliedFiltersRoot: SaveFilterView now renders only when isEditingAllowed is true and storeType === EIssuesStoreType.PROJECT. No other logic or exports changed.

Changes

Cohort / File(s)	Summary
Filters UI gating apps/web/core/components/issues/issue-layouts/filters/applied-filters/roots/project-root.tsx	Added storeType === EIssuesStoreType.PROJECT to the existing isEditingAllowed condition for rendering SaveFilterView; defaults remain unchanged; no API/prop changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• [WEB-3923] fix: applied filters list #6957 — Also modifies ProjectAppliedFiltersRoot to manage filter-editing UI, adding an alwaysAllowEditing prop; closely related control over edit visibility.

Suggested labels

🌐frontend

Suggested reviewers

• sriramveeraghanta

Pre-merge checks (1 passed, 1 warning, 1 inconclusive)

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	The PR description correctly includes a detailed change summary and type of change but leaves the “Test Scenarios” and “References” sections empty, omitting required information about how the fix was verified and the related ticket.	Please add the specific tests you ran to verify the gating behavior in different store types and include a reference link to issue WEB-4857 to complete the template.
Title Check	❓ Inconclusive	The current title “[WEB-4857]fix: applied filters root update” is related to the changeset but remains overly generic and does not clearly convey the specific behavior change of gating the SaveFilterView to the project context.	Consider renaming the title to clearly reflect the main change, for example “fix: show SaveFilterView only in project context” to improve clarity and focus.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

Poem

I twitch my whiskers, flip a bit,
Filters save when they truly fit.
Project burrow? Yes—proceed!
Else I pause my hopping speed.
Small nibble, tidy flow,
Carrots stacked in status quo. 🥕✨

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-applied_filters

---

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

[makeplane]

Pull Request Linked with Plane Work Items

• [WEB-4857] "Save View" option incorrectly displayed in filter view

Comment Automatically Generated by Plane

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

apps/web/core/components/issues/issue-layouts/filters/applied-filters/roots/project-root.tsx (1)

93-104: Also gate on params presence to avoid undefined IDs.

If SaveFilterView expects non-null ids, render only when workspaceSlug and projectId exist; then drop optional chaining.

-        {isEditingAllowed && storeType === EIssuesStoreType.PROJECT && (
+        {isEditingAllowed && storeType === EIssuesStoreType.PROJECT && workspaceSlug && projectId && (
           <SaveFilterView
-            workspaceSlug={workspaceSlug?.toString()}
-            projectId={projectId?.toString()}
+            workspaceSlug={workspaceSlug.toString()}
+            projectId={projectId.toString()}
             filterParams={{
               filters: appliedFilters,
               display_filters: issueFilters?.displayFilters,
               display_properties: issueFilters?.displayProperties,
             }}
             trackerElement={PROJECT_VIEW_TRACKER_ELEMENTS.PROJECT_HEADER_SAVE_AS_VIEW_BUTTON}
           />
         )}

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a8a6536 and 685636a.

📒 Files selected for processing (1)

• apps/web/core/components/issues/issue-layouts/filters/applied-filters/roots/project-root.tsx (1 hunks)

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

• GitHub Check: Build and lint web apps

🔇 Additional comments (2)

apps/web/core/components/issues/issue-layouts/filters/applied-filters/roots/project-root.tsx (2)

93-104: Visibility gate tightened correctly.

Rendering SaveFilterView only when isEditingAllowed and storeType === EIssuesStoreType.PROJECT matches the PR intent and avoids exposing the action in EPIC context.

---

93-104: SaveFilterView not used in EPIC flows. Verified imports of SaveFilterView appear only in project-root.tsx, cycle-root.tsx, and module-root.tsx; no Epic-root or EPIC context references.