| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently it varies how many users can be fetched in one request with
the users.info method. I have had successful requests with 4096 users,
while some people have reported getting HTTP 500 when fetching 1000
users and one person got an error response with error `too_many_users`
when fetching 500 users.
So when we get either of those errors, reduce the number of users we
fetch in one request and try again until it works or the number of users
has been reduced to 1.
Fixes #924
|
| |
|
|
|
|
|
| |
It seems like for enterprise workspaces you have to use the enterprise
id (if the token is a workspace level token,
`enterprise_id/workspace_id` can also be used, but isn't necessary),
while for non-enterprise workspaces the workspace id should be used.
|
| | |
|
| | |
|
| |
|
|
|
| |
Some users have gotten HTTP 500 from the API when trying to request 1000
users in one request.
|
| | |
|
| |
|
|
|
| |
For now this only supports known channels, which currently typically
means they have to be referenced in a channel with history loaded.
|
| |
|
|
|
|
| |
For now this only supports known nicks, i.e. mostly nicks that have
posted a message, is mentioned in a message or appears in the nicklist
in any of the conversations that's loaded.
|
| |
|
|
|
|
|
|
|
| |
Files uploaded in Slack Connect channels doesn't contain any
information, so we have to make a request to files.info in order to get
the information to render it.
See https://api.slack.com/apis/channels-between-orgs#check_file_info for
more info.
|
| |
|
|
|
| |
It's better to post nested objects as JSON rather than url encoding
them, and this fixes some type errors.
|
| |
|
|
|
|
|
| |
It's now possible to set and clear the uses status.
For now it's not possible to set the status emoji or the status expiration.
Signed-off-by: Pierguido Lambri <plambri@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The user can now set the presence with:
/slack presence away
Or:
/slack presence active
Signed-off-by: Pierguido Lambri <plambri@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's possible to have a token that's only for one workspace in an
enterprise grid. For me with such a token, it returns channels in all
workspaces in client.userBoot, but only channels in the tokens workspace
in client.counts. This meant that we didn't get last_read for all
channels we opened, and additionally some methods like
conversations.members would fail with "channel_not_found" for those
channels.
This filters the channels from client.userBoot by checking that the
channel is in the current sub workspace, if the token we're using is not
an org level (for all workspaces the user is in) token.
Additionally it raises an error if any of the channels to open isn't
included in the response from client.counts to prevent missing last_read
for any channels if there are other channels that isn't included. I
could have filtered the list of channels to open by the channels
included from client.counts, but I don't want any channels to just
silently be ignored.
|
| |
|
|
|
| |
The cookies need to be encoded for the Slack API to accept them, so this
makes it work if the config is set with cookies that are not encoded.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some enterprise workspaces are restricted in which API methods they can
use, so we have to use some of the APIs the official web client uses
(which can't be used by OAuth tokens) instead (mainly to initialize the
workspace with client.userBoot and client.counts, and to connect to the
websocket).
This also has the benefit of being more performant, as the API methods
the web client uses are more suited for creating a client than the
official API methods.
I think which API methods are restricted may be configured by the
workspace admins, so it may not be the same for different workspaces,
but for me it seems to be at least rtm.connect, users.conversations,
conversations.list and conversations.members, so these are the ones I've
changed to be conditional on the token type.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If you try to request several thousand users in one request (not sure
exactly what the limit is), it just returns HTTP 500, so split it into
multiple requests with a max of 1000 users per request.
|
| |
|
|
|
|
| |
This is done so we can know if we should include a message hash when
completing thread hashes, and it also has the benefit of eliminating the
loading time when opening thread buffers.
|
| | |
|
| |
|
|
|
|
| |
Instead of having to supply both a limit and the number of pages, change
it to only take in a limit, and determine the number of pages
automatically.
|
| | |
|
| |
|
|
|
| |
Since this isn't available for OAuth tokens it's good to have an easy
way to see where it's used.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This uses Slacks edgeapi which only works for session tokens, but has
the benefit of being able to complete nicks without all users being
loaded. So need to add some completion for the loaded users for when
using OAuth tokens as well.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Turns out you can query for multiple users/bots with
users.info/bots.info even though it's not documented. Use that to query
for multiple users/bots in one request, instead of making tons of
requests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
