I have a situation where I would like to programmatically (re)send a confirmation (opt-in link) email to a member who has unsubscribed.
I know I cannot directly re-subscribe them, but I was hoping there would be a means of at least sending a confirmation email.
Is it possible to trigger the confirmation email for an unsubscribed member in vs 3.0 of the API?
I know I can resend it from the Web UI but I'd really like to accomplish it via an API request when a user who has previously unsubscribed performs some action on the website indicating they'd like to be added again.
Deleting and Adding the member is a last resort, but I would prefer to keep the original account (and its data) in place.
Re-sending an opt-in email for someone who is still in a pending state isn't supported AFAIK, but once the user is unsubscribed, I think if you set them back to pending it will resend the email.
Alternately, I've not found deleting and resubscribing to cause much data loss (if any) so you might try that out too, if the above doesn't work.
Related
1) With a Free Gmail account were unable to get the MessageLabelsChanged event to fire. We're assuming this should occur when you take a gmail message and add or remove a label from it.
At the same time, we ARE able to get the Idle, CountChanged, MessageExpunged and MessageFlagsChanged events working..
We are calling it on the Service.Inbox object.
We found this link https://github.com/jstedfast/MailKit/issues/208 about wrong event raised. Our labels are very uniquely named, therefore we believe, they should not be confused with events?
2) What is the ImailFolder.Subscribed method do? Should this be called to solve issues #1???
Many thanks Jeffrey!
I should probably remove the LabelsChanged event from ImapFolder because GMail is not very good about sending those notifications to the client (in fact, I'm unable to get GMail's IMAP server to send them either).
I've mostly kept it for completeness in case GMail's IMAP is ever fixed to reliably send those notifications.
so this is something I've been trying to think through for about 16 hours. I am coding with PHP / CuRl / etc - the bot works and everything is fine. My current issue is figuring out how to disable the bot and allow a human to begin chatting with the customer/sender.
Has anyone successfully, created a route for this ? I mean it's pretty hard from what I see, you'd have to disable etc etc. A lot of effort for my clients.
Thanks for any input.
Facebook has rolled out a "Handover Protocol" which is supposed to facilitate a combined human/bot Messenger implementation.
https://developers.facebook.com/docs/messenger-platform/handover-protocol
It is a little unclear what actually occurs in step 5:
Pass thread control: At some point in the conversation, a user may choose to do something like interact with a live agent. To handle this, pass thread control from the Primary Receiver to the Secondary Receiver. The Secondary Receiver will receive a messaging_handovers webhook event to notify it that is now controls the conversation.
This doesn't actually disable the bot (as the OP requested), and isn't in the control of the Page owner but rather of the user. It seems FB envisions the user typing something like 'I would like to chat with a human' triggering the bot to pass control...but it would be nice to let the page owner simply put the app in standby and handle the messages herself.
Once you recognize someone wants to speak to a human, set a flag that disables all actions of your bot to on.
Then, have your bot message you, or whoever will respond, that a user ID needs responding to. Have your bot continue to send all messages received from them back to you until you enable the bot again.
Create some sort of way for your bot to interact with you that allows you to send a message to a specific user, and a way to once again enable the bot interaction with the user.
Probably something like "sendMessage104012301230'Hi, sorry you couldn't find [etc]', and enableUser104012301230
There may be a better way, but those are some thoughts on how I'd do it
If you enable messages echo, whenever a human respond using the page, a echo post is sent, and inside entry->messaging->message there's no app_id.
You can use that information to disable bot replies for a certain period, or disable indefinitely until you enabled is with some admin command (that's how I'm doing)
I thought a solution could be to label the message as "unsolved". Another solution could be to have the bot mark the conversation as unread. Does anyone know if it is possibile to add a label to a conversation or mark as unread through API?
I have just created my first PayPal button and it is working correctly within sand box. I would like to know the best way (if possible) to issue a unique activation code on my return url ensuring that the user has definitely paid before they receive the code. I could manually email the code but wondered if the was any way of automating this using some sort of return value? Possibly returning to an aspx page which then reads from my database to get the next activation key and displays it?
Thanks
Garry
As you already know that PayPal doesn't provide such facility for delivering activation instantly but it does offer the Instant Payment Notification API (PayPal IPN) which can be used to build such a platform.
Here is a great article for that purpose only. https://www.codeproject.com/Articles/383207/Selling-software-using-PayPal-IPN-as-an-eCommerceenter link description here
The best way to handle that would be to use Instant Payment Notification (IPN).
Any time a transaction happens on your site (whether it's a payment, refund, cleared pending payment, dispute, etc.) the PayPal server will POST details about that transaction to a script you have sitting on your server.
This script can receive the data and process it accordingly allowing you to automate things like updating a database, generating email notifications, hitting 3rd party web services, delivering e-goods, etc.
If you want the activation code to be visible on the return URL you can look at Payment Data Transfer (PDT), which is just like IPN except that it's made for use with the return URL. It is not recommended to use this, though, for post-transaction processing because there is no guarantee the user will make it back to the return URL, for one, and also it wouldn't handle things like e-checks correctly.
I run a subscription based website, which was going great until the developer of the subscription component I used ceased development.
Due to my lack of knowledge of programing a solution to set up something to catch the exisiting IPNs and convert them into something my new subscription component could manage, I simply manually added new subscriptions into the new subscription component, and kept a manual log of when subscriptions had been cancelled from Paypal's end, then altered the entries accordingly.
This was fine as the defunt subscription component still recieved the IPNs and sent back the correct notification to Paypal, and I kept an eye on things.
Now we have upgraded our security and moved to a new server, and the old subscription component has been marked as being vunerable, so moving it over also to keep this system I have going is no longer viable, and I am getting warnings from Paypal about IPNs not being recieved properly.
What should I do about this?
I can't turn of IPNs because my new subscription component uses them (perfectly).
Is this something a developer could look at and fix for me? I simply want the subscription IPNs from the old system to be recieved somehow (I am totally happy keeping things running manually on my side for older subscriptions).
Is there a way to turn off IPN notifications for just the subscriptions that are trying to send to a paricular URL?
Is there an easier sollution?
Any help would be muchly appreciated, I am worried that my IPNs will get turned off all together which would end up being a lot more work for me!
Kind Thanks,
Thomas
You cannot modify the IPN notification URL that are sent to your old subscriptions.
If you want to stop receiving notifications on your old subscriptions you need to cancel the old subscriptions and create a new/similar one.
I’d like to implement an “out of office” app for Facebook messages but it doesn’t seem technically possible. The idea is simple, let the user define some dates they won’t be reading Facebook messages (i.e.: they're off-line camping) so that when they get a new message we can notify the friend/sender they won’t be able to respond quickly.
I’ve been reading Facebook’s API and, although I can read user’s messages with proper authorization (read_mailbox), I cannot send messages on their behalf.
A workaround would be to get the email address of the sender, and answer with a plan email instead of a Facebook message. But getting the sender's email also requires extended permissions on a per user basis.
I could present the Send Dialog, but logically we want this to work automatically without any user interaction. Also, we could post a private status only visible to the sender, but that doesn’t seem very effective.
This is where I hit the wall. Can you think of a way to implement such functionality?
You can email to username#facebook.com (getting the username from the user id does not require any permissions) – but Facebook’s policies forbid apps from using that in general, because they say these addresses are intended for user-to-user communication.
You could make a point saying, that this was essentially user-to-user communication – but use at own risk. You’re app may be blocked if there’s spam complaints or if Facebook sees you sending a massive amount of messages this way.