aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Set label to short_name when short_name is setTrygve Aaberge2020-06-141-0/+19
| | | | Fixes #563
* Move common destroy_buffer code to SlackChannelCommonTrygve Aaberge2020-06-121-6/+7
|
* Fix parameter names for signal hooksTrygve Aaberge2020-06-121-12/+10
|
* Support /label for channelsTrygve Aaberge2020-06-112-15/+19
| | | | Relates to #563
* Rename thread full name even when label is setTrygve Aaberge2020-06-111-2/+3
| | | | | Label is only for the short_name, so we should always rename the full name.
* Simplify message type check in prnt_messageTrygve Aaberge2020-06-101-2/+2
|
* Fix thread broadcasts not being reprinted in channelTrygve Aaberge2020-06-101-2/+3
|
* Fix broken tests on Python 2Trygve Aaberge2020-06-071-0/+3
| | | | The tests were broken in commit 855cf3c.
* Fix parameters for SlackPrivateChannel.get_historyTrygve Aaberge2020-06-071-2/+2
| | | | This was broken in commit cd888c2.
* Set history_needs_update when receiving historyTrygve Aaberge2020-06-071-0/+3
| | | | | | | | | If wee-slack looses connection to the server while a history request is in the queue and reconnects before the history response is received, it will set history_needs_update to True and call get_history, but since a history request is pending, a new one won't be triggered so history_needs_update will remain True. Setting history_needs_update to False when receiving the history fixes this.
* On load, fetch history after connected to websocketTrygve Aaberge2020-06-071-9/+7
| | | | | | | | | | | | | | | | The websocket url is only valid for 30 seconds. If wee-slack didn't manage to connect in time, it would set history_needs_update and reconnect, but not load history again which meant that each channel would load history when you switched to the buffer. I also think there was a slight chance of a message being sent in the time between history loading and connecting to the websocket, which I think would mean it would be lost. By fetching history after connecting to the websocket, this can't happen. Lastly, by not fetching history before connecting to the websocket, I think there is less chance of not connecting to the websocket url before it expires.
* Disable print hooks when printing old/debug messagesTrygve Aaberge2020-06-071-0/+11
| | | | Fixes #629, fixes #756
* Remove try/except in buffer_prntTrygve Aaberge2020-06-071-10/+7
| | | | | There shouldn't be any exceptions here. If there are, we shouldn't catch them, so we can notice and fix them.
* Set tags in deterministic order with slack_ts firstTrygve Aaberge2020-06-071-19/+19
| | | | | | | Since we look up the message ts from the tags as of the last commit, we should place the ts tag first so we don't have to loop through the other tags when finding it. This should make it a bit faster to find a message, especially when we have to search through many lines.
* Store message ts in line tags instead of misusing date_printedTrygve Aaberge2020-06-072-41/+28
| | | | Fixes #514
* Rename buffers from team.slack.com to slack.teamTrygve Aaberge2020-06-071-1/+1
| | | | Fixes #709
* Refactor setting team nameTrygve Aaberge2020-06-071-18/+19
|
* Remove fixed issue from known issuesTrygve Aaberge2020-06-061-4/+0
| | | | This was fixed in commit ad1a715.
* Merge pull request #774 from trygveaa/history-after-reconnectTrygve Aaberge2020-06-066-388/+663
|\ | | | | Automatically reload history after reconnect
| * Prevent multiple thread notifications when mentionedTrygve Aaberge2020-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | There are two situations where notify_thread is called multiple times where we only want to notify once. One is when we load history for a thread which has multiple unread messages, the other is when you become subscribed to a thread because you are mentioned in it. For the first case, we want to set last_notify to now, so we don't notify for the rest of the unread messages following the first. For the second, the message ts may be greater than now (same second, but greater minor part), so we want to set last_notify to the message ts. Therefore we set last_notify to max of these two.
| * Fetch message replies if subscribed latest_reply > last_readTrygve Aaberge2020-06-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | When using conversations.history (which doesn't include replies), we want to fetch the replies for a thread even if thread_messages_in_channel is off if the user is subscribed to the thread and it has unread messages, so we can notify for new replies. Technically, we could notify without fetching the history, but it's easier to just fetch the history so the normal notification check is run, and when the thread has unread messages, the user probably wants to read them, so it's nice that they don't have to wait for history when opening the thread.
| * Set last_read when (un)subscribing to a threadTrygve Aaberge2020-06-041-2/+3
| | | | | | | | | | | | | | | | | | When you subscribe to a thread, I think it's safe to assume that you have read the messages or want to treat the messages as read, and this is what the web client does. I'm not sure what the point of sending last_read for unsubscribe is, but the web client does so, and it was easiest to do it for both.
| * Only mark subscribed threads as readTrygve Aaberge2020-06-041-0/+2
| | | | | | | | | | Slack doesn't support marking unsubscribed thread as read (it responds `message_not_found`).
| * Make history fetch count configurableTrygve Aaberge2020-06-042-3/+14
| | | | | | | | Fixes #376
| * Don't call buffer_clear on destroy_bufferTrygve Aaberge2020-06-041-5/+1
| | | | | | | | | | When destroy_buffer is called, the buffer will be closed, so there isn't any point in clearing it.
| * Mark thread as read when closing bufferTrygve Aaberge2020-06-041-0/+2
| |
| * Use max_buffer_lines_number instead of hard codingTrygve Aaberge2020-06-042-2/+4
| |
| * Refactor message id handlingTrygve Aaberge2020-06-041-91/+93
| | | | | | | | | | | | This creates a common method for getting a message from a message hash or count. Since all commands now use the same method, all commands that accepts a hash now also accepts a count.
| * Include thread messages in command countsTrygve Aaberge2020-05-301-14/+16
| |
| * Fetch thread when receiving a thread message and parent is not foundTrygve Aaberge2020-05-301-15/+24
| | | | | | | | Fixes #619, fixes #754
| * Use ts instead of count to limit visible_messagesTrygve Aaberge2020-05-301-10/+20
| | | | | | | | | | | | | | When fetching replies for older threads, the messages in the thread older than the first message we fetched from history would be displayed in the buffer. We don't want these to be displayed, because there may be other messages in between which we haven't fetched.
| * Rerender thread messages when hash changesTrygve Aaberge2020-05-301-0/+2
| | | | | | | | | | This is necessary for thread messages rendered in the channel, either broadcast messages or when thread_messages_in_channel is on.
| * Fix broadcast messages not being changed in parent channelTrygve Aaberge2020-05-301-1/+2
| |
| * Don't fall back to ts for thread hashTrygve Aaberge2020-05-301-6/+8
| | | | | | | | | | | | We don't allow the ts to be used in commands, so it doesn't make sense to fall back to it. After the latest commits, hash is always available, so just use that.
| * Use parent channels hashed_messages in SlackThreadChannelTrygve Aaberge2020-05-301-1/+4
| |
| * Store ts -> hash mapping in hashed_messagesTrygve Aaberge2020-05-302-52/+50
| | | | | | | | | | This is so we can show the hash for a thread message when the parent message isn't fetched.
| * Notify for newly subscribed threadsTrygve Aaberge2020-05-301-2/+12
| | | | | | | | | | | | | | | | | | When you receive a new thread message on one of your messages that's not already a thread you may get the subscribed event after the message event. Previously, that meant you would not get a notification, because notify_thread ran in process_message, before you were subscribed. Run notify_thread in process_thread_subscribed too to ensure we notify for these messages.
| * Refactor notify_thread methodTrygve Aaberge2020-05-301-15/+18
| |
| * Set last_read to SlackTS(0) when missingTrygve Aaberge2020-05-301-3/+6
| | | | | | | | | | | | | | | | | | | | | | When last_read is missing, we should assume no messages are read instead of all up until the channel/message is created. The only time I know this happens is for messages that are not yet thread parents. This probably doesn't matter in practice though. For new thread parents the messages that make it a thread parent will arrive after we create the message, so they would have newer ts than the one we set for last_read. Still, I think it makes more sense to set it to 0.
| * Use last_read for parent message when checking mentions notifyTrygve Aaberge2020-05-301-4/+5
| |
| * Support old messages in thread (un)subscribeTrygve Aaberge2020-05-301-6/+12
| | | | | | | | | | Old messages, as in parent messages that's older than the history we fetch.
| * Keep submessages from old message when storing newTrygve Aaberge2020-05-301-0/+5
| | | | | | | | | | | | | | | | | | Submessages (or replies) are not a part of the message anymore with conversations.history, we have to call conversations.replies to get them. So when fetching the channel history, the new message will have an empty submessages. Keep the old, so we don't have to call conversations.replies for each thread parent every time we call conversations.history.
| * Keep "getting channel history" until thread messages are fetchedTrygve Aaberge2020-05-301-7/+29
| |
| * Fetch thread messages when loading channel history if necessaryTrygve Aaberge2020-05-301-10/+24
| | | | | | | | | | | | | | | | | | conversations.history doesn't include thread messages, so when we use that and thread_messages_in_channel is on, we have to call conversations.replies for every thread parent we encounter to fetch the thread messages. Fixes #664
| * Combine receive and receive_slowTrygve Aaberge2020-05-301-21/+7
| |
| * Default background_load_all_history to trueTrygve Aaberge2020-05-303-12/+19
| |
| * Keep necessary messages beyond SCROLLBACK_SIZETrygve Aaberge2020-05-301-48/+109
| |
| * Move store_message back into subprocess functionsTrygve Aaberge2020-05-301-4/+7
| | | | | | | | | | | | | | | | | | | | In subprocess_thread_message we need to store the message before calling notify_thread, so storing it after the function returned didn't work. This is because when auto_open_threads is on and you get a new message, it will open the thread and print the messages immediately, which will fail because the message ts has been added to submessages, but the message has not been stored yet.
| * Check if channel_buffer exists in reprint_messagesTrygve Aaberge2020-05-301-3/+4
| | | | | | | | | | | | | | | | After thread buffers are closed, the instances still remains in channel.thread_channels, but channel_buffer is set to None. reprint_messages may be called after this, e.g. on a reconnect. Therefore, we have to check if channel_buffer is set before calling buffer_clear.
| * Include parent_message in SlackThreadChannel.messagesTrygve Aaberge2020-05-301-18/+18
| |
generated by cgit (git 2.34.1) at 2024-11-15 01:42:55 +0000