In the instant messaging settings there is an "Automatic connect" section with a "Restore last status" checkbox. This does not appear to do anything useful. When I login to KDE (automatic login with locked screen — sidenote: takes a few minutes for the desktop to become usable because my PC is slow), I am asked for the KWallet password by the Telepathy/KDE authentication manager. During that time, Telepathy/KDE often already reports connections as failing. After I enter my password, Telepathy/KDE does not switch my presence to online/auto-away or whatever it was last. The icon the presence plasmoid displays is the right one, but the accounts are not actually online. When I click the plasmoid, the contact list opens. When I hover the mouse over the status selector there, I see the list of accounts and their status. Most of them are in connecting state (except Bonjour, which is probably just very fast). This is reproducable, no matter how long I wait after login: The presence plasmoid will display a status, but when I actually open the contact list and hover its status selector, the accounts are shown as offline / connecting. Reproducible: Always
P.S: Usually, after I enter the KWallet password the first time, Telepathy/KDE will ask a 2nd time for the KWallet password. This is odd, because I enter the password correctly the first time, and I have configured KWallet to only close when the screensaver is activated or no application uses it anymore. So apparently Telepathy/KDE closes the wallet or does not tell it that it still needs it. What I expect from Telepathy/KDE and automatic connect is that it automatically connects all my accounts right after login and not just when I open the contact list. There might be multiple bugs involved here. I just mention everything that might be related, so you can tell me for which parts I should open a separate report.
The reason why you need to insert the password again is because the auth handler exits when he has no authentications to handle, it's not a bug it is the expected behaviour *** This bug has been marked as a duplicate of bug 300062 ***