mesozoic/gmail-yaml-filters

Reverse Nesting

Closed this issue · 3 comments

I was wondering if there is a way to reverse the nesting structure you have. So for example, if any of the following three are true:

  more:
    -
      from:
        not:
          all:
            - test@example.com
            - test@example.com
            -test@example.com
      subject:
        any:
          - "TEST"
          - "Test Test"
          - "TESTESTEST"
  more:
    -
      from:
        any:
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
  more:
    -
      from:
        not:
          all:
            - test@example.com
            - test@example.com
            -test@example.com
      to:
        any:
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"
          - "test@example.com"

So if any of the above three are true, do the following:

  important: true
  label: TEST

Thanks for sending this in! I'm sorry for the delay in responding, but it turns out I needed to tune my GitHub notification settings.

It should be possible to do what you're describing above by creating a top-level rule with no conditions and nesting conditions under more:, but it looks like that won't work. Doing this...

-
  important: true
  label: TEST
  more:
    - from: alice
    - to: bob
    - subject: "TEST"

...ought to have the desired effect, in my opinion, by generating three separate rules (one for from: alice, another for to: bob, and a third for subject: TEST). However, it still generates a fourth rule with no conditions in the XML, which generates an error when importing into Gmail. (I imagine it will create problems with sync, too.)

Unfortunately the current version does not support nested boolean conditions, e.g. you can't have any: or all: as a top-level condition (or, for that matter, nested in any way). Supporting that would require a bigger rewrite than I think I'll take on at the moment, but I think I can tweak how we handle the "filter with no conditions" edge case to make your use case work.

I'll take a stab at this soon but I'm open to pull requests if anyone else can get to it sooner :)

I just published v0.9.2 to support both XML generation and API sync for "empty" top-level rules which get "filled out" by nested rules, e.g.:

-
  important: true
  label: TEST
  more:
    - from: alice
    - to: bob
    - subject: "TEST"

I think this addresses the use case you've outlined above, so I'm going to close this issue. If it does not, feel free to reopen; in that event please help me out with a more detailed example of configuration, the expected output, and what you actually see instead.

P.S. Thanks for nudging me to make this library better! :)