rosulek / gmail-tickler Goto Github PK

Apply a tickler label like tickler/10min, and it will take two executions of the script for the thread to reappear in the inbox: once to convert tickler/10min to an absolute date tickler/@/YYYY-MM-DD at HH:MM, and another to actually restore.

Is this a big problem, is anyone frequently sending things 10 minutes into the future like this? I certainly have never needed to cleanup my inbox on such a short timescale. I guess it could happen if you have a label automatically applied to certain kinds of emails (e.g., tickler/6pm applied to an email coming in at 5:45pm).

(Figure out how to) Bundle the script as a web app that others can add easily.

Wanted to share the following Chrome extension with you. Maybe you can take it as a reference to convert gmail-tickler into an easy installable Chrome extension:

https://chrome.google.com/webstore/detail/gmail-snooze/ajhdhpnafihkepjialgccenokkljdlaf

https://github.com/google/gmailsnooze

Warmly,

Robert

Dear @rosulek,

Thank you very much for this great script! I followed your setup steps and my tickler labels are successfully created. I moved a conversation to tickler/tomorrow in expectation that it would return to my inbox tomorrow. However, it is returned one hour later (project trigger?) with the label tickler/finished.

Do you have any idea why?

Thanks!

Robert

As discussed in #25, we can simplify the script installation by including the Trigger creation in the setup() method.

Does it seem reasonable to synchronize the Trigger interval with the fudge_factor value, and perhaps constrain the latter to the 1/5/1015/30/60 minutes options available in the dropdown for the former?

Hi,
First of all, thanks for your awesome work on this script.

I would like to suggest to add real labels to this script. For example, the /tickler/in/8am should be labeled as "Next morning".
I think it should be really nice !

Great script!

If one turns off conversation view and doesn't adhere to inbox zero philosophy, then the email reminders could appear buried somewhere in the inbox where nobody will notice them.

I dealt with this in the following way:

var EMAIL_USERNAME = "johndoe";
var EMAIL_PREFIX = EMAIL_USERNAME + "+tickler";
.
.
.

function untickleThread(t) {
.
.
.
//t.moveToInbox();
var firstMessage = t.getMessages()[0];
GmailApp.sendEmail(EMAIL_USERNAME + "@gmail.com", firstMessage.getSubject(), firstMessage.getPlainBody());
t.moveToTrash();
}

If you're tickling rich text emails you'll have to do something more sophisticated though.

Hi @rosulek,

Quick question: Let's say I want to schedule an email for a specific date, can I then use the following label to get a reminder on May, 1st?

may/1

I couldn't find this information in the Readme.

Thanks!

Robert

Hi, thank you very much for sharing this very useful script. I tried installing it and noticed that I couldn't get it to work without changing the call to getYear() in the date2str function to getFullYear().

Dates were being converted to strings like '120-07-16' (120 years from 1900 base) and were not being parsed correctly later on.

Currently, it only removes the main TICKLER_LABEL, and not any of the sub-labels. Is this intentional? In contrast, I see that they are all removed in untickleThread.

While some users might prefer to see the labels that were in conflict, most of the time I can easily remember/re-decide until when I want to snooze the thread. The current behavior is particularly frustrating on email clients (such as Outlook on iOS) that don't show the labels that a thread currently has. If I snooze a thread to time A, and then a new email in that thread bumps it back to my inbox, then I may snooze it to time B without realizing that it already has the label for time A. This will cause it to mysteriously appear in my inbox again and again, no matter how many times I try to snooze it. If the Tickler removed the conflicting labels, then the snooze would again succeed the third time.

I'm happy to fix this, but wanted to get some feedback first about whether it warrants a switch and/or should be the default.

If the script is going to start having multiple files + dependencies, it would be nice if there was a one-click way to install this. This is a good idea even if it's a single file, since not everyone will want to do the manual installation process.

Ideally I would host a version of the script from my google account. Anyone could click a button somewhere that installs it to their account.

I think the way it has to happen is to package it as a web app. These can somehow be configured to run as the user of the script (not the author of the script).

On the one hand, this seems possible. On the other hand, I still have not seen a reasonable proof of concept that accomplishes this. Actually, I feel like I saw one a few months ago but apparently didn't bookmark it.

Other things:

• A packaged web app can apparently add the appropriate triggers programatically.

• If the goal is user-friendly install, then there should also be a way to configure the tickler without having to edit the script manually (which is probably not even possible in a packaged web-app). I guess this can be done by manually making a web interface, and using Properties service as a user-specific key-value store. This seems like a bunch of work.

Hi @rosulek,

I had an idea to address the relative baseline problem. As I recall correctly, you were saying that there is no way for you to know the relative date for conversations older than a week. I would like to know from you whether the following could work:

Let's say the last email conversation from a conversation dates back to Friday, 17 April. If I assign the label tomorrow to it, it would immediately come back into my inbox because Saturday, 18 April had already passed. But what if we calculate the relative date based on the date at which the label had been assigned? In that case, tomorrow would become relative to today because I assigned the label today (and this could be calculated based on the hourly trigger, right?).

Looking forward to your response!

Robert

This old tweet showed caught my eye in Timehop today:

@mailbox Just a suggestion: I'd love if I could set geofenced snoozes, so mail would return to my inbox when I entered a certain venue/area.

Often, when I use my 9pm label, I actually mean when I'm home and at my desk again. I realized it might be possible to wire something up with IFTTT's iOS location triggers and some special labels that correspond to different locations. I don't see any particularly obvious ways with either IFTTT's or Zapier's Google integrations to run a method in a Google Apps Script, but there's probably a sufficiently elegant workaround.

This may be outside of the scope for the Tickler, but I figured it was worth mentioning / thinking about some more... after I eventually get through all the others issues I've opened :)

Imagine adding label sendlater/tomorrow/11am to a draft, to have it automatically sent at that time. It would be relatively straight-forward within the current framework. Unfortunately, Google apps script doesn't support sending drafts. People have suggested various workarounds:

• https://gist.github.com/mogsdad/6515581#file-sendgmaildraft-js does it through the more direct Google API, as far as I know not through GMailApp. Could be worth looking into.

Add configurable syntactic sugar. I can only think of examples for times of day: e.g., morning resolves to 8am, evening resolves to 6pm.

This would be very easy to add (filter the tickling command before it gets parsed the usual way), but maybe not incredibly useful.

A handful of times threads in my tickler labels have gotten skipped over. For example, I had a thread in a label like feb15 7am and it is now 5pm on that day, but my thread was not moved to my inbox.

These might correspond with times when the script has encountered a Javascript error (as in #12) or failed to finish for some other reason (I've gotten a couple of Cannot connect to Gmail errors). This would prevent the tickler from moving the email the first time, and then the next time it runs, it thinks my label is intended to trigger a year from now.

I think the relevant code is here:

    if (theDate.getTime() < baseline.getTime()) {
        if (ifPast == "y")
            theDate.setFullYear( theDate.getFullYear() + 1);
        else if (ifPast == "w")
            theDate.setDate( theDate.getDate() + 7 );

(While I haven't used day-of-the-week labels much, I can see a similar issue happening in that case.)

I'm not entirely sure if this needs to be fixed, or what the fix would be. Perhaps a second application of the FUDGE_FACTOR in the timestamp comparison? It's hard to imagine that adjustment would thwart an actual user intention, and even if it did, it's better to return things to the inbox too early than too late.

See whether this is feasible / desirable:

https://gsuite-developers.googleblog.com/2017/10/gmail-add-ons-framework-now-available.html

For the past two days I've gotten the quota error message towards the end of the day Service using too much computer time for one day. I've configured the script to run every fifteen minutes on three dozen Gmail threads in a few different Tickler labels, which is more than I usually have, but not really that many.

I'm guessing the API requests to Gmail are the slowest part, and there are probably ways to cache results and otherwise make those more efficient. I'll take a look as soon as I (eventually) wrap up my relative baseline PR for #6...

As discussed in #25, we will probably eventually migrate to using the Properties service to make installation and configuration easier for non-technical users. These can be configured in the Apps Scripts UI shown in the below screenshot accessible from the File menu. I think it would be worth doing that regardless, so that we can all be running the same version of the code, rather than having to each maintain different configuration values.

This should be pretty straightforward – all we need to do is check for a Property (probably a User Property, as opposed to a Script or Document Property) for each configuration option, and then default to the current values if none is found.

I'd like to add an optional setting for specifying the yyyy-MM-dd' at 'HH:mm format for the tickler-managed labels to some other sufficiently-specific value. It would be nice to be able to see the full timestamps in my narrow Gmail sidebar, perhaps by using a two-digit year:

Javascript's Date parsing is, unfortunately, terrible, and Google Apps Script's seems not much better, so this will probably be most-simply accomplished with an external dependency such as Moment and possibly Moment Timezone. While in most situations I'd cringe at the relatively-large library sizes, in this case I guess it won't really matter.