I want my app to have 3 different kinds of notifications which the user has the option to opt into each but I need to support all of them on the backend I think. I wanted to see if others had an approach which worked well for them. The three notification types are different:
Individual Notifications - A specific user related notification. When a specific event happens in their account they (and their team members) get notified of it.
Item Notifications - An item specific notification. Any user of the system can get notified when a specific item available to all reaches a certain stage of the process.
Topic Notifications - General system event, to be sent to anybody who has opted into receiving notifications for a system event.
If I am going to support badges for each, I need to track them by user I suppose, in order to send down the badge number with the notification. The icon would be the aggregation of each. I am thinking I need three Toggle settings, one for each. When the user sets each one, I would send a registration for that type of notification to a webapi which would store the user id in a registration table along with the registration type.
When sending the registration to the user, the registration table gets queried, a record goes into the notification_view table for that user and notification type, and the badge count is taken from that and sent to apns.
When the user views a notification, I will send a message to the api and update (or remove) the notification_view record associated with he viewed notification.
I know there are ways to have filter a notification, and I expect this will be incorporated. I'm using Azure NotificationHubs and this would be included under tags. So if a device had a tag (sports_news or something like that) the server side could send a notification with a sports_news tag and it would go to everybody who subscribed to it. That might work for category #3 above, provided we do not care about badge counts.
Is anybody else doing something like this? Do you use the same type of backend tables to support the process? Does my process mirror what you are doing?
Related
Is it possible to get conversation id and message id of the messages sent by our app on behalf of the user who only given send only permission?
We want to send follow-up mails in the same conversation and there is no way we can do that without message id.
I'm afraid not. You need to have mail.read in order to find the message id and add to the conversation.
Also, it's important to note that the id is mutable and can change for any number of reasons (most commonly the mail item being moved to another folder). It is possible to get immutable identifiers for Outlook resources but this functionality is still in Preview so, for the time being, it really shouldn't be used in a production environment.
I have a Slack command bot that posts ephemeral messages and lets the user decide whether they want to make the message visible to everyone else in the channel ('Send') or delete the message ('Cancel'). Since Slack API doesn't provide the original message when user interacts with an ephemeral message, I have to store original messages in Redis, retrieve them when user interacts with the posted message and delete the key from Redis afterwards. The one thing I'm worried about is clogging up Redis with keys that will never be deleted because user never interacts with the message (in other words, doesn't tap on any of the buttons, just leaves the message as is and walks away).
Does Slack API provide any way of knowing when ephemeral messages get deleted so I can clean up Redis? Or is there a better way to solve this problem in general?
No - Slack has no mechanism to inform your app when an ephemeral message vanished. In general they will live until the user refreshes the page on his browser (in the web version).
But I can offer an alternative solution to storing all messages on redis:
Since you created the initial ephemeral message you should be able to always recreate that same message later if you know the exact functional context (e.g. User ID).
All you need to do is to store an ID linking to its context in the buttons of your first message. If the user clicks on the buttons the Slack request will include those IDs, which allows you to identify its context, e.g. take the proper action or recreate the same message for sending to the whole channel.
You can use the name or value field of an action for storing IDs. (See also this answer.)
That ID can either represent the instance of an object (e.g. a customer), so you can fetch that object from your DB again or it can be the ID of your server session, which enables you to work with server session and keep all the context data in the server session. (see also this answer).
I want to create something in Slack that sends a message (starting by calling someone with '#') to a channel when specific users login. I've checked ifttt and zapier. I also checked the slack api to create something myself, but I couldn't really find anything usefull.
Anyone has any ideas?
Slack does not track user login or logoff in a traditional sense. Instead, users are always always "logged in" and available to receive messages once they have joined a team / channel.
There also is the concept of "presence", which is related, but not the same thing. User presence can change multiple times during a few minutes, e.g. if the user is on a mobile. I am guessing you would not want to send the user your message that often.
Still you can poll the presence information of a user with the API users.getPresence , which could be used to implement a script that polls this information on a regular basis and send your message. You also want to filter out presence changes below a certain duration threshold.
Keep in mind though that the rate limit for API methods is 1 per second. So depending on how many users you have in your workspace there will be a significant delay between the user becoming "present" and your script being able to send the message.
There is a workaround for that to have a google sheet as a database for the users and you can trigger by day once and timestamp it.
So the best trigger is a private message or public and you can use filter when mentioning or signin or signout it depends on the trigger word then you pass the filter since zapier won't count your zaps if you used fiter as a second step.
I am looking to display incoming push notifications in a table view within my app. I am using the parse framework for push notifications which are triggered via scripts within an existing CRM product. I have setup separate channels for each user for advanced targeting purposes.
What i am looking to do is display all push notifications for the specific user based on their channel in a table view. I would also like to have a way for the user to delete the notification from their phone but not from the parse backend. I'm pretty sure this could be done with a query and a custom field in parse to show a message as deleted by user. The query would look at the channel and then the custom field to only display messages not marked as deleted.
My question is how to structure the query and where/how to add this custom field?
I have found a solution that works.
Trying to capture from an incoming push notification seems like it would only work once the application is opened and would cause delays in displaying in the table view. Trying to capture and store the data received from the push notification requires a call to parse in order to save it as an object in my custom class. I found it easier to make a call to the Rest API to create a row in a custom class in parse.
So basically when a push is triggered to an individual user the following happens.
Creates an API call to post data to parse in my custom class with all the info contained in the Push Notification plus other details like the user receiving it and info for reporting purposes.
Then the push notification is triggered after the object is created in my custom class.
Finally I have the table view querying the custom class to find the push items that are specific to the user and displays them in the table view.
So far this has worked wonderful and seems to be the easiest way to accomplish what I was looking to do.
Since push are tied to Installations (not users) I might suggest that you add column to the Installation table (as a collection) to a custom object you create to represent each push.
You could capture the push notifications locally and store them on the device, but I think that might only work for pushes received while the app is in foreground. The app would not have access to pushes received while in background mode unless the user performs an action on the notification.
It a shame, since I know this data is already being capture somewhere in Parse, but it does not seem to be exposed through their current API. I hate having to store this data again, but I see no other alternative.
Here's what I'd like to do:
User completes sign up form on my app
My app sends the input data (email address, name, etc) to Mailchimp via the API, but with a status of 'pending'
My app sends an email to the user asking them to confirm their email address (essentially emulating the Mailchimp confirmation email)
User clicks link in confirmation email, which takes them back to a confirmation page in my app
My app updates the user's status in Mailchimp to 'subscribed' via the API
Essentially, I want to emulate Mailchimps standard confirmation process, but sending the emails from my own app.
The part that I don't know how to do (or don't know if it's possible) is the part where I add a new subscriber with a status of 'pending'.
Here's some further info that's not strictly relevant but may be of interest...
Why don't I just use the standard Mailchimp confirmation email?
The confirmation email needs to contain extra info, unique to each user, that Mailchimp will not have access to.
Why don't I collect all the data locally and then send it all to Mailchimp once the user has confirmed their email address?
For reasons I won't go into, the number and type of required fields will be unknown. At the point when the sign up form is displayed, I will request the list of fields from Mailchimp and display the necessary fields. It is possible that, between the time when the user initially completes the form and the time when the user confirms via email, the required fields will have been changed. If I try to submit the previously collected data to Mailchimp after the required fields have been changed, it will cause an error.
So I need to collect and submit all data to Mailchimp at the same time. And then simply 'switch on' that user in Mailchimp once (s)he has confirmed.
I hope I've provided enough info. If not, happy to provide more or clarify any points.
Thanks!
The internal "pending" status is not able to be managed manually like that. You can subscribe them using double opt-in and then later force them onto the "subscribed" list, but you can't stop them from getting MailChimp's own confirmation email.
One possible work-around would be to add an interest group or merge field that is populated by your system once you've confirmed the email address. You'd then create a saved segment for only confirmed users and make sure you only ever send to that segment and never the whole list.
Another possibility, if you use API v3.0 (which is currently only in beta), is to add them to your list as unsubscribed and then switch their status to "subscribed" once you've confirmed them. If you do this, be very careful that you're not re-subscribing users who unsubscribed or you could wind up in trouble.
This workflow is definitely 100% possible in the current (V3) of the API. Just set the "status" field on a member to "pending" and then to "subscribed".