-
Notifications
You must be signed in to change notification settings - Fork 18
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
Add NOTHING
action
#29
base: main
Are you sure you want to change the base?
Conversation
30c4404
to
62b567d
Compare
So you have two rules, A targets CI message, B targets comment message. FYI, @dbarnett added feature "next action" in #16. But the column is not in the master sheet. You could give it a try to see if that helps. |
Totally, these more involved rule structures need some kind of chained logic, which sounds like the same set of problems I had in mind for "next action". FWIW, "no action" is still effectively "ARCHIVE" once the standard filter does its thing; I was bothered by the filter + GA moving things around too aggressively and losing state and discussed some of that in #9, but it's still a big unsolved problem. @ranmocy We should go ahead and add it to master sheet, right? If not its own column then maybe some Note covering columns that are supported but not listed in a minimal quickstart sheet? |
Updated in the master sheet to add "next action" field. |
Hm, maybe I'm not understanding the "next action" thing, but I think it won't work since I specifically care about a new input in this case -- i.e. the current location of the thread:
So in these 2 cases the |
FWIW, this is useful for me as I would like to use the script to only apply labels. I am not using the default filter rule to archive by default. There are some rules that the script currently cannot replicate, so I am using a combination of Gmail filters and this script to achieve my goals. |
d211508
to
b8973a7
Compare
b8973a7
to
43890cd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks cool, just a couple comments.
@@ -122,19 +122,19 @@ export class ThreadData { | |||
} | |||
|
|||
validateActions() { | |||
if (!this.thread_action.hasAnyAction()) { | |||
if (!this.thread_action.hasAnyAction() && this.thread_action.move_to != InboxActionType.NOTHING) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this addition does nothing. We just checked that hasAnyAction() == False
, which is:
hasAnyAction() {
return this.label_names.size > 0
|| this.move_to != InboxActionType.DEFAULT
|| this.important != BooleanActionType.DEFAULT
|| this.read != BooleanActionType.DEFAULT;
}
So we know that this.move_to == InboxActionType.DEFAULT
. So the && move_to != NOTHING
will always be true.
@@ -69,7 +69,7 @@ export class Rule { | |||
|
|||
private static parseInboxActionType(str: string): InboxActionType { | |||
if (str.length === 0) { | |||
return InboxActionType.DEFAULT; | |||
return InboxActionType.NOTHING; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative is that we iterate over all the rule cells and change the rules (if they don't already) to have NOTHING
added to the DataValidation criteria values. Then just let someone select NOTHING
.
I think with PR #69 , you can now look at a thread's current archive/inbox status. I'm pretty sure, even though your Gmail filters send the incoming email to "Skip inbox", the thread stays where it is (from a recent test of mine). And with #69 you can do:
|
I keep thinking on this and I think the gist is that
Otherwise we should have added a |
I agree the label checks are another way to get this information. The downside is it seems like a pain to read something like:
Instead of having one row with an empty action (@mlsad3 maybe this is what you're getting at in your last comment). On a side note, this one has also been a bit of a pain to continuously rebase over the years, so if it's not something you're up for merging @ranmocy , that's completely understandable, but it'd be helpful to know that I'll indefinitely have a fork of this repo. |
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
Rows in the rules sheet can match a mail, but do not need to specify actions. This is a different way of doing PR ranmocy#29, instead of adding a new InboxActionType we just decide to not worry about if a thread has any actions to do (as long as it matched a rule).
43890cd
to
b060508
Compare
This is a proposal for a change that allows you to leave the `action` column blank to signify that you want the rule to match messages and stop processing further rules, but not actually move the thread from its current state (similar to the current `mark_important` column behavior). I'm having trouble correctly routing code review emails. I don't want CI messages for other people's changes to move threads to my inbox, but if I specify `archive` on those, and a CI message is processed in the same run as a relevant message, it overrides the relevant message. I could move the CI filter rule below, but that precludes a "catch-all" review rule to route uncategorized reviews to my inbox. If this seems OK, let me know and I can add tests and make it a nicer thing.
b060508
to
d5c6531
Compare
This is a proposal for a change that allows you to leave the
action
column blank to signify that you want the rule to match messages and
stop processing further rules, but not actually move the thread from
its current state (similar to the current
mark_important
columnbehavior).
I'm having trouble correctly routing code review emails. I don't want CI
messages for other people's changes to move threads to my inbox, but if
I specify
archive
on those, and a CI message is processed in the samerun as a relevant message, it overrides the relevant message. I could
move the CI filter rule below, but that precludes a "catch-all" review
rule to route uncategorized reviews to my inbox.
If this seems OK, let me know and I can add tests and make it a nicer
thing.