Provider implements a include filter to define relevant notifications #91
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@glennmatthews , take this as a proposal, it's just a draft, I will add tests and improve it (I believe it's time to make the keywords data type standard), but just raising to get early feedback on the overall idea |
| @@ -49,6 +50,10 @@ class GenericProvider(BaseModel): | |||
| that will be used. Default: `[SimpleProcessor(data_parsers=[ICal])]`. | |||
| _default_organizer (optional): Defines a default `organizer`, an email address, to be used to create a | |||
| `Maintenance` in absence of the information in the original notification. | |||
| _include_filter (optional): Dictionary that defines matching string per data type to take a notification into | |||
| account. | |||
There was a problem hiding this comment.
Would be good to flesh this out with an example or two - it's not obvious from just reading this how a valid _include_filter would be structured.
| @@ -172,6 +214,8 @@ class HGC(GenericProvider): | |||
| class Lumen(GenericProvider): | |||
| """Lumen provider custom class.""" | |||
|
|
|||
| _include_filter = {EMAIL_HEADER_SUBJECT: ["Scheduled Maintenance Window"]} | |||
There was a problem hiding this comment.
Looking at more examples that I have locally, I think just "Scheduled Maintenance" would be better here. I see some subject lines like Lumen Scheduled Maintenance #: 22194642, Scheduled that appear to me to be valid maintenance notifications.
…f github.com:networktocode/circuitmaint-parser into enable-filtering-relevant-notifications-per-provider
glennmatthews
previously approved these changes
Oct 1, 2021
Co-authored-by: Glenn Matthews <[email protected]>
chadell
deleted the
enable-filtering-relevant-notifications-per-provider
branch
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addressing #82
The goal is to make the
Providercapable of filtering in (and implicitly out), which are the relevant notifications that must be parsed and if not successful aProviderErrormust be raised.With the
_include_filterdictionary, theProvidercan define a dictionary of different data_type to match some string in, and if the filter exists, and the notification doens't match, instead of raising error, returns an empty list ofMaintenancesTODO, once approach is approved: