aboutsummaryrefslogtreecommitdiffstats
path: root/wee_slack.py
Commit message (Collapse)AuthorAgeFilesLines
* Add option to show thread messages in parent channel (#616)Josip Janzic2018-10-211-32/+40
| | | Closes #546
* Use an adaptive eventrouter timerTollef Fog Heen2018-09-301-1/+12
| | | | | | | If there's more work, schedule ourselves more often, if there's less, back off a bit to lessen the CPU load. Fixes: #523
* Set tag slack_muted_channel on muted channel messagesTrygve Aaberge2018-09-041-7/+13
| | | | | | | | | | | | The tag slack_muted_channel is set on all messages in channels which are muted, and all messages in threads which belong to muted channels. If you use a plugin for push notifications and don't want notifications from muted channels, you can set it to ignore messages with this tag. This would give you the same behavior as with the official client. Note that this just applies to messages shown in the hotlist, i.e. highlights (depending on your config) and thread messages, as messages hidden from the hotlist are probably already ignored by the notification plugin.
* Print result from /slack mute commandTrygve Aaberge2018-09-041-8/+9
| | | | | Prints either "Muted channel #x" or "Unmuted channel #x" to the team buffer.
* Add a 'muted_channels_activity' config optionTrygve Aaberge2018-09-041-4/+21
| | | | | | | | | | | | This allows you to control which activity from muted channels you will be notified for. The default is set to personal_highlights, as I find that the most useful. The official client doesn't send a notification for any activity, but it shows highlights in the sidebar, so all_highlights is probably the closest to that. However, since there isn't any difference between highlights from muted and non-muted channels in wee-slack, I think getting channel highlights from muted channels is a bit much.
* Always call set_highlights in set_highlight_wordsTrygve Aaberge2018-09-041-4/+3
| | | | | If highlight_words is set to nothing, we should still call set_highlights to remove any previous words.
* Implement showmuted command properlyTrygve Aaberge2018-09-041-2/+5
| | | | | Show channel names instead of id's, and show them in a more readable format.
* Set muted channels to empty set if no muted channelsTrygve Aaberge2018-09-021-1/+1
| | | | Previously, it was set to the set of an empty string.
* Hide activity from muted channelsTrygve Aaberge2018-09-021-8/+14
| | | | | | | | | | | | | This sets the correct tags for messages in muted channels and prevents muted channel from being added to the hotlist on start and when a message arrives. Threads from a muted channel are not muted. If you are part of a thread, you probably want to be notified for messages in it, even though the parent channel is muted. The official client shows messages in threads from muted channels in "New threads" with a highlight in the sidebar. Fixes #456
* Support passing muted as a keyword arg to tag()Trygve Aaberge2018-09-021-16/+16
| | | | | For muted channels, we need the tags for muted in addition to the tags we normally want.
* Set correct tags for topic messagesTrygve Aaberge2018-09-021-1/+2
| | | | | Don't mute topic messages, set the irc_topic and slack_topic tags and let people filter them as wanted.
* Notify of new mentions in subthreadsIsmaël Bouya2018-08-281-6/+41
|
* Move open thread to thread message methodIsmaël Bouya2018-08-281-6/+7
|
* Separate mentions and highlights in channelsIsmaël Bouya2018-08-281-2/+7
|
* Use highlight notifications for MPDMsTrygve Aaberge2018-08-251-2/+2
| | | | | | | | | DMs with multiple persons should highlight just like DMs with one person, instead of notifying without highlight like a channel. This seems to have been the intention all along, but it didn't work because the channel type was checked for mpdm, not mpim which is what the type is set to (even though the class is called SlackMPDMChannel.
* Colorize edits and reactions (#608)Immae2018-08-241-4/+8
|
* Don't print whitespace before join/leave messagesTrygve Aaberge2018-08-231-2/+2
| | | | | | The join/leave prefix ends with a tab (which is used to separate nick and message), but we also add a tab in buffer_prnt, so the join/leave messages ended up with a tab in front of them.
* Show inviter for join eventsTrygve Aaberge2018-08-231-2/+6
| | | | Fixes #538
* Print error if trying to send message in team bufferTrygve Aaberge2018-08-221-0/+3
| | | | | | Prevents a traceback if you try to send a message in the team buffer. Fixes #543
* Cleanup process_replyTrygve Aaberge2018-08-211-25/+8
| | | | | | | | | | | | | There is no point in creating a SlackMessage when we're just going to use message_json. I think this is just left over from when more of the message was actually used. It's not necessary to reset ws_counter. Python supports arbitrarily large ints, and Slacks docs doesn't specify a limit (it does says that the int should be unique for that connection, so this is more in line with the docs). I tested the API with 2^65 and that worked fine. It returns a string instead of an int if it's larger than 2^31 - 1 though, so we convert it to an int to be sure.
* Release v2.1.1v2.1.1Trygve Aaberge2018-08-201-1/+1
|
* Fix missing nick for own messagesTrygve Aaberge2018-08-201-2/+3
| | | | | | | | | | | | | | This was introduced in commit 51c2e76 because I removed user from the request believing it to be unnecessary. I think the reason I didn't experience this problem after removing it (I'm pretty sure I tested it), is that we might receive both a message event and a request response for the message, and we use the first of those that arrives. The message event will always contain the user, while the request response will not (but it's passed along if provided as in this commit). Fixes #612
* Release v2.1.0v2.1.0Trygve Aaberge2018-08-201-1/+1
|
* Handle missing unread_count_display fieldsTrygve Aaberge2018-08-201-7/+4
| | | | | | | | | I have experienced unread_count_display missing from channels.info for some channels. It seems consistent for those particular channels, but I'm not sure what's different about them, or why it's missing from them. I haven't seen it missing from groups.info or conversations.open, but I figured it was best to set it the same way in the three methods.
* Simplify and cleanup process_messageTrygve Aaberge2018-08-201-31/+10
|
* Add a helper for getting functions with a prefixTrygve Aaberge2018-08-201-5/+10
|
* Don't render messages surrounded by _ as actionsTrygve Aaberge2018-08-201-8/+1
| | | | | | | | | | | | | | | Even though me_messages and messages surrounded by underlines render equally in the official client, it is two different types of messages. Converting messages surrounded by underlines to me_messages causes problems when editing, because the underlines will be removed from the message so it won't be shown as an action anymore. The official clients sends me_messages as that subtype, and after the previous commit, wee-slack also does this, so there is no reason for this conversion anymore. Since subtype isn't changed in SlackMessage anymore, we can use the subtype variable we have, and the comment is not needed anymore.
* Send actions as actual me_messagesTrygve Aaberge2018-08-201-10/+22
| | | | | | | | | | Previously, we would just surround the message with underlines. While this renders equally in the official client, it's not actually a me_message, which shows if you try to edit the message. me_messages are not currently supported in threads. If you try to send one in the official client you will get an error, so print an error in wee-slack as well.
* Reset color after nickTrygve Aaberge2018-08-191-1/+1
| | | | | | | | This changes the color of the text of action messages to normal color so that only the nick before the text is colored. This is the same as the irc plugin does. Fixes #355
* Keep nick when actions (/me messages) are editedTrygve Aaberge2018-08-191-4/+5
| | | | Fixes #463
* Set last_read when marking channel as readTrygve Aaberge2018-08-181-2/+4
| | | | | | This fixes a bug where old messages would show up as new instead of as backlog messages when channel history is reloaded (i.e. when running /rehistory or after reconnects).
* Clear messages before processing historyTrygve Aaberge2018-08-181-8/+3
| | | | | | | | | | | | If a message arrived after history was requested, but before the response arrived, it would be lost. It would be printed after the "getting channel history" text, and then handle_history would clear that, and it would not be printed again since the message ts already was processed. By clearing the messages dict, the message will get processed and printed again. So we should never clear the buffer without also clearing the messages, to prevent such problems.
* Don't try to modify buffer line when message not foundTrygve Aaberge2018-08-171-9/+9
| | | | | | | | If the timestamp given to change_message doesn't exist in the messages dict, just return. Previously an unknown ts would make modify_buffer_line crash unless text was set, because modify_buffer_line fails if text is None.
* Update message_json when message is changedTrygve Aaberge2018-08-171-3/+5
| | | | | This fixes an issue introduced in commit d7b26dd where (edited) would not show up after changed messages.
* Fix marking buffer as read after printing own messsagesTrygve Aaberge2018-08-171-8/+5
| | | | | Make sure to mark the buffer as read right after we print a message from our own user, so we don't see a flash of the unread bar.
* Don't process message again if it already existsTrygve Aaberge2018-08-171-0/+4
| | | | | | | | | | | | | | | | | | The API has started to send both responses for sent messages as well as message events for the same messages. Previously, we would only get message events for messages from other clients. For the messages we send ourselves we would just get responses, and no message events. This caused wee-slack to print own messages twice, once for the response and once for the message event. To prevent this, check if we already have a message for the ts, and if we do, ignore the new message. I don't want to rely on only the message events and ignore the responses, because this change has rolled out gradually, so not all users might get message events for own messages yet. Additionally, the docs are not clear on what the behavior should be. Fixes #606
* Clear messages dict when refetching historyTrygve Aaberge2018-08-161-6/+9
| | | | | | | | | | When refetching the history, we clear the buffer because the messages will be printed again. Now the dicts for messages and hashed_messages are also cleared, so they match what we actually have in the buffer. This is necessary so we can check if a message is in the messages dict to find out if it's printed to the buffer, which we need for the next commit.
* Move message edited text to render and remove message suffixTrygve Aaberge2018-08-111-21/+15
| | | | | | | | | | | The message suffix is only used to show that a message is edited. Instead of keeping track of the suffix, just check if the message has been edited in the render function, and add the text there. This way, we only have to add the '(edited)' text one place. With this change, the edited text moves to right after the message text, before the attachments and files. It also fixes a bug where '(edited)' would not show on messages that have a thread.
* Remove url replacing for file_share message subtypesTrygve Aaberge2018-08-101-9/+0
| | | | | | | | | Slack doesn't use the file_share subtype anymore, as file uploads are now sent as normal messages with files attached. The urls we render for files attached to messages are the same as the urls this code previously inserted. The urls this code replaced out are gone from Slack.
* Render files after message instead of changing message textTrygve Aaberge2018-08-101-8/+10
| | | | | | | | | | Instead of changing the message text, append the files belonging to the message when we render the message. This is the same as we do with attachments. This fixes the issue where the files would not be shown anymore if a message is changed. The rendering format of the files is changed to match the way we render refs.
* Remove unnecessary stuff in message changedTrygve Aaberge2018-08-101-24/+3
| | | | | | | I don't think any if this is used anymore. The function changed message_json, but that was not used after it was changed. It also added attachments, but render is called later which also adds attachments, so they ended up being included twice.
* Adding support for new slack upload message style (#599)David Thorman2018-07-281-0/+8
| | | | | | * Adding support for new slack upload message style * better handling of empty messages
* Merge pull request #462 from ericdwang/shared-channelsTrygve Aaberge2018-06-271-43/+144
|\ | | | | Add support for shared channels
| * Use team id to determine if user is externalTrygve Aaberge2018-06-071-12/+14
| | | | | | | | | | | | The is_stranger attribute isn't clearly documented, so it's safer to check if the team_id of the user matches the team_id of the team we request the user in.
| * Handle get_sender being called before users.infoTrygve Aaberge2018-06-071-16/+10
| | | | | | | | | | When messages were loaded before the user info were fetched for an external user, this would crash.
| * Don't assume all users.info responses are for external usersTrygve Aaberge2018-06-071-2/+2
| | | | | | | | | | We might want to use this request for other users as well in the future, so we shouldn't assume that all of the users received by it are external.
| * Ensure presence is always set on SlackUserTrygve Aaberge2018-06-071-3/+4
| | | | | | | | | | The presence attribute is missing in the response for external users, so we just set it to unknown.
| * Check if user exists in is_user_presentTrygve Aaberge2018-06-071-1/+1
| | | | | | | | | | This method may be called before an external user is fetched, so it doesn't exist yet.
| * Use users list to check if user info should be fetchedTrygve Aaberge2018-06-071-3/+1
| | | | | | | | | | This is probably more reliable than depending on the topic not being set.
| * Combine users and external_users listTrygve Aaberge2018-06-071-14/+6
| | | | | | | | | | | | | | | | | | | | | | Since we have an is_external attribute on the users, it's simpler to just have them all in a single list. The documentation says that the user id is not necessarily unique across teams, but I talked to Slack and they said it's unlikely to be a collision. If you refer to a user in a message, you only use the id without a team id, so you will have problems with collisions there anyway. I'm waiting to hear from Slack how to handle that.
generated by cgit (git 2.34.1) at 2024-11-16 22:49:24 +0000