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.
Related
I want to send message as DM to the users, so I've come with some questions;
1- There are two ways to send DM to the user;
the first one open a conversation with user by using conversation.open, and send message. Then if I want to send the message to the same user, I use conversation.list and find the conversationId by userId, then send message to the same channel again.
Second one is just basically using userId as channelId parameter in chatPostMessageRequest.
I've tried both ways, and both of them are sending message as DM. So, what is the purpose of using conversation.open? I'm asking this because nearly all the answers say you should do this etc.
2- Seems like there is no way to get multiple users by emails except users.list?
3- Also seems like there is no way to send messages to the multiple user at the same time (the content of the messages are different, those are depends on user data).
Sending a direct message by user ID works with chat.postMessage as a convenience, a shortcut. But it's the only method/API that allows you to use a user ID as a channel ID, so Slack warns developers away from relying on it in totality -- if you use conversations.open and the resultant conversation ID, it'll work for other methods like chat.update should you need to edit the message after sending it.
Slack doesn't offer many "lookup" APIs -- most things you'll want to look up require fetching an entire data set (like a list of users with all pages of users.list) and then filtering the results yourself. There are no APIs to look up multiple users at once via email address.
There is also no way to send the same direct message content to multiple users with a single request. In most cases, when an app is sending the same message to multiple users the best practice would be to use a channel to broadcast the message a single time, with the intended recipients as members of the channel.
I'm planning to write a slack app, and I need to render messages depending on who read them.
I'm thinking something like: the App should have some options, and user's clients should render the messages depending on the options chosen by the user.
Is there a way to post a persistent message (I mean not an ephemeral message) which is shown only to a user (or a set of users)?
Or
Is it possible to post a message shown differently depending on the user who read it?
I don't need to send private or sensitive data, so if the solution to my problem is a message containing all the content for all the users in the channel, it is perfectly fine. It's just matter of user experience.
I have two constraints:
The user experience for those who don't use the App should not be impacted
I need the messages from the App to be rendered in reply to messages sent by the users, so solutions like "open a new channel" or "send direct messages" are not suitable for my needs.
Thank you all (but the Slack team which, in case let us doing that, it makes that not clear in the documentation :D )
This is not possible unless you create your own client to show/display the messages.
Custom slack apps usually augment to the existing functionality. How do you expect to override the functionality of Native Slack 'Desktop, Mobile & Web' Client.
I am happy to discuss this further, if you have some approach in mind.
So when I submit a braintree order for settlement, there will/can be multiple state changes until I get my money. It can settle, stay in settling, get declined, and so on.
How can I get this information without having to call their API constantly? Is there some kind of webhook for that? Because in my tests, I only get updates for disbursements, which is (if I understood it correctly) basically the last step of the whole transaction.
There are webhooks for some events, but not for specifically when a transaction changes status.
You can, however, use the Search API to create a script or cron job that checks for status changes over a period of time.
If you have additional questions about webhooks or using the API, contact Support.
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.
My web app has an event scheduling feature, and I'd like to automatically create, update, and delete calendar events from users' individual calendars as the event details change on my site.
My plan to do this is to set up an automated/service user (e.g. events#example.co) and use the Calendar API to send invites that come from that user. As the event gets updated I continue to use the API through that user (using a server-to-server authentication protocol, so no human authorization required) to modify the event and deliver updates
If I'm scheduling several thousand events - will this scale with just one user? It doesn't feel right to schedule so many events under one automated user. But then again, it might work just fine.
Is there a limit to how many events I can schedule?
Is there a more sane way to approach this overall?
Thanks!
The google calendar api applies some standard quota limits on you. Basically the number of requests that you can make. However when you are planing on using a single user then there will be some other rules you will need to consider
Copied from here
If a user has created more than 10,000 events in his or her calendar within a short period of time, that user might lose calendar edit access.
If a user creates more than 25 new calendars within a short period of time, that user's calendar might go into read-only mode.
In order to prevent spamming, Google Calendar limits the number of invitations a user can send to external guests. This limit varies depending on the action, and is usually between 100-300 guests.
You can do this using a service account. To my knowledge there is no limit to the number of events you can put in a calendar per day however as stated above there will be a limit to how many you can insert at once.
I am not aware of a more sane option than this sorry.