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
`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
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
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.
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
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
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.
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>
In most get-like funcitons libstrophe returns pointer to a string
that resides in an internal structure (e.g. xmpp_stanza_t). Hence,
Profanity must not change such strings. Define respective variables
as 'const char*' to reduce a chance of error and conform future
libstrophe's interface.
This patch mostly replaces 'char *' with 'const char*', but also
fixes two memory leaks after stanza_get_reason(). Add comment within
stanza_get_reason() to fix conflict with different allocator types.
