Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.6] Allow fields to be unsearchable #7381

Open
wants to merge 1 commit into
base: 3.6
Choose a base branch
from
Open

Conversation

xiaohutai
Copy link
Member

@xiaohutai xiaohutai commented Mar 20, 2018

This is a new feature in the legacy part of Bolt. The fix was simpler than I thought.

Use Case

For some clients, we add a textarea-type field for notes; however, the search still searches this and highlights the keywords in that field. My initial thought was to set the searchweight to something low, but a low searchweight does not mean it's filtered.

Usage

Add searchable: false to your field definition:

 field_notes: &field_notes
     notes:
         label: Notes
         type: html
         height: 300px
+        searchable: false

search-bois


Update with related Docs PR: bolt/docs#888

@xiaohutai xiaohutai changed the title Allow fields to be unsearchable [3.4] Allow fields to be unsearchable Mar 20, 2018
bobdenotter
bobdenotter previously approved these changes Mar 21, 2018
Copy link
Member

@bobdenotter bobdenotter left a comment

Choose a reason for hiding this comment

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

Implemented both for Storage as well as legacy! 👍

@xiaohutai
Copy link
Member Author

Oi, it's the Storage of the Legacy. I think (only) @rossriley knows how it really works with the new one.

@GwendolenLynch GwendolenLynch changed the base branch from 3.4 to 3.6 March 30, 2018 09:49
@GwendolenLynch GwendolenLynch changed the title [3.4] Allow fields to be unsearchable [3.6] Allow fields to be unsearchable Mar 30, 2018
@GwendolenLynch
Copy link
Contributor

As discussed in #development as this is a feature, we're pushing to unstable … plus we've pushed back on legacy changes for a long while now, so we'll all collaborate on getting this into 3.6 as an update to the new layer.

Copy link
Contributor

@GwendolenLynch GwendolenLynch left a comment

Choose a reason for hiding this comment

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

Migrate to new layer

@stale
Copy link

stale bot commented May 29, 2018

This issue has been automatically marked as stale because it has not had recent activity. Maybe this issue has been fixed in a recent release, or perhaps it is not affecting a lot of people?
It will be closed if no further activity occurs, because we like to keep the issue queue concise and actual.
If you think this issue is still relevant, please let us know. Especially if you’d like to help resolve the issue, either by helping us pinpointing the cause of a bug, or in implementing a fix or new feature.

@stale stale bot added the stale Stale issues & PRs flagged for closing label May 29, 2018
@xiaohutai xiaohutai added the keep label May 29, 2018
@stale stale bot removed the stale Stale issues & PRs flagged for closing label May 29, 2018
@JarJak
Copy link
Member

JarJak commented Sep 12, 2018

I personally think setting searchweight: 0 should do the same trick.

@rossriley
Copy link
Contributor

actually haven't tried that, does it work?

@bobdenotter
Copy link
Member

Setting it to searchweight: 0 means that found terms in the field don't affect the search results. However, these fields will show up in the list of results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants