| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add resourcepart to the outgoing carbon that is logged, so we use the
correct filenames for MUC PMs.
Dont log incoming carbons of MUC PMs as a workaround to faulty server
behaviour.
See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under
'Client-side workaround behavior'.
Regards https://github.com/profanity-im/profanity/issues/1214
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.
We still need to make sure carbons log to the same file.
Regards https://github.com/profanity-im/profanity/issues/1214
|
| |
|
| |
|
|
|
|
| |
Forgot to check what happens if the length is <= 10.
|
| |
|
|
|
|
| |
And move defintion to xmpp.h
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`sv_ev_room_message()` called `groupchat_log_msg_in()` to log all
incoming MUC messages.
`cl_ev_send_muc_msg()` calls `groupchat_log_msg_out()`.
So messages sent by the user himself was logged two times.
Filter the incoming messages and only log the ones not from our occupant
jid/nick.
Fix https://github.com/profanity-im/profanity/issues/1201
|
|
|
|
|
|
|
|
| |
Incoming carbons are logged as normal message already.
So we had this logged twice but didn't log outgoing carbons,
send from our account but by another client, at all.
Fix https://github.com/profanity-im/profanity/issues/1181
|
|
|
|
|
|
| |
Carbons where not logged so far.
Fix https://github.com/profanity-im/profanity/issues/1181
|
|
|
|
|
| |
We don't need to do all the timing stuff if last activity is disabled
anyways.
|
|
|
|
|
|
|
|
|
|
|
| |
This occured with a user running Cisco Jabber. It seems this server
sends repeated presence subscribed stanzas. And although I find this
strange according to RFC this seems to be ok.
So let's filter them and only display in the console output and to the
log. But don't open seperate windows.
Fix https://github.com/profanity-im/profanity/issues/1165
|
|
|
|
|
| |
Small bug caused by 13675fb and ce5a4ed.
Fix https://github.com/profanity-im/profanity/issues/1142
|
| |
|
| |
|
|
|
|
|
|
|
| |
Probably missing copy of body to plain in carbon and privmessage.
Only covers the incoming message path because goal is OMEMO decryption
of untrusted message.
Cover some of the log functions but not all.
|
| |
|
|
|
|
| |
Like discussed with James.
|
|\
| |
| | |
Feature/704 ui behaviour reconnect
|
| |
| |
| |
| |
| |
| | |
After pasis review of my code he thinks it's better to safe the
timestamp per MUC so we can account for some problems that could occur
with timing.
|
| |
| |
| |
| |
| |
| | |
For #704 we don't show the room history upon reconnect.
Now we also don't show the room subject in the channel
upon re-established connection.
|
| |
| |
| |
| | |
Let's test for mucwin earlier.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If re-establish a connection don't print the room history again.
In case there there happened nothing at all since we got the room
history on the last connection.
And in case there were no new messages during the time we have been
disconnected.
Instead of printing the room history again we now print 'Re-established
Connection'.
This adds a bit of overhead since we save the timestamp upon every MUC
message.
See: https://github.com/profanity-im/profanity/issues/704
|
|/
|
|
| |
Should fix https://github.com/profanity-im/profanity/issues/1120
|
|
|
|
|
| |
Duplicate code in client_events.c and server_events.c. Let's have
events/common.c and a function containing that code.
|
| |
|
|
|
|
|
| |
Remove the windows, clear tls certs, clean omemo.
Regards https://github.com/profanity-im/profanity/issues/1089
|
|\
| |
| | |
Handle presence received before roster
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Presence of contact not found in roster are filtered out.
But sometimes roster is received after a first few presences.
We choose to store presences until we receive roster and then process
this presences.
Fixes #1050
|
|/
|
|
| |
This should close #1052
|
| |
|
|
|
|
| |
Add sv_ev_connection_features_received for that purpose
|
|
|
|
|
|
|
|
|
| |
Reflected messages can't be filtered by nick only otherwise you might
ignore messages comming from you on another devices.
Consequently we maintain a list of sent messages id in mucwin.
To be sure the id will be correctly reflected we use the origin-id
stanza.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix {signed,}_pre_key store
|
| |
|
|
|
|
|
|
| |
We try to decrypt all messages, if it's successful we use
sv_ev_incoming_message even for OMEMO messages. We pass an OMEMO
boolean to let UI be aware that message were encrypted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After specifying the PGP key ID with pgp.keyid within the accounts file on startup profanity asks for the secret key passphrase. It then doesn't redraw the screen, leaving it in an odd looking state.
This probably only happens with pinentry-curses since it draws in
screen.
We need this fix for cli only environments.
Fixes https://github.com/boothj5/profanity/issues/906 reported by Bob
Mottram.
Based on https://github.com/boothj5/profanity/pull/908 by Bob Mottram
Bob removed his GitHub account, so GitHub created a ghost placeholder
user for him, which unfortunately makes it impossible to cherry-pick
this commit. To more or less preserve authorship I added him as
co-author.
Commit picked and message edited by jubalh.
Co-authored-by: Bob Mottram <bob@freedombone.net>
|
| |
|
|\
| |
| | |
server_events: fix potential NULL pointer deref
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|