In bug 54814, Xavier wrote: > self_id is also wrong, you can't parse the object path to get the self_id. > It should be tp_account_get_normalized_id() He's referring to this code in log-store-xml.c: if (!tp_account_parse_object_path ( tp_proxy_get_object_path (TP_PROXY (account)), NULL, NULL, &self_id, &error)) { DEBUG ("Cannot get self identifier from account: %s", error->message); // ... } and then self_id is used as if it were the user's own identifier, which it is not.
We have discussed this issue already, and the conclusion is that a correct storage should properly save the ID, and not rely on object patch in any ways. The things is that logger data should be readable event if the accounts no longer exist.
Reading the code, that self_id is used to create the receiver TplEntity. But we never care about the receiver, Tp*Message never have a receiver... How do you define the receiver in an unnamed MUC anyway? Maybe I'm overlooking something, but I feel that the correct fix is to trash that code actually. The best patches are patches that remove code :D
(In reply to comment #2) > Maybe I'm overlooking something, but I feel that the correct fix is to trash > that code actually. The best patches are patches that remove code :D That will cause more harm then good. As said, the root of the problem is the original design of the storage, information whould have been saved while it was available. When you read back from the store, you can't assume that there is a valid TpAccount for that data. Long term solution is to drop that storage, and replace with a new one. Short term, well you can't fixed the stored data really, so I don't see any magic solution. But if the account exist, one would use tp_account_get_normalized_name(), and fallback to the current code when that fails. That could be a good compromise and work in most cases. If the account no longer exist, nobody will care how exact the id is.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-logger/issues/35.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.