Summary: | pimsettingsexporter forget to setup correctly the database | ||
---|---|---|---|
Product: | [Applications] pimsettingexporter | Reporter: | Bruno Friedmann <bruno> |
Component: | general | Assignee: | Laurent Montel <montel> |
Status: | REPORTED --- | ||
Severity: | grave | CC: | info, kdebugs |
Priority: | NOR | ||
Version: | 4.12.2 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Bruno Friedmann
2014-02-23 15:31:55 UTC
"All accounts failed to connect to the imap, due to missing entries in wallet" we will not store in plain text password no ? I will not do it. "Any folders (trash,sent,drafts,templates) complain that they don't exist and ask to select one, but none of the account work so you have to use cancel." ? Laurent I mean all accounts failed to retrieve their login information from kwallet (if restored on the previous working computer) I think this is due to the fact that the imap account (name) is not restored correctly example in place of 00_bruno if got akonadi_ressources_0rc name 2nd point : You have to postpond the selection of any special folders ( in restore Trash is asked for each account) until the connection to that account is restored. If there's a failure to connect to that account, there's no other choice than use cancel to continue the next part of the restore. We don't use same account name id so we can't do it. 2nd point: normal if we don't have connection we don't have folder tree. I can't fix it if you can't connect to it. (In reply to comment #3) > We don't use same account name id so we can't do it. Okay then the tool can't be used to export & re import the same structure, and thus can't be considered as a backup tool. I would have expected that what is exported/backup is what I will get back. > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. Fair enough (In reply to Laurent Montel from comment #3) > We don't use same account name id so we can't do it. But why we can't use the same account name id? > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. This s problem. We can't connect because we use different id in kwallet. We can't get folder tree because we not connected. And we can't set proper folders because we not connected. So, import tool have circular deps. I ran into the same issue today while trying to restore a configuration on a new laptop. On the original PC I am using pim-data-exporter-19.04.3-2.fc31.x86_64, on the laptop where I want to import I am using 4:17.12.3-0ubuntu1 . Both are the default ones shipped on the respective systems (being Fedora 31 and Ubuntu 18.04LTS). (In reply to Laurent Montel from comment #3) > We don't use same account name id so we can't do it. > How hard would it be to fix this ? I haven't looked at the code (yet). However I think it would be sufficient to export a map of the user-visible account names to account name ids in the backup file and reuse this map to recover e-mail folder names on restore. The data is available on the PC where the backup is created. Why can't it be added to the backup so it can be reused during restore ? > 2nd point: normal if we don't have connection we don't have folder tree. I > can't fix it if you can't connect to it. The issue I see here is not really being unable to connect, but trying to restore folders before actually connecting. When I do a restore I first get a question to choose a trash folder. This trash folder originally pointed at a folder on the imap server. Only after successfully setting a dummy folder the restore process will ask me to connect to the imap server. That's backwards. I would suggest the restore first tries to make all remote connections and only then start mapping folders. Combined with backing up more details of how the accounts were named by the user at the original pc this would tremendously improve the export/import experience. Note I'm also being asked for folders related to 'IDENTITY_12345679' multiple times. The 123456789 changes for each request. I have no idea what these mean exactly. |