| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #550 properly.
|
|
|
|
|
|
|
|
| |
The commit 74da303 introduced a regression with messages not being shown
as deleted anymore because deleting only changed the text field, and
that's not being used anymore with that commit.
Fixes #897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just using the text field of a message, use the rich_text
blocks to format the message.
The main reason for doing this was that messages that include images
suddenly started just having "This message contains interactive
elements." in the text field.
There are some other benefits as well:
- It fixes some bugs with multiple formatting styles not being applied
correctly.
- It fixes links in code blocks not being rendered verbatim (but with
text and url, like outside code blocks).
- It fixes code blocks sometimes having newlines after/before ``` and
sometimes not, depending on how the message was sent.
It looks like messages with images are now back to having the proper
text in the text field (for new messages), so this change isn't
necessary to fix that after all (except for for messages in the history
sent in the last couple of days), but since it fixes other issues as
well, it's best to keep it.
There is one bug left when inline code blocks contains links. Then there
will be ` characters before and after the link, which shouldn't be
there, but I'll leave fixing this for later.
Fixes #354, fixes #550, fixes #893
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The url_private link for Slack posts just downloads a json of the post,
which isn't very useful to click on. The permalink goes to the web view
for a post, which is what we want. The web client adds origin_team and
origin_channel, which makes the post page show info about where the post
is shared, so add that here as well.
We still want to use url_private for images etc., not permalink there as
well, because that links to the Slack client with the image shown in the
sidebar, which is much more inconvenient than just getting the image
directly.
|
|
|
|
|
|
|
|
|
|
|
| |
One user experiences receiving a "HTTP/1.1 200 Connection established"
header block before a "HTTP/2 200" header block with the headers. I'm
not sure why specifically this happens, but I know a similar response
will happen if redirects are followed.
This wasn't supported by the http_check_ratelimited function which
splits the header from the body. It now splits out all the header blocks
from the body and uses the status and headers from the last one.
|
| |
|
| |
|
|
|
|
| |
This is a necessary step for #844
|
|
|
|
|
|
|
|
|
|
|
| |
rtm.start is deprecated and will stop working on September 20, 2022.
This patch replaces it with several other API endpoints to get the info
we need.
The handle_rtmstart method is kept for the test setup to work, but this
setup should also be replaced with the new API endpoints.
This is a necessary step for #699 and #844
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, some MPIMs are listed in the channel list of the
response from rtm.start, with is_mpim set to true, instead of in the
mpims list. These incorrectly appeared as private channels instead of
MPIMs in wee-slack.
These entries do not contain a members list, so we have to call
conversations.members and set the name after receiving the response from
that.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, the API now sends an mpim_joined event when an MPIM is
created instead of a group_joined event, even if we don't set mpim_aware
to true.
Instead of just handling mpim_joined in addition to group_joined (which
could cause issues if both are called for MPIMs, though I haven't
experienced that), it's better to properly support mpim_aware.
Fixes #825, fixes #833
|
|
|
|
| |
E203 should be ignored when using black according to their docs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Relates to #797
|
|
|
| |
Fixes #781
|
| |
|
|
|
|
|
|
|
|
|
| |
Thanks to @Informatic for the initial implementation of this in PR #426.
I have seen that most attachment colors are without the leading #, but a
few does include it, so we have to handle it.
Fixes #424, closes #426
|
| |
|
| |
|
|
|
|
| |
Fixes #514
|
| |
|
|
|
|
|
| |
This is so we can show the hash for a thread message when the parent
message isn't fetched.
|
|
|
|
|
|
| |
background_load_all_history is set
Fixes #629, fixes #715, closes #732
|
| |
|
|
|
|
| |
Fixes #728
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We should only use the fallback if we don't get any information out of
the attachment. For links that exists in text_before, we have gotten the
information from the attachment, but choose not to display it so we
don't end up with duplicate links. Therefore, we shouldn't use the
fallback in this case.
|
|
|
|
|
| |
The urls in the attachment fields can apparently come both escaped and
unescaped.
|
| |
|
|
|
|
|
| |
Prevents showing "http://some.url (http://some.url)" if the url has a
fallback which is equal to the url.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a thread on a thread message is not possible, so the logical
thing to do if a user tries to reply to a thread message is to put the
message in the same thread as the message that is replied to.
Slack currently has a bug which causes thread messages to be converted
to normal messages if you try to reply to them (that is, send a message
with thread_ts set to the ts of the thread message), but the message you
reply with will end up in the original thread. I filed an issue and they
confirmed that it is a bug, and that you should not send messages with
thread_ts set to the ts of a thread message.
Fixes #751
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, the date tests of the last commit only work in one time
zone. This changes them to work in UTC. If your machine doesn't use UTC,
you now have to run the tests like this:
TZ=UTC pytest
I'm not sure what the best way to avoid requiring this is.
|
| |
|
| |
|
|
|
|
|
|
| |
Fallbacks in messages are not changed when channels/users/groups are
renamed, so they shouldn't be used unless the ref can't be found. Links
are not refs we look up, so they are still treated the same way.
|
|
|
|
|
| |
This is only used in tests and in render_topic, and I don't see why
render_topic shouldn't follow the global config that is set.
|
|
|
|
|
| |
This is only used in tests, and there we can override the config
instead.
|