Bug 64126

Summary: log-store-xml should use tp_account_get_normalized_name to get self_id.
Product: Telepathy Reporter: Will Thompson <will>
Component: loggerAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED MOVED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: xclaesse
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Will Thompson 2013-05-01 17:02:56 UTC 
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.
Comment 1 Nicolas Dufresne 2013-05-01 17:47:18 UTC 
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.
Comment 2 Xavier Claessens 2013-05-02 12:51:13 UTC 
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
Comment 3 Nicolas Dufresne 2013-05-02 19:21:50 UTC 
(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.
Comment 4 GitLab Migration User 2019-12-03 19:32:05 UTC 
-- 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.