PR proposal: Enhanced Global Search (Fuzzy Matching, Ranking, Comments) #894

New Issue

OVERLORD · 2026-02-04T21:34:28+03:00

OVERLORD commented

2026-02-04 21:34:28 +03:00

Originally created by @renantmagalhaes on GitHub (Jan 8, 2026).

Proposal: Enhanced Global Search (Fuzzy Matching, Ranking, Comments)

Hi Planka Team,
I've been working on improving the global search functionality to make it more robust and user-friendly. As per the contributing guidelines, I wanted to share my approach and get your feedback before submitting a Pull Request.

The Problem

Currently, the search functionality has a few limitations:

Strict Matching: typos often lead to "no results".
Siloed Ranking: Search results are often grouped by type logic rather than pure relevance (e.g., a partial Board name match might appear above an exact Card name match).
Limited Scope: Card comments are not included in the global search, making it hard to find discussions.

Proposed Solution

I have implemented a solution locally that enhances the existing search with the following features:

Unified Global Ranking:
- Results are prioritized by a relevance score across all entity types (Projects, Boards, Cards).
- Result: An exact card match now correctly prioritizes above a partial board match.
Fuzzy Search:
- Implemented using fuse.js on the backend to handle typos and near-matches.
Deep Content Search:
- Card Comments are now indexed and searchable.
- Text Previews: Matches in descriptions or comments display a limited text snippet (e.g., ...context of the match...) to help users identify the right card.
UI Enhancements:
- Added a dedicated Search Button in the header (between Lock and Notifications) for better discoverability.
- Updated the placeholder to clearly indicate the global scope.

Technical Approach

Backend: Utilizing fuse.js to index accessible Projects, Boards, Cards (and their comments) in-memory during the request.
Frontend: The search result list is sorted by the backend-provided score, ensuring the most relevant item is always at the top.
I believe these changes significantly improve the findability and UX. I would love to hear your thoughts on this approach and if you would be open to a PR!

Thanks!

The commit on my forked project: 4948d86ab1

Originally created by @renantmagalhaes on GitHub (Jan 8, 2026). # Proposal: Enhanced Global Search (Fuzzy Matching, Ranking, Comments) Hi Planka Team, I've been working on improving the global search functionality to make it more robust and user-friendly. As per the contributing guidelines, I wanted to share my approach and get your feedback before submitting a Pull Request. ### The Problem Currently, the search functionality has a few limitations: - **Strict Matching**: typos often lead to "no results". - **Siloed Ranking**: Search results are often grouped by type logic rather than pure relevance (e.g., a partial Board name match might appear above an exact Card name match). - **Limited Scope**: Card comments are not included in the global search, making it hard to find discussions. ### Proposed Solution I have implemented a solution locally that enhances the existing search with the following features: 1. **Unified Global Ranking**: * Results are prioritized by a **relevance score** across all entity types (Projects, Boards, Cards). * *Result*: An exact card match now correctly prioritizes above a partial board match. 2. **Fuzzy Search**: * Implemented using `fuse.js` on the backend to handle typos and near-matches. 3. **Deep Content Search**: * **Card Comments** are now indexed and searchable. * **Text Previews**: Matches in descriptions or comments display a limited text snippet (e.g., `...context of the match...`) to help users identify the right card. 4. **UI Enhancements**: * Added a dedicated **Search Button** in the header (between Lock and Notifications) for better discoverability. * Updated the placeholder to clearly indicate the global scope. ### Technical Approach - **Backend**: Utilizing `fuse.js` to index accessible Projects, Boards, Cards (and their comments) in-memory during the request. - **Frontend**: The search result list is sorted by the backend-provided `score`, ensuring the most relevant item is always at the top. I believe these changes significantly improve the findability and UX. I would love to hear your thoughts on this approach and if you would be open to a PR! Thanks! The commit on my forked project: https://github.com/renantmagalhaes/planka/commit/4948d86ab19e2eeda17373883ff9d18cbe078895 <img width="2414" height="828" alt="Image" src="https://github.com/user-attachments/assets/3d04759e-231e-48f0-b7d1-d270a77a90e4" /> <img width="2436" height="664" alt="Image" src="https://github.com/user-attachments/assets/abb0a7f0-4a02-44b5-9d83-5bfc87294dbf" />

OVERLORD closed this issue

2026-02-04 21:34:31 +03:00

OVERLORD commented

2026-02-04 21:34:36 +03:00

@meltyshev commented on GitHub (Jan 12, 2026):

Hey! Thanks for taking the time to make the proposal 🙏

I've reviewed the fork, and unfortunately we won't be able to merge it.

This approach might work for a small self-hosted setup, but in real production use it would lead to serious performance and memory issues. Fetching all cards and comments into memory (which can grow without limit) and running the search in the Node.js process doesn't scale. Since we're planning a SaaS version and some teams already have a large amount of data, we can't ship an implementation that would introduce these issues.

@meltyshev commented on GitHub (Jan 12, 2026): Hey! Thanks for taking the time to make the proposal 🙏 I've reviewed the fork, and unfortunately we won't be able to merge it. This approach might work for a small self-hosted setup, but in real production use it would lead to serious performance and memory issues. Fetching all cards and comments into memory (which can grow without limit) and running the search in the Node.js process doesn't scale. Since we're planning a SaaS version and some teams already have a large amount of data, we can't ship an implementation that would introduce these issues.

OVERLORD commented

2026-02-04 21:34:39 +03:00

@renantmagalhaes commented on GitHub (Jan 12, 2026):

Hey @meltyshev

That makes total sense! I completely agree that for SaaS or large-scale enterprise setups, the memory overhead of an in-memory search would be a bottleneck.

However, I still believe enhanced search is vital (9ironically, the larger the dataset, the more users rely on robust search and fuzzy matching to find what they need). Moving forward, transitioning to a database-level solution using PostgreSQL’s tsvector or tsquery would be the right path to balance performance with findability.

Thanks for the feedback! I’m currently pivoting to a feature for my instance to view links as cards. It's still in the early stages, but I’ll be sure to reach out with a proposal before submitting the PR next time.

@renantmagalhaes commented on GitHub (Jan 12, 2026): Hey @meltyshev That makes total sense! I completely agree that for SaaS or large-scale enterprise setups, the memory overhead of an in-memory search would be a bottleneck. However, I still believe enhanced search is vital (9ironically, the larger the dataset, the more users rely on robust search and fuzzy matching to find what they need). Moving forward, transitioning to a database-level solution using PostgreSQL’s tsvector or tsquery would be the right path to balance performance with findability. Thanks for the feedback! I’m currently pivoting to a feature for my instance to view links as cards. It's still in the early stages, but I’ll be sure to reach out with a proposal before submitting the PR next time. <img width="923" height="1100" alt="Image" src="https://github.com/user-attachments/assets/dc500704-1fb4-4eb1-b072-96ea95317e04" />

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#894