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

using message decorator hides "source" field #3584

Closed
jalogisch opened this Issue Mar 7, 2017 · 0 comments

Comments

Projects
None yet
3 participants
@jalogisch
Member

jalogisch commented Mar 7, 2017

Expected Behavior

using a decorator should only change the visibility of fields that might be decorated.

Current Behavior

using a decorator hides the source field in the field overview

Possible Solution

some fields are not reserved before the decorator jumps in

rework https://github.com/Graylog2/graylog2-server/blob/master/graylog2-server/src/main/java/org/graylog2/indexer/results/SearchResult.java#L61-L89

Your Environment

  • Graylog Version: 2.2.2

@dennisoelkers dennisoelkers self-assigned this Mar 7, 2017

dennisoelkers added a commit that referenced this issue Mar 7, 2017

Using consistent collection of non displayable fields to filter against.
Before this change, the "source" field was suppressed from being
returned (and therefore) displayed in decorated results. This was caused
by some fields included in the `RESERVED_FIELDS` set, which were not
[added
back](https://github.com/Graylog2/graylog2-server/blob/master/graylog2-server/src/main/java/org/graylog2/indexer/results/SearchResult.java#L79-L84)
from the decorator processor before returning the list of fields included
in the search result
(https://github.com/Graylog2/graylog2-server/blob/master/graylog2-server/src/main/java/org/graylog2/decorators/DecoratorProcessorImpl.java#L95-L100)..

This change could have extracted the method used in `SearchResult.java`
into a commonly used helper method used in both code points. This would
have involved a lot of casting/conversion between different
(`ResultMessage`/`ResultMessageSummary`) data types for each returned
message which is decorated, so the impact of deduplication would be
bigger than its benefits. Instead, I cleaned up and (hopefully) made the
sets of fields more expressive and easier to use.

Fixes #3584.

@dennisoelkers dennisoelkers added this to the 2.2.2 milestone Mar 7, 2017

@joschi joschi modified the milestones: 2.2.2, 2.2.3 Mar 7, 2017

@joschi joschi closed this in #3585 Mar 28, 2017

@wafflebot wafflebot bot removed the in progress label Mar 28, 2017

joschi added a commit that referenced this issue Mar 28, 2017

Using consistent collection of non displayable fields to filter again…
…st. (#3585)

Before this change, the "source" field was suppressed from being
returned (and therefore) displayed in decorated results. This was caused
by some fields included in the `RESERVED_FIELDS` set, which were not
added back from the decorator processor before returning the list of fields included
in the search result.

This change could have extracted the method used in `SearchResult.java`
into a commonly used helper method used in both code points. This would
have involved a lot of casting/conversion between different
(`ResultMessage`/`ResultMessageSummary`) data types for each returned
message which is decorated, so the impact of deduplication would be
bigger than its benefits. Instead, I cleaned up and (hopefully) made the
sets of fields more expressive and easier to use.

Fixes #3584

dennisoelkers added a commit that referenced this issue Mar 28, 2017

Using consistent collection of non displayable fields to filter again…
…st. (#3585)

Before this change, the "source" field was suppressed from being
returned (and therefore) displayed in decorated results. This was caused
by some fields included in the `RESERVED_FIELDS` set, which were not
added back from the decorator processor before returning the list of fields included
in the search result.

This change could have extracted the method used in `SearchResult.java`
into a commonly used helper method used in both code points. This would
have involved a lot of casting/conversion between different
(`ResultMessage`/`ResultMessageSummary`) data types for each returned
message which is decorated, so the impact of deduplication would be
bigger than its benefits. Instead, I cleaned up and (hopefully) made the
sets of fields more expressive and easier to use.

Fixes #3584
(cherry picked from commit a724a27)

joschi added a commit that referenced this issue Mar 28, 2017

Using consistent collection of non displayable fields to filter again…
…st (#3668)

Before this change, the "source" field was suppressed from being
returned (and therefore) displayed in decorated results. This was caused
by some fields included in the `RESERVED_FIELDS` set, which were not
added back from the decorator processor before returning the list of fields included
in the search result.

This change could have extracted the method used in `SearchResult.java`
into a commonly used helper method used in both code points. This would
have involved a lot of casting/conversion between different
(`ResultMessage`/`ResultMessageSummary`) data types for each returned
message which is decorated, so the impact of deduplication would be
bigger than its benefits. Instead, I cleaned up and (hopefully) made the
sets of fields more expressive and easier to use.

Fixes #3584
Refs #3585
(cherry picked from commit a724a27)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment