I'm using Slack's Real Time Messaging API to track when my team members log into or out of Slack. Using the presence_change and manual_presence_change events I am notified when someone explicit changes their presence state (or if they're automatically set to "Away" after a period of inactivity).
But if a team members logs out (e.g. closes the Slack app) I do not receive any type of notification. Am I missing something or is there no way to be notified when someone logs into or out of Slack? I really don't want to have to resort to polling.
Related
By default, Twilio trial accounts can only send SMS to numbers that are listed as Verified Caller IDs in the Twilio console. These numbers have to be added manually, and require a verification message before they can receive SMS. This is an excellent feature for development, as it prevents accidentally sending SMS to wrong numbers.
My problem, is that I am developing for a client whose account is already out of trial status. I don't want the software in development to be able to send text messages to any number, because there is a risk of sending dev messages to the client's actual customers. However, we need to be able to send to some numbers for testing. Is there any way to turn the trial behavior back on? That is, can we somehow configure Twilio to only allow sending SMS to verfied numbers, even if it is not a trial account?
If this isn't possible, I think I can query the Outgoing Caller IDs resource from my program to verify the recipient number against the list before sending. However, this puts the responsibility back on my development team, and the possibility for mistakes remains. I'd like to be able to block the behavior at the Twilio level.
This behavior is only applied for trial accounts, however I'll pass this feedback on internally.
You'll need to replicate this behavior yourself for your applications using an upgraded account.
As you mentioned, you can query the Outgoing Caller IDs to get the phone numbers you have already verified with Twilio and use that as an accept list.
However, for your use case, you can store and fetch the accept list using whatever way is most convenient for you, like in code, file, database, etc.
Depending on your needs, you could embed this logic directly into your app, or use a single shared library, or create a web API that all other apps have to use to send texts.
Good luck! We can't wait to see what you build!
Update after getting internal feedback.
You can create a new trial account, even with the same Twilio profile, which would give you promotional credits and the same verified Caller ID limits again.
The promotional credit should last you a long time for test scenarios.
Implementing subscriptions on an iOS app means we want to handle SSEs in case of subscription status change, as to manage the user's rights inside the service.
The Apple documentation doesn't show an explicit customer GUID.
They provide, in each SSE's payload, receipts, e.g. the latest one.
The question is: how can an API server uniquely identify customers?
Should the API server keep track of every receipt, in an inheritance way?
I.e. should the API persist every receipt, and a link to the previous receipt, up to the first
one that was emitted (which can be linked to a customer through the iOS app the user used to initiate its subscription), and re-trace this history on every SSE?
Per this thread, the applicationUsername service-side UUID (used by apple, for "irregular activity checking") isn't a solution, as it isn't provided in receipts or SSEs. The thread hints that using the transaction IDs is still the best way to identify a SSE, as it is ultimately tied to a user, and it is up to the service to keep track of transactions made by the user on the Apple platform for the given service.
Isn't there an easier, more direct, way, to establish the relationship between a SSE, its apple customer, and the service's user?
After digging for a while and asking around, I reached the following conclusion:
There is only one way to tie a transaction event to a user, and that is by the
restoration mechanism one has to implement on their application.
For this reason, you need to at least keep track of original transaction IDs,
so when the restoration mechanism is triggered on your app, you can check the
currently logged user on your app, and call your back-end with the logged user,
and a list of original transaction IDs.
Usually, when a user subscribes, it is mainly done from within your app, so you
can do this link in a trivial way.
But, because you can "re-subscribe" from the AppStore after a while, without
going through your app, Apple may send a SSE to your back-end which would contain
a new (hence unknown) original transaction ID, since this new subscription is
has a new transaction.
In short,
You need to keep at least a DB of original transaction IDs you receive as SSEs
You need to implement the restoration mechanism as to contact your server every
time the app starts, with the list of transaction IDs / original transaction IDs Apple gives you
You need to accept having transactions stored in your backend without a link
to a user (because the user may have re-subscribed without launching the app yet)
I am building a CRM which handles email exchange in the app by processing emails sent to the Office365 accounts of the users using Microsoft Graph API. What is the best practice to keep track of emails in the actual mailbox? Should I use delta's or subscriptions?
From what I can tell, Delta's are URLs which give data about the current state of the mailbox, but deltas need to be triggered on a regular basis (I'd use a CRON job) but then I'd be running the process a lot more than needed because users don't receive that many emails per day.
Alternatively if I use a subscriptions that will let me know when a new email is received and I can process using a webhook in my app.
From the Microsoft Graph documentation it seems like deltas are the way to keep track of changes, but I feel like since all I need is to know when a new email is received so that it can be processed accordingly, delta's would be overkill in a sense.
You use a combination of the two.
The webhook tells you the mailbox has changed, the delta tells what has changed in the mailbox. When you receive a notification, you pull the delta to retrieve the changes to the mailbox.
There are many reasons for doing this, but the primary one is that the id of an email can change. This is because Message IDs are a composite value that includes the folder it is stored in. So if the message gets moved, the Id you received in the notification will be invalid. Historically this was a somewhat rare race condition, but with the advent of interactive mobile notifications, it is now commonplace for an email to come in and instantly get "archived". By relying on webhooks for notifications and deltas for content, you avoid a CRON job while mitigating the Id changing before you can process the message.
Hello I have a monthly subscription on my app using Braintree which is working ok. I would like some advice on best practices for the event where payments aren't made on time for whatever reason.
I currently have a User model with subscribed:boolean subscribeddate:date and subscribedend:date.
When a user completes payment through braintree, the attributes get updated to subscribed:true subscribeddate:Date.today and subscribedend:Sometime_way_in_the_future .
When a user cancels a subscription, the attributes get updated too, subscribed:false and subscribedend:(a braintree attribute, billing_due_date)
This way I can filter things in my app according to dates and subscription status. The only problem I can see with this is if Braintree tries to charge an account one month but fails. Braintree has an attribute for this (.days_past_due), but my app has no way of knowing whether this has occurred or not.
What are the best practices for this? Should I do a scheduled task each day to check if every single user has a value for the .days_past_due attribute on the Braintree server? Would this not be incredibly slow if I have a lot of users?
I may be going about this all wrong and I'd just like a bit of advice on the matter,
Thanks.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support#braintreepayments.com.
Your best bet is going to be to implement Braintree's recurring billing webhooks. Webhooks send you a notification via HTTP POST whenever an event occurs that may not have been directly triggered by an API call—such as a customer getting charged via their subscription, a subscription getting canceled, or a subscription going past due. This will allow you to directly respond to subscription events, without having to perform daily checks to see if any changes have occurred.
To use webhooks, you need to choose which events you want to receive webhooks for, designate an endpoint on your server where we'll send the notifications, and set up that endpoint with code to parse the webhook notification into a useable form. For details, see this guide with instructions.
I've got an iOS app backed with ejabberd, with a small extension based on offline_message_hook that uses APNS (Apple Push Notification Service) to deliver push notifications of messages that are sent to offline users. This doesn't work out so well for group chats though, so I'm looking for a strategy that would do the same for offline users that are part of a group chat. Do MUCs even keep track of users that are part of the room but offline? Would I need to extend them in some way to keep track of this? Could I subtract the set of invited users from the set of online users to get the offline users? What hook should I be using to do this?
Any suggestions on this or advice on a better strategy are much appreciated!
The XMPP specification for Multi User Chat define MUC rooms as presence based. Per definition, a user is only in a chat room when it is connected. When he gets offline, users gets out of the chatroom. It means he does not receive message at all. This explains why they are not stored offline.
This is for now a feature of XEP-0045. Some future XMPP specifications (aka MUC 2) may address this issue in the future. Currently, MUC + offline storage of message is not possible in XMPP.