ASF GitHub Bot commented on METRON-1548:

Github user merrimanr commented on the issue:

    Most of this worked, I could only find one issue.  We store a user's 
selected columns in local storage right now.  These columns are selected in the 
Configure Table view and the list of available columns comes from a REST call 
that returns ES (or Solr) metadata.  The available column list will always be 
correct since that information is coming straight from the index templates or 
schemas but the column name in local storage will become incorrect since it's 
still the old source type.
    There is an attempt to just transform the name in the selected column list 
but I think this is flawed (I added an inline comment on that).  I am not sure 
what the best way to handle this is.  I feel like if we find ourselves 
hardcoding either "source:type" or "source.type" we're doing something wrong.  
    One idea is to limit the source.type.field property to be either 
"source:type" or "source.type".  This would at least allow us to perform those 
hardcoded checks to see if we need to substitute the new value.  Otherwise 
we'll need to evolve our local storage model by using boolean fields like 
"includeSourceType" instead of the actual source.type.field value.  This would 
make upgrading harder though.

> Alerts UI: Remove hardcoded source:type and other fields that may vary
> ----------------------------------------------------------------------
>                 Key: METRON-1548
>                 URL: https://issues.apache.org/jira/browse/METRON-1548
>             Project: Metron
>          Issue Type: Sub-task
>            Reporter: Justin Leet
>            Priority: Major
> In Solr, we use source.type instead of source:type (which was originally due 
> to ES limitations, we'd prefer it to be common across both). However, it's 
> hardcoded in the alerts UI to be source:type, so nothing in the UI has a 
> source type and it breaks other things like metaalerts (which rely on source 
> type for being able to pull the data together).
> Any other configs / queries that would cause similar problems should be 
> updated appropriately.

This message was sent by Atlassian JIRA

Reply via email to