handling unmapped operators in stix pattern

[mdazam1942]

No description provided.

[codecov]

Codecov Report

Merging #744 (da8bfe6) into develop (73d8673) will increase coverage by 0.98%.
The diff coverage is 89.65%.

@@             Coverage Diff             @@
##           develop     #744      +/-   ##
===========================================
+ Coverage    63.39%   64.37%   +0.98%     
===========================================
  Files          425      425              
  Lines        36859    36518     -341     
===========================================
+ Hits         23368    23510     +142     
+ Misses       13491    13008     -483     

Impacted Files	Coverage Δ
.../async_dummy/stix_translation/query_constructor.py	21.93% <0.00%> (+5.36%)	⬆️
...security_hub/stix_translation/query_constructor.py	0.00% <0.00%> (ø)
...ar_perf_test/stix_translation/query_constructor.py	16.19% <0.00%> (+2.58%)	⬆️
...ronous_dummy/stix_translation/query_constructor.py	21.93% <0.00%> (+5.36%)	⬆️
...les/guardium/stix_translation/query_constructor.py	81.22% <60.00%> (+4.88%)	⬆️
...dules/splunk/stix_translation/query_constructor.py	70.65% <90.00%> (+4.18%)	⬆️
stix_shifter/stix_translation/stix_translation.py	62.99% <100.00%> (-0.90%)	⬇️
...es/alertflex/stix_translation/query_constructor.py	61.72% <100.00%> (+10.08%)	⬆️
...les/arcsight/stix_translation/query_constructor.py	62.45% <100.00%> (+2.45%)	⬆️
...s/aws_athena/stix_translation/query_constructor.py	66.75% <100.00%> (+2.70%)	⬆️
... and 62 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73d8673...da8bfe6. Read the comment docs.

[delliott90]

Infoblox seems to be the only reason you need to allow for dialect-specific operator files. But looking at this original mapping, this seems to be wrong and misleading. GreaterThan, LessThan, and so on are not the same as equals and would be misleading if we treat them as such in the translated query. Would it not have been better to just keep them as unsupported operators or am I missing something? I know you didn't develop this connector, this just jumped out at me is all. I think this connector should have just used the one set of operators and have it a smaller set at that. It also seems like the data source doesn't support any sort of OR operator.

[delliott90]

Showing both of these kind of masks what is actually causing the error. I know in this case that it's the operator, but it might be good to split the errors up, or put some conditions in the error code to choose what gets printed out.

[mdazam1942]

yeah I thought about it. But my intention was showing the users not only the unmapped operators but also the objects that are associated with the error. if this is not the correct approach then sure I can separate the errors.

[delliott90]

I see your point. You want to show the context where that operator is used. Maybe have three conditions for the error message: 1. If you have both unmapped fields and operators, you show what you have here, just replace the wording to read "and" Operators. 2. If you have just unmapped fields, remove any mention of operators. 3. If you have just unmapped operators, remove mention of unmapped objects and properties, but still show the errored query.

[mdazam1942]

updated the error messages