I'm creating an Applet that will trigger as follows:
If New row added to, then Send an email from myemail#gmail.com
This is Applet version ID 100348625.
Notice the "to," which sounds to me like a bug. I've verified that everything is done properly and still this applet is never triggered. I'm adding rows to the spreadsheet and nothing happens. The applet says "Never run" so it doesn't even attempt to do it. It's like the adding of the row isn't being detected by IFTTT.
The spreadsheet contains an email address for the destination. The body of the email is long but within the maximum. I'm connected to my Google account for both the Google Sheet and Gmail services. My spreadsheet URL is good. I've tried both the internal URL and the Shared URL. I've also tried with the path and name instead of the URL but the same result.
What am I doing wrong?
I replicated your issue and I have managed to find a workaround, using Mail, instead of Gmail. When using the Gmail as that I got exactly the same result as yours - my applet was never triggered. Then I did it anew with Mail as that, and it started to trigger right away, sending me a bunch of notifications on each edit/row added. But the emails I receive are from "Google Sheets via IFTTT" which is action#ifttt.com instead of my own email.
Then I figured that something is probably wrong with the service and I headed to the services outage page of IFTTT which is located here. As of the time of this answer, one of the issues states:
Gmail actions may fail for some users Incident Report for IFTTT
Identified
The issue has been identified and a fix is being worked on.
It will require a large rework in how Gmail is implemented, we
appreciate your patience as we get Gmail up and running for everyone.
(Posted May 15, 2019 - 16:51 PDT)
This sounds to me like a serious issue, that is probably the explanation of all your trouble. It probably fails silently in the background and it the whole applet never registers as triggered.
Until they've fixed it, I suggest using Mail, instead of Gmail.
Here is how my working version looks:
Hope this helps!
In the end, I had to switch to another solution than IFTTT because this bug is not going to be fixed soon enough. Until it is fixed, I have no choice.
So I went with Integromat and I was able to do my integration work easily.
Related
I'm building an Outlook Add-In and using the Outlook REST API 2.0. When updating a mail message to flag the message for follow-up, the update is accepted and in the Outlook Web client it briefly shows the start and due dates, but within a few seconds the start date goes away. When looking at the message through the API, the start date is completely removed, even though it was successfully added.
The API is PATCH Office.context.mailbox.restUrl + '/v2.0/me/messages/' + messageId ...
EDIT: I confirmed that this same behavior is exhibited in the Graph API as well.
As soon as the API is called, the UI on the message is updated:
Shortly after that (sometimes within a second, sometimes a little longer), the UI changes to:
And once the UI updates, if you query the API for the message and look at the Flag property, the StartDateTime object is completely gone.
Has anyone seen this or know why it might be happening?
Checked it on Graph with the following payload for PATCH-Message call and it seems to be working fine.
{"flag":{"dueDateTime":{"dateTime":"2020-08-20T00:00:00.0000000","timeZone":"Asia/Kolkata"},"flagStatus":"flagged","startDateTime":{"dateTime":"2020-08-14T00:00:00.0000000","timeZone":"Asia/Kolkata"}}}
I suspect that there is another application/outlook add-in that's removing this flag. Can you check once?
Zendesk Support is a world-class site full of useful information. But after searching for, and reading, lots of articles I still have some very basic questions:
We run a travel site that takes bookings. We have a need to organise our emails so that everyone can easily find every email regarding an individual booking, both incoming and outgoing. (And later we would add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But throughout the Zendesk site there only seems to be talk of using Support for problems.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to our chosen email address (we will retain and use one of our domain email addresses) and Zendesk Support automatically starts a thread and sends us an email to tell us about the new thread. We then open the Zendesk console, and find the thread.
2) To reply by email to the client we then write a comment in the Zendesk console - is that right?
3) And presumably our email system gets a copy of the comment?
4) What happens to our actual email system? - We will be doing everything in Zendesk, so all the usual maintenance of our email inbox is not being done - marking as read, cancelling stuff, moving to other folders and so on. How do people manage the inbox on the original email server?
Thanks for any help on this.
Zendesk Support is a world-class site full of useful information. But
after searching for, and reading, lots of articles I still have some
very basic questions:
We run a travel site that takes bookings. We have a need to organise
our emails so that everyone can easily find every email regarding an
individual booking, both incoming and outgoing. (And later we would
add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But
throughout the Zendesk site there only seems to be talk of using
Support for problems.
You are correct in that a plurality if not majority of use cases are
for customer contact centers which usually focus on addressing issues
after they arise. At the same time, I know Zendesk is used for a
variety of other use cases including in your space.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to
our chosen email address (we will retain and use one of our domain
email addresses) and Zendesk Support automatically starts a thread and
sends us an email to tell us about the new thread. We then open the
Zendesk console, and find the thread.
Yep, that sounds correct. Details on the mechanism for configuring
the Support Address and redirecting messages to Zendesk can be found
here.
2) To reply by email to the client we then write a comment in the Zendesk > console - is that right?
While it is possible to work from an inbox, Yes, the main emphasis is
on working in the Zendesk agent console.
3) And presumably our email system gets a copy of the comment?
I would suggest to check out some of the articles provided by Zendesk
about email. forwarding, SPF, email archiving
4) What happens to our actual email system? - We will be doing
everything in Zendesk, so all the usual maintenance of our email inbox
is not being done - marking as read, cancelling stuff, moving to other
folders and so on. How do people manage the inbox on the original
email server? Thanks for any help on this.
Basically, Zendesk will be used by agents to respond to communications
and guide the interactions, and the email box can be considered as
operational in directing emails as needed. Separately you can
configure email archiving as linked above.
Depending on what system you're using, Gmail has a built in connector
described here, details on Exchange here, or something else here.
What do you want the interaction to look like between it and Zendesk
and what does your current operation look like compared to motivation
for using something like Zendesk?
I assume it has something to do with this:
For me Google one Tap stopped working on all my sites that previously worked. I added API HTTP refer to restriction in console.developer.com, but I still get a warning message "The client origin is not permitted to use this API." any thoughts? If you go to the page https://www.wego.com/ you can see that Google one tap still works...
https://news.ycombinator.com/item?id=17044518#17045809
but Google YOLO stop working for everyone. I use it like many people for login and it just stop work.
My domain are obviously added on console.developers.google.com
Any ETA for fix this? Some information would be great for people who rely on it.
Google YOLO is not disabled. It is open to a small list of Google Partners.
The reason you were able to access it earlier was because it was open for a short period of time but the whitelist is now readded/enabled.
Reference:
https://twitter.com/sirdarckcat/status/994867137704587264
Google YOLO was put on whitelist after a client-side exploit became clear to google.
People could cover the login button of the prompt with something like a cookie consent (which we all know people automatically accept).
Therefor people could easily steal their gmail or other details due to this google decided to put it on whitelist and review the sites that are using this technology in order to ensure that they are using it as they should.
Google retroactively labeled One-Tap as a "closed beta".
https://developers.google.com/identity/one-tap/web
The beta test program for this API is currently closed. We are improving the API's cross-browser functionality and will provide updates here in the coming months.
The link for the entire project is currently 404, but the beta statement is visible on the wayback machine.
Bitbucket has improves its Webhooks functionality. We won't be able to create POST or Pull Request POST in Services, instead in Webhooks.
So I have tried to create POST request to Slack using new Webhook, but it doesn't work. Clicked on View requests, I got 500 error on the request. While with the same URL, it works in Services.
I don' know what I did wrong. Bitbucket documentation doesn't help. Can someone please help me?
I'm experiencing the same problem, and it appears to be a known issue with the integration (from the perspective of Slack).
As documented on slack.com:
This integration only supports the Repository push trigger at this
time, so make sure it is selected. Press Save when you're done.
I'm not sure where to find a public link to this document, but you can find it if you go to add the bitbucket integration. And the documentation on slack appears to be up to date with the new bitbucket webhooks.
Hopefully one of the parties fixes it soon.
Update:
The integration appears to have started working in the last couple of days. At least for us with PR create/update/comment?approve/merge.
Maybe Graham is talking about this here. You maybe need to change your IP-whitelist to connect to your server.
131.103.20.160/27 165.254.145.0/26 104.192.143.0/24.
I never used Posthooks. I m myself struggeling with the webhook configuration.
Not sure if this is related to your issue, but I'm putting it here as it might help others, there's currently an open issue related to non-standard ports that has similar symptoms:
https://bitbucket.org/site/master/issue/11514/webhook-fails-when-using-an-alternative
Do you have any IP limits on what IPs can post to that end target? The new web hooks may be using different IP addresses than the old services.
We have realized that this URL http://Keyword:redacted#example.com/ redirects to http://example.com/ when copied and pasted into the browser's address bar.
As far as I understand this might be used in some ftp connections but we have no such use on our website. We are suspecting that we are targeted by an attack and have been warned by Google that we are passing PII (mostly email addresses) in our URL requests to their Google Adsense network. We have not been able to find the source, but we have been warned that the violation is in the form of http://Keyword:redacted#example.com/
How can we stop this from happening?
What URL redirect method we can use to not accept this and return an error message?
FYI I experienced a similar issue for a client website and followed up with Adsense support. The matter was escalated to a specialist team who investigated and determined that flagged violations with the format http://Keyword:redacted#example.com/ will be considered false positives. I'm not sure if this applies to all publishers or was specific to our case, but it might be worth following up with Adsense support.
There is nothing you can do. This is handled entirely by your browser long before it even thinks about "talking" to your server.
That's a strange URL for people to copy/paste into the browser's address bar unless they have been told/trained to do so. Your best bet is to tell them to STOP IT! :-)
I suppose you could look at the HTTP Authorization Headers and report an error if they come in populated... (This would $_SERVER['PHP_AUTH_USER'] in PHP.) I've never looked at these values when the header doesn't request them, so I'm not sure if it would work or not...
The syntax http://abc:def#something.com means you're sending userid='abc', password='def' as basic authentication parameters. Your browser will pull out the userid & password and send them along as authentication information, leaving the url without them.
As Peter Bowers mentioned, you could check the authorization headers and see if they're coming in that way, but you can't stop others from doing it if they want. If it happens a lot then I'd suspect that somewhere there's a web form asking users to enter their user/password and it's getting encoded that way. One way to sleuth it out would be to see if you can identify someone by the userid specified.
Having Keyword:redacted sounds odd. It's possible Google Adsense changed the values to avoid including confidential info.