Skip to content
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

Support deliveredto rule #377

Open
legeana opened this issue Dec 19, 2023 · 3 comments
Open

Support deliveredto rule #377

legeana opened this issue Dec 19, 2023 · 3 comments
Labels
kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale. needs design The issue needs a sane design before implementation

Comments

@legeana
Copy link

legeana commented Dec 19, 2023

Similar to to, bcc etc.

See https://webapps.stackexchange.com/a/5729.

Surprisingly it doesn't work with workspace aliases, but works well with + aliases (e.g. me+tag@domain.com).
But it's still pretty useful for filters to deal with forwarding proxies e.g. simplelogin.io.

@mbrt
Copy link
Owner

mbrt commented Jan 4, 2024

This seems still second class in Gmail, as there's no dedicated option in the UI (as opposed to e.g. has-attachments which we still don't have).

I think we need to decide which operators to support natively. I do see the value of providing all of these (including deliveredto) natively, but I haven't really decided yet.

At a minimum we need to first support the obvious and visible ones though (e.g #115).

@mbrt mbrt added kind/feature New feature or request needs design The issue needs a sane design before implementation lifecycle/keep-alive Denotes an issues or PR that should never be considered stale. labels Jan 4, 2024
@legeana
Copy link
Author

legeana commented Feb 13, 2024

What would you think about a generic operator that would help with escaping etc, instead of query.

Currently one has to write { query: 'deliveredto: %s' % std.escapeStringJson(alias) }, probably. This is pretty ugly in my opinion.

Maybe if we supported { custom_op: { op: 'deliveredto', query: alias } }, or something similar, it would make writing simple wrappers for these 2nd class rarely used operators easier, without explicit need to support them natively?

Maybe gmail comes up later with something new and whoever wants to use it can just make their own

    local newgmailop(query) =
      { custom_op: { op: 'newgmailop', query: query } };

What that be more palpable?

@mbrt
Copy link
Owner

mbrt commented Mar 11, 2024

I think this might be a good idea.

I'm curious though. What would be the difference with having this in your config?

local newgmailop(query) = {
  query: 'newgmailop:%s' % std.escapeStringJson(query),
};

You would use it the same way it seems?

{ filter: newgmailop('foo'), actions: { archive: true } },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale. needs design The issue needs a sane design before implementation
Projects
None yet
Development

No branches or pull requests

2 participants