Autocomplete behaviour change between 9.0 and 10.1

[andrey.ivanov]

I have re-uploaded the file zimbrastore-patched-10.1.8.jar: https://filesender.renater.fr/?s=downlo ... a1ce418af7

sha256sum is af1fb1ce23f744b9e90b55b28b225e75e90ec6e2dadc80203bfa76a54013bb12

This file (/opt/zimbra/lib/jars/zimbrastore.jar) was not modified by the latest 10.1.9 update.

[adrian.gibanel.btactic]

Yes, we had a huge problem with autocomplete after migration from 9.0 to 10.1.8 last week. We use external LDAP as GAL and we hide all the internal accounts of Zimbra LDAP ("Internal GAL") using zimbraHideInGal=TRUE. The problem is that there are some addresses in internal accounts that coincide with addresses in external LDAP GAL. So after the upgrade our users could see in autocompletion only the addresses from an external LDAP that were not hosted on Zimbra.

(...)

Here is the (very simplistic) patch :

Code: Select all

--- a/zm-mailbox/store/src/java/com/zimbra/cs/mailbox/ContactAutoComplete.java  2025-06-09 11:26:45.198623170 +0200
+++ b/zm-mailbox/store/src/java/com/zimbra/cs/mailbox/ContactAutoComplete.java  2025-06-06 00:29:26.534628570 +0200
@@ -776,7 +776,7 @@
             // when account is null, its external contact.Below alias logic is not applicable.
             if (null != account) {
                 // check if account needs to be hidden in autocomplete
-                if (ContactConstants.A_email.equalsIgnoreCase(emailKey) && account.isHideInGal()) {
+                if (ContactConstants.A_email.equalsIgnoreCase(emailKey) && false) {
                     ZimbraLog.gal.debug("Skipping account %s from autocomplete", getFieldAsString(attrs, emailKey));
                     continue;
                 }
@@ -969,4 +969,4 @@
             queryFolders(str, queryRanking, mountpoints, limit, result);
         }
     }
-}
\ No newline at end of file
+}

So, the issue you are describing would have been introduced in ZCS-15617: Implementation & testing of Hide alias in GAL commit.

Please notice that the fix proposed here is a workaround and not a proper fix.

In other words, if I have understood the code properly, if you apply this suggested patch then internal-only contacts which were supposed to be hidden from the GAL would appear again if you try to autocomplete them. So it's as if the zimbraHideInGal attribute for an account is simply ignored.

So... if your server only has one domain with external GAL you might be fine, otherwise if you have additional internal domains be aware of the consequences I have described above.

After a quick glance it would seem to me that the right place where to fix this would be populateEligibleEmails function but I'm not quite sure.

[andrey.ivanov]

Yes, of course it is a fast and simple workaround and it is clearly not a definitive solution. For our configuration (internal GAL + external GAL + local user contacts) it fixes everything - meaning it works like in 9.0. The internal accounts and distribution lists with zimbraHideInGal=TRUE are still hidden in address book and are not shown in autocompletion (probably there is another place in the source code where these are not selected as candidates since zimbraHideInGal=TRUE), while ALL accounts from external LDAP GAL are shown and appear in autocompletion. But indeed, your mileage may vary depending on the infastructure configuration.

[IamtheStefan]

We've got the same expierence after the upgrade. Annoying.
Yes the address should be hidden when I never had contact.
But as soon as the address is part of my 'Emailed contacts' it should be found for me despite the hidden status.

[oetiker]

Hi

Sadly the ZBUG-4975 was not fixed in the 10.1.10 .. so no help for
the paying customers ... we have to wait for the 10.1.11 for the fix.

I did escalate the bug two times ... but did not get anymore information

[andrey.ivanov]

Hi

Sadly the ZBUG-4975 was not fixed in the 10.1.10 .. so no help for
the paying customers ... we have to wait for the 10.1.11 for the fix.

I did escalate the bug two times ... but did not get anymore information

I've checked the new zimbrastore.jar (extracted from 10.1.10 zimbra-common-core-jar-10.1.10.1751349175-1.r8.x86_64.rpm). It contains the same file ContactAutoComplete.class as in version 10.1.8. So for our production i will reuse the same method of "fixing" by replacing this .class file in the new .jar.

[oetiker]

Bug Report: ZBUG-4975

Status: Open since 30.6.2025

Issue Summary

I have escalated this bug twice, and Zimbra support claimed the bug has a very high priority. However, despite these assurances, it remains unfixed in version 10.1.11, and there is absolutely no meaningful information about any progress or resolution timeline in the Bug Lookup web portal from Zimbra support.

The only response provided is: "please wait."

Current Bug Status

• Bug ID: ZBUG-4975
• Status: Open
• Version Fixed: NA
• Last Updated: Tue, 05 Aug 2025 10:04:59 GMT
  (unclear what Zimbra actually updated in this bug)

This situation without information and without a roadmap makes it extremely difficult for me as a Zimbra service provider to manage client expectations and plan accordingly.

[BradC]

This situation without information and without a roadmap makes it extremely difficult for me as a Zimbra service provider to manage client expectations and plan accordingly.

Looking at the mailbox commits, about 50% of them seem to be licensing related. Perhaps re-submit the bug as a license issue and see if it gets fixed.

[oetiker]

Still no official fix for ZBUG-4936.

It is difficult to understand why Synacor strategically withholds information on bugs.
This makes it impossible for professional hosting partners to inform their customers and find solutions.
We are left with a non-functioning feature and no clear timeline for a fix, with the only real alternative being to use the open-source version. Their actions seem to actively promote the use of the open-source version, as it's clearly bringing more advantages in terms of bug fixes and responsiveness.

But it is completely incomprehensible to me how this business model is supposed to work when the license revenues start to fall away.

[BradC]

It is difficult to understand why Synacor strategically withholds information on bugs.

I don't think it's strategic as such. More likely Hanlon's razor applies.