I have an old slack app that relies on channel.join. I need to migrate conversations.join. The APIs have two different keys. Channels allows you to use the channel name, and conversations requires a conversation id. How do you convert them? conversations.list -> loop?
You will probably have to loop. The new API is very focused on IDs and the advice is to store the IDs of the channels you want to join not their names, because name can be changed at any time. It feels like they’re saying you can join by name if you want but we won’t make it easy for you :) It's probably good advice tbh.
Related
Whenever there is a channel with the name that matches a certain regex, we want to add a certain group of members to these channel automatically. For example, if a new slack channel with the name that matches the regex INC-.* is created, slack group #incidentmembers will be added to that new slack channel automatically
Is there a way to configure this in Slack?
There's no native way to do this in Slack, but you could build something using the public APIs. Specifically you would
Listen to the channel_created event which fires when a public channel is created, which you can then regex as you see fit.
Grab the membership of the relevant User Group using usergroups.users.list (if the membership is static you could probably skip this)
Use conversations.invite to add the users to the channel
One limitation of this approach is that you won't get channel_created events for private channels. There's no way around this I'm afraid.
As explained by this post, when the client first connects with the server, a “main socket/process” gets created and holds its assigns. Later, when the client joins specific channels/topics, each channel’s socket/process copies those assigns and can add to them as it will.
I now have a use case where, upon the user joining their own individual channel (i.e. user:#{user_id}), I retrieve some information about the user from the DB, which should then be globally available to all channels this user later joins. However I haven’t been able to find a way to put those information into socket.assigns so that they can be available everywhere. If I try to assign them, they will only be available in the socket.assigns of this particular user:#{user_id} channel.
Is there a way to do it? Should I just instead simply try to fetch all those information in one go when the user first connects, instead of when they join the individual user channel?
Different channels mean different sockets.
The easiest solution would be to maintain the permanent state (Agent, ETS, DETS, mnesia, ...), holding a map user_id => user_info and query this state whenever you need this info.
Writing a slack bot and I would like to be able to get a list of all the channels my bot is a member of. One way to do this is to call https://slack.com/api/channels.list, get a (potentially large) list of all channels and then search for the channels that the current (bot) user is a member of. This works fine, but seems very heavy handed.
Is there a better way? To get just the channels that a given user is a member of?
I think users.conversations is what you're looking for. Without additional params it will return all public channels the calling user is a member of.
No, there is no shorter way to get this information.
Actually, Slack recommends to use the new conversations methods for this task, since the members property in all other methods, e.g. channels.list has recently been changed to only return a truncated user list. See here for details.
With conversations you have to make an additional call per channel to get all channels a user is a member of. However it will work with all types of channels (e.g. public channels, private channels) at the same time.
The basic approach is:
Get the list of all conversations from conversations.list
Get the list of members per conversation form conversations.members.
So if you want your Slack app to be future proof and also work with large number of users better use the conversations methods for your task.
FYI you can now list user channels/conversations using:
https://api.slack.com/methods/users.conversations
Say, I have a channel named teamA, and also got a channel named subTeamB, and subTeamB is actually a sub-team of team A, e.g. all members in subTeamB included in teamA.
In this case, is that possible to have subTeamB nested inside teamA?
No, you can not have channels within a channel in Slack.
As a workaround you could name the channels in a way that they reflect sub-channels.
Examples:
#teamA-subTeamA
#teamA-subTeamB
This is also what Slack recommends on its documentation page about Organizing and naming channels.
They did say they were working on it, or something to better organize:
https://twitter.com/slackhq/status/503652089755873280
Makes sense. We're exploring better ways to organize / group large
amounts of channels. Stay tuned! ✨— Slack (#SlackHQ) January
9, 2016
If I need to keep track of a key or token that identifies a resource being displayed and modified in the browser, what are the some of the programming patterns used?
For example, if I display a list of movies and hookup ajax calls for users to checkout or review those movies, I'm assuming I would embed the identifier in the html which would then be passed back to the server.
Is it bad practice to use database keys? Is it bad practice to expose the identifiers in hrefs?
I don't consider a bad practice to expose a resource identifier to the clients. Doing so could overcomplex your system without any reason. If the database key is in fact your entity key, you can use it transparently.
The only pattern I can remember for displaying and editing data on the client side is DTO.
About the HREFs and your identifiers, a REST architecture would even recommend you to do so. It is a common practice ; )
Hope it helps you.
To start off, I do suggest using URIs to identify stuff. It's central to how the web works.
Exposing your database IDs to the client isn't too bad, but you should consider:
Clients that know about database IDs and use them to do stuff are introducing a subtle form of coupling. The more clients expect of these IDs (e.g. that they're unique) the more coupling there is.
Do the clients need to know that the items have database IDs at all? Perhaps it's OK to expose the ID buried inside a URI. Clients have no business disecting URIs to figure stuff out, so you're not strictly exposing it.
If the clients need database IDs, could that be merely as a display identifier? You could then embed the database ID in the data going over the wire, but mark it up in such a way that it's understood that the ID should only be used to show users the identifier, in case they have a vested interest (because the ID is leaked elsewhere).
Removing the database ID from the URI suggest having another unique identifier which is not a primary key in some database.
Consider how e.g. Twitter's own twitter account has a list of the team:http://twitter.com/twitter/team The well designed URI exposes very little, so they could change their entire implementation without URIs being a problem. A single tweet on twitter has something which looks like a primary key http://twitter.com/meangrape/status/18622784109 but who's to know.