- Use new parse_datetime() method
- Drop message with error if MAM doesnt supply a timestamp.
- If the user supplys an own timestamp, save it so we can decide in the
future how to display it.
Goal is to make the logger module easier to maintain in the future
- extract deduplication out into a own method, so we can use it
on its own in some other places.
- add new insert_into_logs() method
the DB fields we want to write to are passed as arguments, this makes
it so we dont have to change the method when we add or remove DB fields
in the future.
- instead of using get_jid_id() all around gajim to get the jid_id
before we write to the DB, we only have to pass the jid to
insert_into_logs(), it makes sure to get the correct jid_id or add
one in case it doesnt exist.
This handles every possible XEP-0082 timestamp
It has some additional options:
- Check if a timestring is a valid UTC timestamp, as required by some
XEPs (for example: XEP-0203)
- Return timestamp as datetime in UTC
- Return timestamp as datetime in localtime
- Return timestamp as epoch
Set source IDs to None after removing the source
except when shutting down, because the Control ist destroyed anyway
Only try to remove if we have a source ID
- The 'configure-event' does not trigger anymore when connected to
the MessageTextView. The reason is unknown.
- Use our own ScrolledWindow Widget instead so we can better control
the dimension of the MessageTextView
We get our full JID on the bind event.
After that it is saved in the `registered_name` attr on the Connection
Object.
In case the bind never occured we get the bare JID from config.
- Condition type = groupchat is not needed because we drop messages
type groupchat that come from the user archive. To get these messages
we will query the MUC.
- Because of this the logging method save_if_not_exists() can be much
simpler
A missing stanza ID means, we will have to take some measures to make
sure we get no duplicates in the Database later on.
Also fix getting the origin-id. Third time is a charm.
The gaol why we need to determine what ID should be used as stanza-id,
is so we can use the stanza-id in the future for deduplication.
Case we are the sender:
Either we look for a origin-id element, which we will include in the
Future in all messages we send, or until then the ID we set on the
message as attr.
Case we are the receiver:
If our server supports mam:2 we take the ID of the result element,
because mam:2 injects the archive ID live into every message we
receive. If we dont have mam:2 we fall back to the ID of the message
attr.
- Refactor and clean up code around MamMessageReceivedEvent
- Goal is to add a GcMamMessageReceivedEvent later on
- For that cause added a raw-mam-message-received base event
This lets us attach all attributes of the base event to the
new event. Often Events trigger other Events. When that happens
we often want to keep all attr from the previous Event, and just
continue under a new Event. Until now all attr had to be pulled
out of `self.base_event` again.
- Refactor get_last_date_that_has_logs()
- use NATURAL JOIN in SQL query instead of multiple SELECT via
_build_contact_where
- make code more concise
- update method documentation
- use NATURAL JOIN in SQL query instead of multiple SELECT via
_build_contact_where
- make code more concise
- update method documentation
- Fix a bug where messages were displayed in wrong order when
they had the same timestamp
Philipp Hörist
Yann Leboulanger
Yann Leboulanger