Hello,

I do not see this problem.

We are using Thunderbird 31.6 (but never saw it in earlier versions either) and latest Lightning, with Connector/Integrator 31.0.1...

Maybe provide more details about your environment?

I would be very happy to get this sorted out!
We cannot role this out to out users like this, it would be a support nightmare! :(

As I said, this is a Thunderbird only thing, the WebGUI is fine.
So where to look at to provide more details?

I have also experienced this on three systems running SOGo 2.2.17a and Thunderbird 31.6.0 (on a variety of Windows, Linux and Mac platforms). One system was a fresh install on Ubuntu 14.04 and the other two were upgrades from 10.04 -> 12.04 -> 14.04.

This issue exhibits itself in a few ways. New events added to the TB calendar are not displayed immediately, as stated. It is also not possible to edit existing events as they simply will not open when double-clicked. The worst is that event notification pop-ups cannot be dismissed because the event status cannot be updated. Apart from the notifications they can all be worked around by right-clicking the calendar in TB and selecting Reset Calendar Cache. This works for a single operation only though and has to be repeated each time.

The common theme between our installations is that we have changed the SOGo UIDFieldName from username format (usera) to e-mail address format (usera@example.net). For our pre-existing systems we used the command "sogo-tool rename-user usera usera@example.net" on each account to rename the users.

Our Dovecot server is allowing authentication using either format of username and looking this up in Active Directory (provided by Samba 4) to check it. This appears to be the issue. To work properly you must log into the IMAP server (via Thunderbird) with the same format username as SOGo's UIDFieldName is expecting. When you do, calendars work fine.

In summary, the SOGo Connector does not seem to employ any "smart" logic or communicate with the SOGo backend on the server to help it calculate the Cal/CardDAV URLs. Instead it simply uses the username from the first IMAP account configured in Thunderbird and injects it into the URL. If you have your IMAP account in Thunderbird configured to use a simple username you get something like:

https://www.example.net/SOGo/dav/username/Calendar/personal/

Whereas, if you log into your IMAP account using an email address (username@example.net) you get:

https://www.example.net/SOGo/dav/username@example.net/Calendar/personal/

You need to check which of these SOGo is configured to expect in sogo.conf:

SOGoUserSources = (
{
type = ldap;
CNFieldName = displayName;
UIDFieldName = mail;
MailFieldNames = ( mail, otherMailbox );
baseDN = "CN=Users,dc=example,dc=net";
bindDN = "CN=auth-sogo,CN=Users,DC=example,DC=net";
bindFields = (sAMAccountName, mail);
bindPassword = "<strong_password>";
canAuthenticate = YES;
displayName = "Global Address Book";
hostname = ldap://127.0.0.1:389;
filter = "mail = '*'";
id = directory;
isAddressBook = YES;
}

The key part here is the UIDFieldName. If this is configured to expect a username, then log into IMAP with a username in Thunderbird. If it is configured to expect an e-mail address, log into IMAP with an e-mail address in Thunderbird.

(An alternative way to check is to log into SOGo with a web browser, right-click Properties on your personal calendar. On the Links to this Calendar tab you will see the CalDAV URL and be able to tell whether your system is configured for username or e-mail address.)

If your users aren't too worried about their local Thunderbird preferences, you can simply remove their old profile and re-configure it using the correct style of username for your system. Otherwise, the following procedure (a bit long winded) is working for me:

1. Start TB.
2. Go to Add-ons and disable both the SOGo Connector and SOGo Integrator extensions.
3. Restart TB.
4. Right-click your IMAP account in the tree-list on the left and select Settings.  Navigate to Server Settings below your account name and update the Username.
5. Move down to Outgoing Server (SMTP) at the bottom of the list and Edit your entry.  Update the Username field appropriately and click OK.
6. Close Account Settings by clicking OK.
7. Restart TB and log into your IMAP account when prompted (save password with Password Manager, if desired).
8. Click the Address Book toolbar button.  Delete all address books by right-clicking and selecting Delete.  Two will remain (local personal and collected addresses).
9. Open the Calendar and Unsubscribe from all calendars by right-clicking them.  (You may have to create a temporary new local calendar to allow the last one to be removed.)
10. Re-enable both the SOGO Connector and SOGO Integrator extensions.
11. Restart TB and log into your SOGo account when prompted (save password with Password Manager, if desired).

It is possible that after this procedure you will see two SOGo directories in Address Book after this has completed. (In our case called Global Address Book from the displayName = "Global Address Book" line in sogo.conf.) Work out which one is using the wrong URL by checking its Properties and delete it. (Your personal address book title will probably vanish at this stage but do not panic!) Restart TB and everything will work normally.

This has been causing me considerable pain on three customer sites. While strictly not a bug (simply a Thunderbird mis-configuration) I think the Connector should be smarter and ask the SOGo back-end for the URL of the resources. This way it could potentially also support changing the UIDFieldName style without the horrible local Thunderbird procedure above. Does this sound like a sensible enhancement (or at minimum documentation) request?

It appears that if you use a CalDAV client (like CalDAV-Sync on Android or the native iOS one) then you can log in using any supported (SOGo bindFields) format. The SOGo backend returns the correct URLs and everything works fine, like in webmail. Therefore, this specific behaviour is limited only to the Thunderbird Connector.

If you require any other details of our configuration, please do not hesitate to ask?

A much simpler way would be to reconfigure the backend to allow logging in with the local part only (ie, dovecot can be configured to append the domain part).

This way no changes would be needed on the client side.

But I guess this wouldn't work for sites that support multiple domains.

As we support multiple domain names for some of our customers we wanted to standardise our SOGo configurations. Therefore, we now use e-mail address as a UID on every system so that it is guaranteed unique.

Sadly this brings the Thunderbird client pain with it too as we need to change the IMAP username on each local machine. Hopefully it will future-proof our installations a little and reduce the pain one day? Either that or a Connector upgrade to check the Calendar URL with the SOGo backend will! ;-)

I wonder how hard it would be for SOGo to determine the correct FQDN part and append it if it is missing?

When I saw McMichaeli's entry from 2015-05-20 11:10 I took another look at UIDFieldName.

We had a earlier test system with SOGo 1.3 which works still fine.
There UIDFieldName was set accordingly to the bindfield: initials

In the new system it was set to employeenumber, which matches IDFieldName.
Then I checked the docs again: "The field that returns the login name of a user."

Both - initals and employeenumber - are unique here.

Where you can have multiple bindFields, can one have multiple UIDFieldName(s)? I think not.

So I you have multiple bindFields, the bindfield used in Thunderbird has to be set in UIDFieldName. Is this right?

After I changed UIDFieldName to initials, which matches the value of the username read from Thunderbird's first mail account, the error is gone.

So it seems to be:

• user name from Thunderbird has to be in bindFields
• user name from Thunderbird has to be UIDFieldName

This bug is 1 year old - and still new …