Zimbra Releases/8.6.0/P2/Changelog: Difference between revisions
(Created page with "__FORCETOC__ <ol class="breadcrumb"> <li>Zimbra Wiki</li> <li>Zimbra Releases</li> <li>Zimbra Collaboration 8.6.0</li> <li>...") |
(No difference)
|
Latest revision as of 11:40, 5 July 2015
Zimbra Collaboration 8.6.0 GA Release Patch 2 Changelog
Bug 91009 | Getting membership information for all groups is slow. |
Change 539281 by gren.elliot@gelliot_coco on 2015/03/11 10:48:10 bug: 91009 Custom Dynamic Group improvements. Use LDAP Compare to determine whether an account is a member of a custom dynamic group instead of using an inverse cache of members to groups. Now include custom dynamic groups with other groups in account caches of group members (instead of referring to the now non-existent inverse cache) Avoid creating DynamicGroup objects (which can be expensive) when don't need to. https://reviewboard.eng.zimbra.com/r/4305/ https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/DynamicGroup.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/SearchDirectoryOptions.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapHelper.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#15 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/ZLdapHelper.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/entry/LdapDynamicGroup.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/LdapOp.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/LdapUsage.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/SearchLdapOptions.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/ZLdapContext.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapContext.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapOperation.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCustomDynamicGroupCache.java#2 edit | |
Change 539710 by gren.elliot@gelliot_coco on 2015/03/17 04:53:21 bug: 91009 getGroupMembership improvements for static DLs. getAllAddrsAsGroupMember - now doesn't return the name twice (Accounts and DistributionList) Replaced LdapDynamicGroup.Searcher with more generic BySearchResultEntrySearcher, used for new static DL searches as well. Reuse ZLDapContexts more. May help with performance a bit but certainly makes logging less chatty. For static DLs, having run makeDelegateAdminAndData.sh from Bug 97743 with "-d 2000" updating GroupMembership for the kuduadmin user took about 1/10th the time (45ms instead of 471ms) Renamed TestCustomDynamicGroupCache TestGroups as original name no longer makes sense. https://reviewboard.eng.zimbra.com/r/4367/ https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/Account.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/DistributionList.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/Provisioning.java#8 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/BySearchResultEntrySearcher.java#1 add ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#17 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/entry/LdapDynamicGroup.java#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCustomDynamicGroupCache.java#3 move/delete ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/qa/unittest/TestGroups.java#1 move/add | |
Change 539715 by gren.elliot@gelliot_coco on 2015/03/17 05:08:28 bug: 91009 Custom Dynamic Group improvements. Use LDAP Compare to determine whether an account is a member of a custom dynamic group instead of using an inverse cache of members to groups. Now include custom dynamic groups with other groups in account caches of group members (instead of referring to the now non-existent inverse cache) Avoid creating DynamicGroup objects (which can be expensive) when don't need to. JUDASPRIEST --> main https://reviewboard.eng.zimbra.com/r/4305/ https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/DynamicGroup.java#13 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/SearchDirectoryOptions.java#12 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapHelper.java#18 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#690 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/ZLdapHelper.java#15 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/entry/LdapDynamicGroup.java#10 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/LdapOp.java#7 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/LdapUsage.java#24 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/SearchLdapOptions.java#17 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/ZLdapContext.java#26 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapContext.java#46 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapOperation.java#13 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCustomDynamicGroupCache.java#5 integrate | |
Change 539718 by gren.elliot@gelliot_coco on 2015/03/17 05:23:31 bug: 91009 getGroupMembership improvements for static DLs. getAllAddrsAsGroupMember - now doesn't return the name twice (Accounts and DistributionList) Replaced LdapDynamicGroup.Searcher with more generic BySearchResultEntrySearcher, used for new static DL searches as well. Reuse ZLDapContexts more. May help with performance a bit but certainly makes logging less chatty. For static DLs, having run makeDelegateAdminAndData.sh from Bug 97743 with "-d 2000" updating GroupMembership for the kuduadmin user took about 1/10th the time (45ms instead of 471ms) Renamed TestCustomDynamicGroupCache TestGroups as original name no longer makes sense. https://reviewboard.eng.zimbra.com/r/4367/ JUDASPRIEST ---> main https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/Account.java#93 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/DistributionList.java#45 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/Provisioning.java#595 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/BySearchResultEntrySearcher.java#1 branch ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#691 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/entry/LdapDynamicGroup.java#11 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCustomDynamicGroupCache.java#6 move/delete ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/qa/unittest/TestGroups.java#1 move/add | |
Change 540138 by gren.elliot@gelliot_coco on 2015/03/23 07:28:55 bug: 91009 getGroupMembership improvements for static DLs. Off by 1 error in chunking. https://reviewboard.eng.zimbra.com/r/4452/ https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/DistributionList.java#3 edit | |
Change 540140 by gren.elliot@gelliot_coco on 2015/03/23 07:30:59 bug: 91009 getGroupMembership improvements for static DLs. Off by 1 error in chunking. https://reviewboard.eng.zimbra.com/r/4452/ JUDASPRIEST ---> main https://bugzilla.zimbra.com/show_bug.cgi?id=91009 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/DistributionList.java#46 integrate | |
Bug 91793 | Performance: slow CountObjectRequest, the response time is linear to the # of domains the server has. |
Change 540467 by gren.elliot@gelliot_coco on 2015/03/25 11:50:53 bug: 91793 CountObjects slow for Domain Admin. If have more than 100 domains, use 3 threads to do the counting concurrently. getAllDomains now caches the domains as long as the cache is big enough i.e. Localconfig setting ldap_cache_domain_maxsize is larger than the number of domains (This is what is recommended at http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 - at least if the number of domains is less than 30000). This speeds up later CountObjects calls - which is useful for Admin Console which does 5 CountObjectsRequests at startup. Use JAXB in the handler. Fixed up the JAXB to fit with actual handler behavior - can specify multiple domains. https://reviewboard.eng.zimbra.com/r/4457/ https://bugzilla.zimbra.com/show_bug.cgi?id=91793 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraCommon/src/java/com/zimbra/common/localconfig/DebugConfig.java#6 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#18 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/ZLdapFilterFactory.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapFilterFactory.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/service/admin/CountObjects.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCountObjects.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraSoap/src/java/com/zimbra/soap/admin/message/CountObjectsRequest.java#2 edit | |
Change 540479 by gren.elliot@gelliot_coco on 2015/03/25 12:29:58 bug: 91793 CountObjects slow for Domain Admin. If have more than 100 domains, use 3 threads to do the counting concurrently. getAllDomains now caches the domains as long as the cache is big enough i.e. Localconfig setting ldap_cache_domain_maxsize is larger than the number of domains (This is what is recommended at http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 - at least if the number of domains is less than 30000). This speeds up later CountObjects calls - which is useful for Admin Console which does 5 CountObjectsRequests at startup. Use JAXB in the handler. Fixed up the JAXB to fit with actual handler behavior - can specify multiple domains. https://reviewboard.eng.zimbra.com/r/4457/ JUDASPRIEST ---> main https://bugzilla.zimbra.com/show_bug.cgi?id=91793 Affected files ... ... //depot/zimbra/main/ZimbraCommon/ZimbraStoreCommon/src/main/java/com/zimbra/common/localconfig/DebugConfig.java#6 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#692 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/ZLdapFilterFactory.java#47 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/ldap/unboundid/UBIDLdapFilterFactory.java#47 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/service/admin/CountObjects.java#9 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/qa/unittest/TestCountObjects.java#6 integrate ... //depot/zimbra/main/ZimbraSoap/src/java/com/zimbra/soap/admin/message/CountObjectsRequest.java#10 integrate | |
Change 542437 by gren.elliot@gelliot_coco on 2015/04/17 15:57:00 bug: 91793 CountObjects slow for Domain Admin. Previous fix had check the wrong way round on whether to populate the Domain cache or not. Think I introduced the problem tidying up code after testing :( With check flipped, get this difference in elapsed times for logging in as a DomainAdmin on a system with 4000 domains / 52013 accounts - should have listened to Amit when he questioned how much better things were for the previous changes. Content of diff files created using: # grep -e Consider -e elapsed= /opt/zimbra/log/mailbox.log |sed -e 's/^.* search - //' -e 's/^.* soap - //' # diff -y -W 120 CountObjects-pan.4000domains-DomainAdminLogin-ldap_cache_domain_maxsi ze500 CountObjects-pan.4000domains-DomainAdminLogin-ldap_cache_domain_maxsi ze10000 AuthRequest elapsed=49 | GetDomainInfoRequest elapsed=15 GetInfoRequest elapsed=64 | GetDomainInfoRequest elapsed=0 (batch) GetVersionInfoRequest elapsed=1205 | GetDomainInfoRequest elapsed=0 > (batch) GetDomainInfoRequest elapsed=0 > GetInfoRequest elapsed=2 > AuthRequest elapsed=52 > GetInfoRequest elapsed=77 > (batch) GetVersionInfoRequest elapsed=1158 GetAdminExtensionZimletsRequest elapsed=13 GetAdminExtensionZimletsRequest elapsed=13 GetEffectiveRightsRequest elapsed=5815 | GetEffectiveRightsRequest elapsed=5634 GetAllEffectiveRightsRequest elapsed=24253 | GetAllEffectiveRightsRequest elapsed=20584 GetAdminConsoleUICompRequest elapsed=757 | GetAdminConsoleUICompRequest elapsed=763 GetAllServersRequest elapsed=1 GetAllServersRequest elapsed=1 GetAllServersRequest elapsed=1 < (batch) CountObjectsRequest elapsed=1 < GetAllEffectiveRightsRequest elapsed=14 < GetEffectiveRightsRequest elapsed=0 < localconfig ldap_cache_domain_maxsize=500 < number of do < GetAllServersRequest elapsed=2 GetAllServersRequest elapsed=2 GetAllServersRequest elapsed=0 | (batch) CountObjectsRequest elapsed=4 (batch) CountObjectsRequest elapsed=6367 | GetAllEffectiveRightsRequest elapsed=7 localconfig ldap_cache_domain_maxsize=500 < number of do | GetEffectiveRightsRequest elapsed=1 SearchDirectoryRequest elapsed=291 | GetAllServersRequest elapsed=1 SearchDirectoryRequest elapsed=502 | GetAllServersRequest elapsed=1 (batch) CountObjectsRequest elapsed=6345 | (batch) CountObjectsRequest elapsed=1367 localconfig ldap_cache_domain_maxsize=500 < number of do | SearchDirectoryRequest elapsed=377 (batch) CountObjectsRequest elapsed=5842 | SearchDirectoryRequest elapsed=406 localconfig ldap_cache_domain_maxsize=500 < number of do | (batch) CountObjectsRequest elapsed=1398 (batch) CountObjectsRequest elapsed=5967 | (batch) CountObjectsRequest elapsed=757 localconfig ldap_cache_domain_maxsize=500 < number of do | (batch) CountObjectsRequest elapsed=841 (batch) CountObjectsRequest elapsed=5913 | (batch) CountObjectsRequest elapsed=750 NoOpRequest elapsed=1 | SearchDirectoryRequest elapsed=129 > GetDomainInfoRequest elapsed=0 > GetDomainInfoRequest elapsed=0 > (batch) GetDomainInfoRequest elapsed=0 > GetInfoRequest elapsed=1 https://reviewboard.eng.zimbra.com/r/4705/ https://bugzilla.zimbra.com/show_bug.cgi?id=91793 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#19 edit | |
Change 542440 by gren.elliot@gelliot_coco on 2015/04/17 16:14:15 bug: 91793 CountObjects slow for Domain Admin. Previous fix had check the wrong way round on whether to populate the Domain cache or not. https://reviewboard.eng.zimbra.com/r/4705/ JUDASPRIEST ---> main https://bugzilla.zimbra.com/show_bug.cgi?id=91793 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#693 integrate | |
Change 542504 by psurana@psurana-mac on 2015/04/19 13:52:29 bug: 91793 CountObjects slow for Domain Admin. Previous fix had check the wrong way round on whether to populate the Domain cache or not. Think I introduced the problem tidying up code after testing :( With check flipped, get this difference in elapsed times for logging in as a DomainAdmin on a system with 4000 domains / 52013 accounts - should have listened to Amit when he questioned how much better things were for the previous changes. Content of diff files created using: # grep -e Consider -e elapsed= /opt/zimbra/log/mailbox.log |sed -e 's/^.* search - //' -e 's/^.* soap - //' # diff -y -W 120 CountObjects-pan.4000domains-DomainAdminLogin-ldap_cache_domain_maxsi ze500 CountObjects-pan.4000domains-DomainAdminLogin-ldap_cache_domain_maxsi ze10000 AuthRequest elapsed=49 | GetDomainInfoRequest elapsed=15 GetInfoRequest elapsed=64 | GetDomainInfoRequest elapsed=0 (batch) GetVersionInfoRequest elapsed=1205 | GetDomainInfoRequest elapsed=0 > (batch) GetDomainInfoRequest elapsed=0 > GetInfoRequest elapsed=2 > AuthRequest elapsed=52 > GetInfoRequest elapsed=77 > (batch) GetVersionInfoRequest elapsed=1158 GetAdminExtensionZimletsRequest elapsed=13 GetAdminExtensionZimletsRequest elapsed=13 GetEffectiveRightsRequest elapsed=5815 | GetEffectiveRightsRequest elapsed=5634 GetAllEffectiveRightsRequest elapsed=24253 | GetAllEffectiveRightsRequest elapsed=20584 GetAdminConsoleUICompRequest elapsed=757 | GetAdminConsoleUICompRequest elapsed=763 GetAllServersRequest elapsed=1 GetAllServersRequest elapsed=1 GetAllServersRequest elapsed=1 < (batch) CountObjectsRequest elapsed=1 < GetAllEffectiveRightsRequest elapsed=14 < GetEffectiveRightsRequest elapsed=0 < localconfig ldap_cache_domain_maxsize=500 < number of do < GetAllServersRequest elapsed=2 GetAllServersRequest elapsed=2 GetAllServersRequest elapsed=0 | (batch) CountObjectsRequest elapsed=4 (batch) CountObjectsRequest elapsed=6367 | GetAllEffectiveRightsRequest elapsed=7 localconfig ldap_cache_domain_maxsize=500 < number of do | GetEffectiveRightsRequest elapsed=1 SearchDirectoryRequest elapsed=291 | GetAllServersRequest elapsed=1 SearchDirectoryRequest elapsed=502 | GetAllServersRequest elapsed=1 (batch) CountObjectsRequest elapsed=6345 | (batch) CountObjectsRequest elapsed=1367 localconfig ldap_cache_domain_maxsize=500 < number of do | SearchDirectoryRequest elapsed=377 (batch) CountObjectsRequest elapsed=5842 | SearchDirectoryRequest elapsed=406 localconfig ldap_cache_domain_maxsize=500 < number of do | (batch) CountObjectsRequest elapsed=1398 (batch) CountObjectsRequest elapsed=5967 | (batch) CountObjectsRequest elapsed=757 localconfig ldap_cache_domain_maxsize=500 < number of do | (batch) CountObjectsRequest elapsed=841 (batch) CountObjectsRequest elapsed=5913 | (batch) CountObjectsRequest elapsed=750 NoOpRequest elapsed=1 | SearchDirectoryRequest elapsed=129 > GetDomainInfoRequest elapsed=0 > GetDomainInfoRequest elapsed=0 > (batch) GetDomainInfoRequest elapsed=0 > GetInfoRequest elapsed=1 https://reviewboard.eng.zimbra.com/r/4705/ https://bugzilla.zimbra.com/show_bug.cgi?id=91793 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/ldap/LdapProvisioning.java#6 integrate | |
Bug 91986 | Performance:multi-domain admin: search dir is slow |
Change 541132 by heswaran@heswaran on 2015/04/02 03:46:02 Bug: 91986 Searching in admin console requires minimum 3 characters. If the user enters less than 3 characters error message will be shown. https://bugzilla.zimbra.com/show_bug.cgi?id=91986 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/controller/ZaSearchBuilderController.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/model/ZaSearchOption.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchField.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchOptionDialog.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchOptionView.js#2 edit | |
Change 541133 by heswaran@heswaran on 2015/04/02 03:49:39 Bug: 91986 Merging from JUDASPRIEST to main. Searching in admin console requires minimum 3 characters. If the user enters less than 3 characters error message will be shown. https://bugzilla.zimbra.com/show_bug.cgi?id=91986 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/controller/ZaSearchBuilderController.js#61 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/model/ZaSearchOption.js#62 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchField.js#121 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchOptionDialog.js#12 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/search/view/ZaSearchOptionView.js#26 integrate | |
Bug 95730 | Both date and time should be shown in reading pane |
Change 534741 by vbellows@vbellows-JP on 2015/01/21 09:57:27 Bug: 95730 - Both date and time should be shown in reading pane Reverting the display to show full date-time. Also, after a discussion with Josh, I'm making the messages in the conversation view display date-time. https://bugzilla.zimbra.com/show_bug.cgi?id=95730 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#18 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmMailMsgView.js#10 edit | |
Change 534742 by vbellows@vbellows-main on 2015/01/21 09:59:59 Bug: 95730 - Both date and time should be shown in reading pane Reverting the display to show full date-time. Also, after a discussion with Josh, I'm making the messages in the conversation view display date-time. Merging //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail /view/... to //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/. .. https://bugzilla.zimbra.com/show_bug.cgi?id=95730 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#323 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmMailMsgView.js#693 integrate | |
Bug 96166 | Imap delete leaves orphan item on device when dumpster is enabled. |
Change 527735 by dywang@dywang-mac-main-11 on 2014/11/03 21:46:41 bug: 96166 Items deleted by imap client still on device. This only happens for initial sync and is fixed in this change. It works for delta sync. http://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java-test/com/zimbra/cs/db/DbMailItemTest.java#17 edit ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/db/DbMailItem.java#300 edit ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CalendarSync.java#152 edit ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CollectionSync.java#186 edit | |
Change 527736 by dywang@dywang-mac-jp on 2014/11/03 21:49:56 Integrate from main to JP Change 527735 by dywang@dywang-mac-main-11 on 2014/11/03 21:46:41 bug: 96166 Items deleted by imap client still on device. This only happens for initial sync and is fixed in this change. It works for delta sync. http://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java-test/com/zimbra/cs/db/DbMailItemTest.java#2 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/db/DbMailItem.java#4 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CalendarSync.java#2 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CollectionSync.java#8 integrate | |
Change 528439 by dywang@dywang-mac-main-11 on 2014/11/11 14:13:15 bug: 96166 Delete imap expunged items for ActiveSync. Side effect is that the expunged items will be sent for delete to every subscribing folder as there is no way to tell which folder they belong to, so no way to rule them out for unrelated folders, but this is just for expunge, normal delete or move won't be affected. https://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CollectionSync.java#187 edit ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/Ping.java#78 edit ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/Sync.java#63 edit ... //depot/zimbra/main/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/SyncState.java#97 edit | |
Change 528442 by dywang@dywang-mac-jp on 2014/11/11 14:46:10 Integrate from main to JP Change 528439 by dywang@dywang-mac-main-11 on 2014/11/11 14:13:15 bug: 96166 Delete imap expunged items for ActiveSync. Side effect is that the expunged items will be sent for delete to every subscribing folder as there is no way to tell which folder they belong to, so no way to rule them out for unrelated folders, but this is just for expunge, normal delete or move won't be affected. https://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/CollectionSync.java#9 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/Ping.java#5 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/Sync.java#5 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraSync/src/java/com/zimbra/zimbrasync/commands/SyncState.java#8 integrate | |
Change 536396 by psurana@psurana-mac on 2015/02/07 00:47:23 bug:96166 Issue: hard deleted or imap expunged messages are not getting deleted from device when dumpster folder is enabled. Fix: update mod_metadata while moving message to dumpster. Note all items moved in this batch will get same mod_metadata. Fixed logic to get items from dumpster. https://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/db/DbMailItem.java#8 edit | |
Change 536397 by psurana@psurana-mac on 2015/02/07 00:59:23 bug:96166 Issue: hard deleted or imap expunged messages are not getting deleted from device when dumpster folder is enabled. Fix: update mod_metadata while moving message to dumpster. Note all items moved in this batch will get same mod_metadata. Fixed logic to get items from dumpster. https://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/db/DbMailItem.java#307 integrate | |
Change 541458 by psurana@psurana-mac on 2015/04/07 00:46:06 bug:96166 Issue: hard deleted or imap expunged messages are not getting deleted from device when dumpster folder is enabled. Fix: update mod_metadata while moving message to dumpster. Note all items moved in this batch will get same mod_metadata. Fixed logic to get items from dumpster. https://bugzilla.zimbra.com/show_bug.cgi?id=96166 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/db/DbMailItem.java#2 integrate | |
Bug 96408 | zmtrainsa fails to update SA's bayes_* DB; direct sa-learn is OK |
Change 528456 by quanah@qmain on 2014/11/11 17:24:14 bug: 96408 When using on-disk bayes, don't set the path, we use it correctly already https://bugzilla.zimbra.com/show_bug.cgi?id=96408 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/bin/zmtrainsa#51 edit | |
Change 537103 by quanah@qmain on 2015/02/13 15:14:55 bug: 96408 Fix zmtrainsa broken by invalid bug report https://bugzilla.zimbra.com/show_bug.cgi?id=96408 Affected files ... ... //depot/zimbra/main/ZimbraServer/src/bin/zmtrainsa#53 edit | |
Bug 96715 | duplicate overlapping sender name in message list of a conversation |
Change 532700 by zkogan@zk-JUDASPRIEST on 2014/12/23 17:42:27 Bug 96715 - duplicate overlapping sender name in message list of a conversation In the message list, in the contacts split view, and in the contact edit view: - Added onerror on avatar images to display the default one if the imageUrl is broken. Also in ZmEditContactView: - Removed duplicate call to setValue; - Don't prompt to save if the image wasn't updated to a valid one. Related bugs: https://bugzilla.zimbra.com/show_bug.cgi?id=96715 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/abook/view/ZmContactSplitView.js#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/abook/view/ZmEditContactView.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#13 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/templates/abook/Contacts.template#5 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/templates/mail/Message.template#7 edit ... //depot/zimbra/JUDASPRIEST/Zimlet/src/zimlet/com_zimbra_email/UnknownPersonSlide.js#3 edit | |
Bug 96733 | Draft count gets increase after clicking on Cancel from Reply/Fwd compose window. |
Change 531324 by eyarkon@eyarkon-JUDASPRIEST on 2014/12/08 00:36:16 Bug 96733 Draft count gets increase after clicking on Cancel from Reply/Fwd compose window This is a regression from bug 96706. The change to ZmHtmlEditor.prototype.clear, of not clearing the textarea if editor is not defined. Reverting bug 96706 and added a specific check for the case where we really don't want to clear the textarea. https://bugzilla.zimbra.com/show_bug.cgi?id=96733 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#11 edit | |
Bug 96808 | Google Chrome zoom level at 90% is not displaying emails |
Change 535336 by zkogan@zk-JUDASPRIEST on 2015/01/27 12:42:24 Bug 96808 - Google Chrome zoom level at 90% is not displaying emails Chrome seems to change the hardcoded pixel value. Depending on the zoom level, it fluctuates +/- 1. This then messes up the layout. Something along the lines: reported calculated width of #skin_td_tree_app_sash is x pixels, but the element still occupies x+1 pixels which causes an incorrect width calculation for the #skin_td_main. Decreasing the width of #skin_td_main by 3 works on all zoom levels. Only do this in Chrome (no problem in FF) and only on non-integer devicePixelRatio (e.g. skip 100% zoom on retina and non-retina displays where devicePixelRatio is 2 and 1). Sash's width is set in skins. https://bugzilla.zimbra.com/show_bug.cgi?id=96808 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtShell.js#3 edit | |
Change 535926 by zkogan@zk-main on 2015/02/02 12:35:57 Bug 96808 - Google Chrome zoom level at 90% is not displaying emails https://bugzilla.zimbra.com/show_bug.cgi?id=96808 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtShell.js#29 integrate | |
Bug 97000 | Replied/Fwd'ed message doesn't get open in reading pane. shows error "s.innerText is undefined" |
Change 532411 by cdamon@cdamon_judaspriest on 2014/12/19 14:49:17 Bug: 97000 - Replied/Fwd'ed message doesn't get open in reading pane. shows error "s.innerText is undefined" Firefox doesn't support innerText, so replace our uses of it with textContent or innerHTML. https://bugzilla.zimbra.com/show_bug.cgi?id=97000 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/util/AjxStringUtil.js#7 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/dialog/ZmSharePropsDialog.js#4 edit | |
Bug 97067 | ZWC: Slow search results |
Change 532961 by eyarkon@eyarkon-JUDASPRIEST on 2014/12/29 17:33:09 Bug 97067 ZWC: Slow search results Like I mentioned in the bug, this is a problem in the case of preview pane at the bottom (multi-column) and not on the right. Anyway, the methods that show as most time consuming on the Chrome timing, are the native DOM ones such as get clientWidth and so on. That's probably expected. But I believe the reason for the issue is not those methods, but rather that they are called too many times (Chrome shows the total CPU of all calls to each method). I was able to see a couple places where code that ends up calling DwtListView.prototype._resetColWidth (which is one of the issues in the Chrome timing, getting clientWidth from DOM), is called in a loop. _fitToContainer is called many times from a path that includes ZmSkin._reflowApp. ZmSkin._reflowApp is called multiple times due to a couple of loops in ZmAppViewMgr where it's not really required to be called at least until the last iteration of the loop (loops over components). So my fix is to tackle this issue. Interestingly ZmAppViewMgr.prototype.showSkinElement already has a param, that might not be used (could't find a use but I might miss something), noReflow which is exactly for that - to pass to ZmSkin.show not to reflow all the components. So I used that. https://bugzilla.zimbra.com/show_bug.cgi?id=97067 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/core/ZmAppViewMgr.js#4 edit | |
Change 533156 by eyarkon@eyarkon-JUDASPRIEST on 2015/01/02 15:27:16 Bug 97067 ZWC: Slow search results Looked at this again, since it was causing regressions (bug 97121 and bug 97122). I realized my logic was failing in case the last element does not have displayComponent called on it (if it is invisible and so on). Instead of this, I always call displayComponent with noReflow param "true", and now I call fitAll at the end. At first I tried to reuse the _fitToContainer() calls that were already there - but that didn't work, fitAll has to be called for all elements apparently. (and no, it's not due to fitAll having the line this._shell.relayout(); in addition to fitToContainer of all the elements - I tried to just add that line to after the loops but that didn't help). That works and got rid of the regressions. Here's the original check-in comment since this fix overrides all that in the annotations: Like I mentioned in the bug, this is a problem in the case of preview pane at the bottom (multi-column) and not on the right. Anyway, the methods that show as most time consuming on the Chrome timing, are the native DOM ones such as get clientWidth and so on. That's probably expected. But I believe the reason for the issue is not those methods, but rather that they are called too many times (Chrome shows the total CPU of all calls to each method). I was able to see a couple places where code that ends up calling DwtListView.prototype._resetColWidth (which is one of the issues in the Chrome timing, getting clientWidth from DOM), is called in a loop. _fitToContainer is called many times from a path that includes ZmSkin._reflowApp. ZmSkin._reflowApp is called multiple times due to a couple of loops in ZmAppViewMgr where it's not really required to be called at least until the last iteration of the loop (loops over components). So my fix is to tackle this issue. Interestingly ZmAppViewMgr.prototype.showSkinElement already has a param, that might not be used (could't find a use but I might miss something), noReflow which is exactly for that - to pass to ZmSkin.show not to reflow all the components. So I used that. https://bugzilla.zimbra.com/show_bug.cgi?id=97067 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/core/ZmAppViewMgr.js#5 edit | |
Bug 97128 | "New Folder" menu text remains invisible in new window |
Change 534757 by vbellows@vbellows-JP on 2015/01/21 11:11:41 Bug: 97128 - "New Folder" menu text remains invisible in new window ZmFolderChooser in a new window was using ZmApp.MAIL etc to set up organizer info for the 'New Folder' display. However, the apps (mail, calendar, etc) were being loaded after ZmFolderChooser, so ZmApp.MAIL (and others) were undefined. I moved the ZmFolderChooser to load after the Apps in the new window package. https://bugzilla.zimbra.com/show_bug.cgi?id=97128 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/package/NewWindow_2.js#2 edit | |
Change 534758 by vbellows@vbellows-main on 2015/01/21 11:13:13 Bug: 97128 - "New Folder" menu text remains invisible in new window ZmFolderChooser in a new window was using ZmApp.MAIL etc to set up organizer info for the 'New Folder' display. However, the apps (mail, calendar, etc) were being loaded after ZmFolderChooser, so ZmApp.MAIL (and others) were undefined. I moved the ZmFolderChooser to load after the Apps in the new window package. Merging //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/pack age/NewWindow_2.js to //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/package/New Window_2.js https://bugzilla.zimbra.com/show_bug.cgi?id=97128 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/package/NewWindow_2.js#67 integrate | |
Bug 97207 | error sending mail (duplicates send) |
Change 541495 by psurana@psurana-mac on 2015/04/07 04:07:18 bug: 97207 error sending mail (duplicates send) Added possible null check. Catched Exceptions. Added warn statement for further debugging. https://bugzilla.zimbra.com/show_bug.cgi?id=97207 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraEws/src/java/com/zimbra/operation/EmailOperation.java#10 edit | |
Change 541496 by psurana@psurana-mac on 2015/04/07 04:09:15 bug: 97207 error sending mail (duplicates send) Added possible null check. Catched Exceptions. Added warn statement for further debugging. https://bugzilla.zimbra.com/show_bug.cgi?id=97207 Affected files ... ... //depot/zimbra/main/ZimbraEws/src/java/com/zimbra/operation/EmailOperation.java#41 integrate | |
Bug 97283 | Cannot select subject text in conv view |
Change 534552 by eyarkon@eyarkon-JUDASPRIEST on 2015/01/19 19:05:42 Bug 97283 Cannot select subject text in conv view lots of history here. Bug 72339, bug 76096. Another related bug, bug 76098 added object processing on the subject line, which also made the subject selectable somehow. However in bug 85721 I removed the Zimlet object processing since it didn't make sense (e.g. to have a link inside the subject), and cause the bug. That might have been where this regression happened, but not sure, other things related to mouse events were changed recently, for accessibility. At any rate, was tough to figure this out, mostly to find out the key event is onSelectStart, (though onMouseMove, onKeyDown and onKeyUp play a role too). This is the solution in ZmConvView2Header constructor: this.setEventPropagation(true, [DwtEvent.ONMOUSEDOWN, DwtEvent.ONSELECTSTART, DwtEvent.ONMOUSEUP, DwtEvent.ONMOUSEMOVE]); And this is an explanation of what's wrong/confusing with the DwtComposite.prototype._mouseDownListener method: Bug 23462 changed it to stop propagation, so supposedly it should NOT allow selection. But it's more complicated than this, since ev._dontCallPreventDefault is more important, and is not set here, so a listener could set it to TRUE thus making it allow selection, despite _stopPropagation being set to true here. (not sure what the meaning is). Note for example the inconsistency with the DwtComposite.prototype._contextMenuListener method. Anyway the above setEventPropagation causes _dontCallPreventDefault to be set to true, not being overriden here, thus selection works. Additional fix (the one in zm.css) is due to the fact that once selection works, it was working a bit weird when leaving the edge of the subject text, since that span was positioned absolutely. So consulted with Josh and we position the span relative and it works fine now. Also added a comment to DwtControl.__mouseEvent, as I'm not sure if something might be wrong there in the setting of _stopPropagation and _dontCallPreventDefault. https://bugzilla.zimbra.com/show_bug.cgi?id=97283 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/css/zm.css#12 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtComposite.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtControl.js#10 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#17 edit | |
Bug 97403 | Expanded conversation collapses on clicking to + icon |
Change 535090 by eyarkon@eyarkon-JUDASPRIEST on 2015/01/23 15:23:41 Bug 97403 Expanded conversation collapses on clicking to + icon 2 bugs here actually: 1. This is detectable even before clicking the header - the icon was set to "collapse all" instead of "expand all" - it should have been "expand all" since not all the messages are expanded when the conv is displayed. (collapse-all is a bit meaningless but that's a different discussion). The bug here was due to _forceCollapse being set to undefined instead of false. This caused _expanded to be set to undefined in ZmMailMsgCapsuleView.prototype.set. In turn, this caused ZmConvView2.prototype.getExpanded to return an empty array when expanded param is false since if (msgView.isExpanded() == expanded) { does not execute (it's not true that undefined == false, unfortunately). I fixed it more or less at the source, ZmMailMsgCapsuleView constructor to make sure it's Boolean. I could have fixed it in the callers to this but there were 2 different ones and more could have been added so this is the place I thought it could be fixed best. 2. The bug reported here (more or less), of the thing expanding and collapsing: At first I thought it's related to accessibility, in particular bug 32283 and the change in DwtControl.__mouseEvent, where the onclick event that's supposedly only called by screen readers. But well no idea why but the onclick is called for this header. Anyway it's all that mess of we are unable to decide if we do stuff in mouseUp or in onClick type events. This sequence causing the issue was this more or less: 1. DwtControl.__mouseUpHdlr calls 2. DwtControl.__processMouseUpEvent 3. which sets up DwtControl.__timedClick timeout 4. DwtControl.__clickHdlr is called next (before the timeout is executed), which calls DwtControl.__mouseEvent which this does that mouseDown followed by mouseUp due to the code that Dan added. (again, not sure if it's causing the issue or not related). 5. this is good so far, the listener expands all the messages. 6. this is where things go wrong - DwtControl.__timedClick is called (btw the reason for this delay is to try to detect a double click), and it calls DwtControl.__mouseEvent with ONMOUSEUP event, which triggers the listeners again causing them to COLLAPSE all the messages. The problem, at least the way I finally saw it is not with step 6, but with step 4. __clickHandler should check if there's no "_clickPending" on the obj - if there is, it should return. At least that's what I did and it solved the issue. I tested double-click and thankfully it still seems to work. NOTE that this only happened when using the _dblClickIsolation option, introduced in bug 15874, to prevent the click from executing before a possible detection it was first click of a double click. Currently it's only used from the conv header. https://bugzilla.zimbra.com/show_bug.cgi?id=97403 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtControl.js#11 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#19 edit | |
Bug 97462 | Expanding DL in the 'To:' field does not remove the group itself |
Change 536186 by eyarkon@eyarkon-JUDASPRIEST on 2015/02/04 16:10:50 Bug 97462 Expanding DL in the 'To:' field does not remove the group itself Regression from bug 94016. There the solution was an overkill that removed functionality not just from the bug's use-case (reading pane), but from the use case here (compose). My solution is to revert the change to bug 94016, and add a specific check in ZmDLAutocompleteListView.prototype.reset that the addrInput (in the case of bug 94016 it's not really an address input) has removeBubble. I did the check for functionality (removeBubble) rather than class (say, isZmAddrInputField) since it's better practice. This way if we ever have another use-case that has a bubble (but is not ZmAddrInputField) it would still work. https://bugzilla.zimbra.com/show_bug.cgi?id=97462 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/ZmAddressInputField.js#8 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/ZmDLAutocompleteListView.js#3 edit | |
Bug 97469 | crossmailbox / mailbox search in admin console limits still broken |
Change 538886 by heswaran@heswaran on 2015/03/06 02:52:46 Bug:97469 âMaximum number of messagesâ input field limit is currently set as 500. It is removed so that user can enter larger value. https://bugzilla.zimbra.com/show_bug.cgi?id=97469 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraXMbxSearch/src/admin_extension/com_zimbra_xmbxsearch/com_zimbra_xmbxsearch.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraXMbxSearch/src/admin_extension/com_zimbra_xmbxsearch/com_zimbra_xmbxsearch.properties#2 edit | |
Change 538889 by heswaran@heswaran on 2015/03/06 03:00:45 Bug:97469 Integrated from JUDASPRIEST to main 'Maximum number of messages' input field limit is currently set as 500. It is removed so that user can enter larger value. https://bugzilla.zimbra.com/show_bug.cgi?id=97469 Affected files ... ... //depot/zimbra/main/ZimbraXMbxSearch/src/admin_extension/com_zimbra_xmbxsearch/com_zimbra_xmbxsearch.js#32 integrate ... //depot/zimbra/main/ZimbraXMbxSearch/src/admin_extension/com_zimbra_xmbxsearch/com_zimbra_xmbxsearch.properties#23 integrate | |
Change 542046 by quanah@qint on 2015/04/14 13:33:41 bug: 97469 Fix type for xmbx from file to zimlet https://bugzilla.zimbra.com/show_bug.cgi?id=97469 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraBuild/rpmconf/Patch/conf/zmpatch.xml#10 edit | |
Bug 97563 | Spell Check doesn't work in Firefox and OS X Yosemite |
Change 537498 by eyarkon@eyarkon-JUDASPRIEST on 2015/02/19 15:06:10 Bug 97563 Spell Check doesn't work in Firefox and OS X Yosemite This is a regression from bug 85153 and/or bug 81955. Those 2 dealt with adding and/or removing the tinyMCE context menu. Seems Dan kept going back and forth. Specifically the problem on FF was ev.srcElement was not set. Perhaps that's a problem but that code path is deep into tinyMCE. However I noticed there's ev.target, and in case of Chrome it's the same as ev.srcElement, at least while right clicking on a word. What I chose is to try srcElement and default to target if srcElement is null/undefined. Another option would have been to just use the "target" but I'm not certain that would not cause some regressions in different use-cases and/or browsers. https://bugzilla.zimbra.com/show_bug.cgi?id=97563 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#19 edit | |
Bug 97743 | membership in many domain admin DLs causes excessive LDAP searching and slow domain admin login and management access |
Change 537732 by gren.elliot@gelliot_coco on 2015/02/23 12:25:34 bug: 97743 Reserve attributes for short term Grantee and AllEffectiveRights caches on main See also https://reviewboard.eng.zimbra.com/r/4146/ for preliminary work on caches this will affect (for JP) https://reviewboard.eng.zimbra.com/r/4164/ https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/main/ZimbraCommon/ZimbraStoreCommon/src/main/java/com/zimbra/common/account/ZAttrProvisioning.java#41 edit ... //depot/zimbra/main/ZimbraServer/conf/attrs/zimbra-attrs.xml#1329 edit ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrAlwaysOnCluster.java#32 edit ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrConfig.java#689 edit ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrServer.java#666 edit | |
Change 537753 by gren.elliot@gelliot_coco on 2015/02/23 13:00:45 bug: 97743 Reserve attributes for short term Grantee and AllEffectiveRights caches https://reviewboard.eng.zimbra.com/r/4164/ main ---> JUDASPRIEST https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraCommon/src/java/com/zimbra/common/account/ZAttrProvisioning.java#27 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/conf/attrs/zimbra-attrs.xml#40 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrAlwaysOnCluster.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrConfig.java#24 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrServer.java#20 edit | |
Change 537987 by gren.elliot@gelliot_coco on 2015/02/24 14:07:01 bug: 97743 Admin Console slow for delegate admins. Add short term caches for AllEffectiveRights and Grantees - sizes and expiry configurable in LDAP. RightBearer - implements a short term, thread safe cache for Grantee and use this from various call sites. RightCommand - implements a short term, thread safe cache for AllEffectiveRights AdminAccessControl - new public List<NamedEntry> getAllowed(List<NamedEntry> entries, int maxEntries) Prevents un-necessary work processing entries that will be discarded ZimbraLog - added utility method elapsedTime which is useful for light weight code instrumentation to track both elapsed and clock time. https://reviewboard.eng.zimbra.com/r/4146/ https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraCommon/src/java/com/zimbra/common/util/ZimbraLog.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLAccessManager.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLUtil.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/CollectAllEffectiveRights.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ParticallyDenied.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/SearchGrants.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/service/admin/AdminAccessControl.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchAccounts.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchCalendarResources.java#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchDirectory.java#2 edit | |
Change 537990 by gren.elliot@gelliot_coco on 2015/02/24 14:37:16 bug: 97743 Admin Console slow for delegate admins. Add short term caches for AllEffectiveRights and Grantees - sizes and expiry configurable in LDAP. RightBearer - implements a short term, thread safe cache for Grantee and use this from various call sites. RightCommand - implements a short term, thread safe cache for AllEffectiveRights AdminAccessControl - new public List<NamedEntry> getAllowed(List<NamedEntry> entries, int maxEntries) Prevents un-necessary work processing entries that will be discarded ZimbraLog - added utility method elapsedTime which is useful for light weight code instrumentation to track both elapsed and clock time. https://reviewboard.eng.zimbra.com/r/4146/ JUDASPRIEST ---> main https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/main/ZimbraCommon/ZimbraStoreCommon/src/main/java/com/zimbra/common/util/ZimbraLog.java#3 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLAccessManager.java#64 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLUtil.java#17 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/CollectAllEffectiveRights.java#28 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ParticallyDenied.java#9 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#19 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#92 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/SearchGrants.java#27 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/service/admin/AdminAccessControl.java#41 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchAccounts.java#72 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchCalendarResources.java#41 integrate ... //depot/zimbra/main/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchDirectory.java#70 integrate | |
Change 541466 by psurana@psurana-mac on 2015/04/07 01:15:18 bug:97743 Integrated change list 537987 for bug# 97743 Added LC parameter for patch purpose. see bug 98186 Admin Console slow for delegate admins. Add short term caches for AllEffectiveRights and Grantees - sizes and expiry configurable in Local config. RightBearer - implements a short term, thread safe cache for Grantee and use this from various call sites. RightCommand - implements a short term, thread safe cache for AllEffectiveRights AdminAccessControl - new public List<NamedEntry> getAllowed(List<NamedEntry> entries, int maxEntries) Prevents un-necessary work processing entries that will be discarded ZimbraLog - added utility method elapsedTime which is useful for light weight code instrumentation to track both elapsed and clock time. LC Keys. short_term_all_effective_rights_cache_expiration (default: 50000) short_term_all_effective_rights_cache_size (default: 128) short_term_grantee_cache_expiration (default: 50000) short_term_grantee_cache_size (default: 128) https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraCommon/src/java/com/zimbra/common/localconfig/LC.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraCommon/src/java/com/zimbra/common/util/ZimbraLog.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLAccessManager.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ACLUtil.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/CollectAllEffectiveRights.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/ParticallyDenied.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/SearchGrants.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/service/admin/AdminAccessControl.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchAccounts.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchCalendarResources.java#2 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/service/admin/SearchDirectory.java#2 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#3 integrate ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#3 integrate | |
Change 541470 by psurana@psurana-mac on 2015/04/07 01:18:55 bug:97743 Back out revision 3 from //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/accoun t/accesscontrol/RightCommand.java Back out revision 3 from //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/accoun t/accesscontrol/RightBearer.java https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#4 edit | |
Change 541471 by psurana@psurana-mac on 2015/04/07 01:24:12 bug:97743 Changed code to use LC keys for 8_6_0 Patch. //depot/zimbra/users/cpd/JUDASPRIEST-851-SYNAQ/ZimbraServer/src/java/ com/zimbra/cs/account/accesscontrol/... to //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/ac count/accesscontrol/... https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightBearer.java#3 integrate ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/accesscontrol/RightCommand.java#3 integrate | |
Change 541621 by tpubliski@katbert on 2015/04/07 16:46:10 Bug: 97743 Revert change #541565. https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraCommon/src/java/com/zimbra/common/account/ZAttrProvisioning.java#3 edit ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/conf/attrs/zimbra-attrs.xml#3 edit ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrAlwaysOnCluster.java#3 edit ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrConfig.java#3 edit ... //depot/zimbra/JUDASPRIEST-860/ZimbraServer/src/java/com/zimbra/cs/account/ZAttrServer.java#3 edit | |
Bug 97838 | Emoticons not getting included while composing a message. |
Change 539851 by eyarkon@eyarkon-JUDASPRIEST on 2015/03/18 15:04:39 Bug 97838 Emoticons not getting included while composing a message My solution is to update the editor settings temporarily before adding the emoticon, and resetting it afterwards. I make sure to stash the original value and reset it to it, in case we change it in the future to "true" and this code would break it. https://bugzilla.zimbra.com/show_bug.cgi?id=97838 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/custom/plugins/zemoticons/plugin.js#2 edit | |
Bug 97956 | Firefox: first reply after login loses cursor focus |
Change 538099 by eyarkon@eyarkon-JUDASPRIEST on 2015/02/25 16:03:27 Bug 97956 Firefox: first reply after login loses cursor focus actual summary: first new message compose after login loses "To" focus. OK this is actually not solving the original issue reported on FF. I do see that issue. I did however see a similar issue to what Vince was seeing in FF in reply, with NEW messages with focus (that is on the "To" field getting lost as you start typing or clicking on the field and start typing). This is what I fix here. Again the use case is simple: 1. reload ZWC 2. click "new message" 3. start typing the "to" address. The cursor disappears and nothing is typed. This is a very complicated thing as usual, and the bug might or might not be a regression from such bugs as bug 32283 (related to accessibility). After digging for a while, and trying to understand the meaning of such ambiguously named vars as __dwtCtrlHasFocus and __focusObj, realized the problem was somehow that: this.__dwtCtrlHasFocus was true, but the focus was on an input field, in which case this.__dwtCtrlHasFocus should be false. Interestingly in DwtKeyboardMgr.prototype.__doGrabFocus we do not set __dwtCtrlHasFocus to false when setting __focusObj to some input field. (or rather a field with input element in it...confusing, again). So my simple fix is to set it to false at that point, which fixes the Chrome issue with new messages "to" field losing focus first time. The actual problem manifested itself in DwtKeyboardMgr.__syncFocus, in that "focus missmatch" case, this is one of the hardest lines to understand: if ((obj != kbMgr._kbFocusField) && kbMgr.__dwtCtrlHasFocus) { I eventually understood that: 1. _kbFocusField is that hidden textarea that's supposed to catch shortcuts when no input field is in focus. Wish it was named better. and 2. kbMgr.__dwtCtrlHasFocus should only be TRUE (as it was in the case of this bug) if no obj other than that hidden textarea (_kbFocusField) is getting focus. In the case of the bug __dwtCtrlHasFocus was true when it should have been false since the ZmAddrInputField input field in the "To" field was in focus. So there might be other reasons this is failing other than the one I fixed (like why is inputGotFocus not called, like it is in DwtInputField._focusHdlr - which is not what is used for the "To"/"CC" etc fields). But the one line I fixed, fixes this issue. https://bugzilla.zimbra.com/show_bug.cgi?id=97956 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/keyboard/DwtKeyboardMgr.js#11 edit | |
Change 540151 by vbellows@vbellows-JP on 2015/03/23 09:09:01 Bug: 97956 - Firefox: first reply after login loses cursor focus Two cases: 1. tinyMCE hasn't loaded yet. Setting the auto_focus attribute takes care of that. We were trying to focus via the initCallbacks, but that was too soon, so I've removed that code. After the initCallbacks are executed, some 40+ additional tinyMCE callbacks run, and its likely one of those mucks up the focus. Auto_focus is performed at the very end of the init (Editor.initContentBody) - indeed, it uses a setTimeout(focus, 100) - so nothing occurs after it to disrupt the focus. 2. Once tinyMCE has loaded, the first use was still not focusing correctly. I'm delaying focus via a setTimeout (same thing done in tinyMCE init); I assume something with its iFrame or html needs to stabilize before applying focus for the first time. Tested both cases fore FF, Chrome, and IE11. https://bugzilla.zimbra.com/show_bug.cgi?id=97956 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/controller/ZmComposeController.js#23 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#23 edit | |
Change 540152 by vbellows@vbellows-main on 2015/03/23 09:11:58 Bug: 97956 - Firefox: first reply after login loses cursor focus Two cases: 1. tinyMCE hasn't loaded yet. Setting the auto_focus attribute takes care of that. We were trying to focus via the initCallbacks, but that was too soon, so I've removed that code. After the initCallbacks are executed, some 40+ additional tinyMCE callbacks run, and its likely one of those mucks up the focus. Auto_focus is performed at the very end of the init (Editor.initContentBody) - indeed, it uses a setTimeout(focus, 100) - so nothing occurs after it to disrupt the focus. 2. Once tinyMCE has loaded, the first use was still not focusing correctly. I'm delaying focus via a setTimeout (same thing done in tinyMCE init); I assume something with its iFrame or html needs to stabilize before applying focus for the first time. Tested both cases fore FF, Chrome, and IE11. Merging //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/... to //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/... https://bugzilla.zimbra.com/show_bug.cgi?id=97956 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/controller/ZmComposeController.js#542 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#280 integrate | |
Bug 97960 | Delete button action loses message focus |
Change 538095 by eyarkon@eyarkon-JUDASPRIEST on 2015/02/25 15:53:03 Bug 97960 Delete button action loses message focus regression from bug 96140 (accessibility stuff). It undid what one of the changes in bug 16196 did, which was add a noFocus attribute to a toolbar to indicate it should not grab focus. Bug 96140, the change in ZmBaseController.prototype._initializeTabGroup - instead of marking the toolbar with noFocus, adds it as part of the tab group. Which probably makes sense for accessibility. However, my solution is not to revert that, for 2 reason, the obvious one being that reverting it would break accessibility stuff. The other reason is that I don't know why a button should grab focus when clicked on by the mouse. I don't see a legit use case of somebody clicking on a button in order to grab focus (since the button action would also be executed, so that's a weird price to pay in order to focus on a button so you can tab to the next one or something?). So my change is to never grab focus when mouse-clicking on a button. Focus should only be grabbed when mouse-clicking on an input element (meaning text input, textarea, radio) or a list. https://bugzilla.zimbra.com/show_bug.cgi?id=97960 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/ajax/dwt/widgets/DwtButton.js#7 edit | |
Bug 97994 | Tab into body in Compose is inefficient |
Change 538480 by eyarkon@eyarkon-JUDASPRIEST on 2015/03/02 15:20:24 Bug 97994 Tab into body in Compose is inefficient This is just the part about text mode tabbing not always working as far as tabbing to the textarea. To repro set the default compose view to text and compose a new message. Tab a few times and it does not reach the textarea. (note that once you switch modes to HTML and back to Text, things start to work). The problem was that we got into a situation where the tab group textarea member was some kind of zombie textarea object that is not in the DOM (despite having the same ID as the one in the DOM). It was not tabbing to it due to recent fix in bug 97329, (since the size of that phantom textarea is calculated as 0 since it's not in the DOM and we use offsetWidth/offsetHeight) but even if it did, it would not be a good thing since it was not the real current textarea. I don't know why that happened but I think it's pointless to try to figure out all the different cases here. What I did instead to solve this issue, was to remove some smart stuff we did to try to optimize the code, but I think it was both premature optimization and also causes us to revisit issues with this all the time. The solution is to not cache stuff, and always set the correct members for text or HTML editor, even if we didn't change mode. Also make sure to always call _setupTabGroup - it was not always called. (maybe since ZmHtmlEditor.prototype.onInit was not always called, but really this fix makes it less fragile). Now it's called from ZmHtmlEditor.prototype.getTabGroupMember, which seems to be the safest thing to do. BTW the problem might be similar to what Conrad saw and commented about in the header of ZmHtmlEditor.prototype._setupTabGroup - I did not change what's done in HTML mode where it still caches part of the tab group since it seems to work indeed. But in general I doubt we should to cache anything in this. It's not something that's heavy to recreate or is called in a long loop. https://bugzilla.zimbra.com/show_bug.cgi?id=97994 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#20 edit | |
Change 538705 by eyarkon@eyarkon-JUDASPRIEST on 2015/03/04 14:47:04 Bug 97994 Tab into body in Compose is inefficient Update my previous fix. It had a problem the first time HTML mode compose is created, as I removed the call to this._setupTabGroup, which was not good. (the html editor buttons would not have been added at that time). Fixed that. The changes in _setupTabGroup is more simplification and less caching, that I did before I realize my mistake was the removal of _setupTabGroup, but I think it's better to simplify it anyway, to avoid all kinds of hard to reproduce/debug issues. My original comment from previous fix is this, for documentation: This is just the part about text mode tabbing not always working as far as tabbing to the textarea. To repro set the default compose view to text and compose a new message. Tab a few times and it does not reach the textarea. (note that once you switch modes to HTML and back to Text, things start to work). The problem was that we got into a situation where the tab group textarea member was some kind of zombie textarea object that is not in the DOM (despite having the same ID as the one in the DOM). It was not tabbing to it due to recent fix in bug 97329, (since the size of that phantom textarea is calculated as 0 since it's not in the DOM and we use offsetWidth/offsetHeight) but even if it did, it would not be a good thing since it was not the real current textarea. I don't know why that happened but I think it's pointless to try to figure out all the different cases here. What I did instead to solve this issue (and I think I encountered some other issues too), was to remove some smart stuff we did to try to optimize the code, but I think it was both premature optimization and also causes us to revisit issues with this all the time. The solution is to not cache stuff, and always set the correct members for text or HTML editor, even if we didn't change mode. Also make sure to always call _setupTabGroup - it was not always called. (maybe since ZmHtmlEditor.prototype.onInit was not always called, but really this fix makes it less fragile). Now it's called from ZmHtmlEditor.prototype.getTabGroupMember, which seems to be the safest thing to do. https://bugzilla.zimbra.com/show_bug.cgi?id=97994 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/share/view/htmlEditor/ZmHtmlEditor.js#21 edit | |
Change 539668 by cdamon@cdamon_judaspriest on 2015/03/16 11:40:01 Bug: 97994 - Tab into body in Compose is inefficient Add a setting to the toolbar to ignore Tab key events. It still handles left and right arrow to move focus among its buttons. - add patch from a previous TinyMCE fix (bug 97552) - add patch for this fix https://bugzilla.zimbra.com/show_bug.cgi?id=97994 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/patches/08-clipboard-paste.diff#1 add ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/patches/09-toolbar-tabbing.diff#1 add ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/classes/ui/KeyboardNavigation.js#3 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/themes/modern/theme.js#2 edit | |
Change 539970 by cdamon@cdamon_judaspriest on 2015/03/19 19:09:19 Bug: 97994 - Tab into body in Compose is inefficient Check in built versions of TinyMCE. Includes a couple of versions of the paste plugin from bug 97552. https://bugzilla.zimbra.com/show_bug.cgi?id=97994 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/plugins/paste/plugin.dev.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/plugins/paste/plugin.min.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/themes/modern/theme.min.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.dev.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.jquery.dev.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.jquery.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.jquery.min.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.js#4 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/tiny_mce/tinymce-4.1.6/js/tinymce/tinymce.min.js#4 edit | |
Bug 98136 | IE 8.0 on Windows 7 : Conversation is not shown in reading pane. Only single message is shown |
Change 539290 by vbellows@vbellows-JP on 2015/03/11 15:55:12 Bug: 98136 - IE 8.0 on Windows 7 : Conversation is not shown in reading pane. Only single message is shown Happens for XP/IE8 too. IE8 throws an exception when insertBefore tries to insert a newItem and the reference item (for positioning) is null. https://bugzilla.zimbra.com/show_bug.cgi?id=98136 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#25 edit | |
Change 539291 by vbellows@vbellows-main on 2015/03/11 15:57:11 Bug: 98136 - IE 8.0 on Windows 7 : Conversation is not shown in reading pane. Only single message is shown Happens for XP/IE8 too. IE8 throws an exception when insertBefore tries to insert a newItem and the reference item (for positioning) is null. Merging //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail /view/ZmConvView2.js to //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/Z mConvView2.js https://bugzilla.zimbra.com/show_bug.cgi?id=98136 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmConvView2.js#330 integrate | |
Bug 98226 | Cache Accounts, Aliases, Distribution Lists and Resources in the Client |
Change 539699 by heswaran@heswaran on 2015/03/17 01:44:46 Bug: 98226 Accounts, Aliases, Distribution Lists and Resources list is cached and reused. When user clicks refresh icon in the admin console, cache is bypassed and request is fired to get the data from the server. https://bugzilla.zimbra.com/show_bug.cgi?id=98226 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/accounts/controller/ZaAccountListController.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraAdmin/common/ZaController.js#4 edit | |
Change 539700 by heswaran@heswaran on 2015/03/17 01:47:14 Bug: 98226 Integrating from JUDASPRIEST to main. Accounts, Aliases, Distribution Lists and Resources list is cached and reused. When user clicks refresh icon in the admin console, cache is bypassed and request is fired to get the data from the server. https://bugzilla.zimbra.com/show_bug.cgi?id=98226 Affected files ... ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/accounts/controller/ZaAccountListController.js#258 integrate ... //depot/zimbra/main/ZimbraWebClient/WebRoot/js/zimbraAdmin/common/ZaController.js#169 integrate | |
Bug 98501 | Script Error: msg.getAddress is not a function when using Group By, sorting by From in conversation mode |
Change 540628 by eyarkon@eyarkon-JUDASPRIEST on 2015/03/27 19:35:33 Bug 98501 Script Error: msg.getAddress is not a function when using Group By, sorting by From in conversation mode This is one solution to the issue, that does not change any other functionality. This solution though is a quick one for the problem at hand. Pass the list type (msg/conv) to getGroupIdFromSortField, and for "From" return "none" for conv case. https://bugzilla.zimbra.com/show_bug.cgi?id=98501 Affected files ... ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/model/ZmMailListGroup.js#2 edit ... //depot/zimbra/JUDASPRIEST/ZimbraWebClient/WebRoot/js/zimbraMail/mail/view/ZmMailListView.js#7 edit | |
Bug 98773 | Patch2 zcs-patch-8.6.0_GA_1165 build broken |
Change 541830 by tpubliski@katbert on 2015/04/10 12:02:14 Bug: 95414,98773 Back out Change 541387. https://bugzilla.zimbra.com/show_bug.cgi?id=95414 https://bugzilla.zimbra.com/show_bug.cgi?id=98773 Affected files ... ... //depot/zimbra/JUDASPRIEST-860/ZimbraTagLib/src/java/com/zimbra/cs/taglib/bean/ZUserAgentBean.java#3 edit ... //depot/zimbra/JUDASPRIEST-860/ZimbraWebClient/WebRoot/public/login.jsp#6 edit |