[KOE-14] Implement workaround to Outlook limitation of only one contact folder per account Created: 12/Oct/16  Updated: 17/Jan/18  Resolved: 27/Feb/17

Status: Closed
Project: Kopano OL Extension
Component/s: None
Affects Version/s: None
Fix Version/s: 1.3
Security Level: Public

Type: Improvement Priority: Medium
Reporter: Felix Bartels Assignee: Patrick Simpson
Resolution: Done Votes: 3
Labels: None

Attachments: PNG File WarnRestart.png    
Issue Links:
Blocks
is blocked by KOE-61 Implement Client Capabilities header Closed

 Description   

Outlook ActiveSync implementation only allows one contact folder per account.

Preliminary tests show that, similar to the way the synchronisation of notes folders can be forced, Outlook can be tricked to also sync contact folders.

From ZO-53:
By transmitting secondary Contact folders as e.g. Appointment folders and have the plugin changing the folder class back to

  • IPF.Contact and
  • set 0x6A1A PT_LONG to 14 (user contact)
    This makes OL synchronize secondary contact folder as expected.
    The icon and "folder classification" is not updated until OL is restarted.
    The folder stays under Calendar and does not appear under Contacts until OL is restarted.
    Marking the folder as hidden and then shwoing it again does not solve that.

A working approach was implemented in https://stash.z-hub.io/projects/ZO/repos/z-push/commits/41587f43eea49efd085be955ec857c8c415e0d52

Still, there are side-effects. OL will immediately try to synchronize this folder. If there are contact entries in it, Z-Push will send them. This causes OL to crash as it cannot save contact entries in a calendar folder. This is the case before KOE kicks in and updates the properties. After the properties are updated this works flawlessly.
A required workaround is that Z-Push stalls the synchronization of such a folder until KOE tells it that the folder was successfully patched.



 Comments   
Comment by Sebastian Kummer [ 11/Jan/17 ]

Patrick Simpson as dicussed, a short resume of what is implemented in Version 2.4.0.1483554915.2097efe.
If KOE is installed:

  • new secondary contact folders will be send with type 18 (SYNC_FOLDER_TYPE_UNKNOWN) => maps to 0x6A1A PT_LONG
  • the displayname of the folder will have a zero width UTF-8 space (U+200B) appended to the name
  • no data will be synchronized until the folder is updated by the client and the space be removed

If a resync happens, the folder will again be synchronized as 18 + U+200B. It will then not receive further updates from the server until the name update (as above) will be done. No changes from the client are expected until this happens (needs testing).

Atm, folders that were already synchronized will not be updated to type 18 by Z-Push. This possibility is being investigated in https://jira.z-hub.io/browse/ZP-1134.
New contact folders and new profiles should work.
The client capabilities are not yet considered. Any KOE version will receive that behaviour in this version on the known systems.

Comment by Patrick Simpson [ 18/Jan/17 ]

I see contact folders coming in with type 18 and the invisible space. However, when I patch the folder, I see no contacts coming in.

What I do:

  • Type (0x6A1A) = 14
  • Container class = "IPF.Contact"
  • Display name = stripped name
  • EAS Name (0x6915) = stripped name

I also tried setting 6A17 and 6A1D to true, as that was required for notes.

However, nothing seems to happen to the folder.

Comment by Patrick Simpson [ 25/Jan/17 ]

The basic patching works. Somehow it works only if the update of the sync type, contain class and folder name are done in separate steps, and specifically in that order.

This means there'll most likely be 3 syncs back to the server for the folder. It also means we cannot really use sync type to filter to folders to patch, as the sync type may be updated successfully but updating the name may fail (if Outlook is shut down, or whatever). So for now I test if the name has the suffix and sync type == 18 or 14. If it's 14 and the name has the hidden character, it's patched again, just to be sure.

It's all done without restarting now, will add that.

Comment by Patrick Simpson [ 25/Jan/17 ]

Restarting now works too. It's available in build #112.

Comment by Sebastian Kummer [ 27/Jan/17 ]

I've just tested build #112 and found a few things:

  • after updating, OL crashed on restart. Log didn't show much, but last log message was: 'Debug: WebApp: Starting kdiscover: kopano.com'. Deactivating the webapp feature via plugin debugger fixed these crashes. Re-enabling this feature causes OL to crash again. I keep it disabled for now. Profiles that have only one account without kdiscover entry work.
  • when adding a folder the "want to restart" dialog pops up quickly, while the sharing dialog is still open. If I choose 'yes, restart' OL tells me after a few seconds that it failed as I still had dialogs open.
  • if I don't restart the folder is visible as mail folder, so it's not being hidden yet. I guess this is a make-dev-easier thing for now.
  • after the first successful restart via the dialog the folder pane was hidden and needed to be reactivated once.
  • when closing the shared folder dialog fast enough, the restart dialog option "yes" just closes OL but didn't restart it again for me. The first time I saw a quick scan being performed by my anti-virus (avira).

As comment to the above: when I did the patching manually I could change the sync type and the folder class in one step via OLSpy which triggered only one FolderSync request to the server.

Comment by Sebastian Kummer [ 01/Feb/17 ]

On #113:
On an older profile I still had a few unpatched folders. After starting this profile, I got a popup during the first settings call of KOE for one folder and shortly after a second popup for one of the other folders (both visible at the same time). After accepting these (do restart) I had a few of the mentioned warnings (dialog open) and there were several popups for the other folders.
Perhaps it's possible to show the popup only once and not on a per patch-required-folder basis.

Comment by Sebastian Kummer [ 01/Feb/17 ]

Interestingly OL 2013 with #113 does hide the folders after sync and before the popup.
But at least once the restart did not finalize the patching. It was then only done after I've restarted OL 2013 again manually.

Comment by Sebastian Kummer [ 13/Feb/17 ]

The dialog about "open dialogs" also appears when sending a large email that is not completely sent. OL shows a dialog asking if you want to wait before exit or just exit.

Comment by Patrick Simpson [ 22/Feb/17 ]

Setting the folder icon to the contacts icon creates a bit of a weird layout. Hiding the folder doesn't always work reliably, also when done from the UI thread.
Switching to other issues for now.

Still need to clean up the logic for the dialog, and hide it when other dialogs are visible.

Comment by Patrick Simpson [ 27/Feb/17 ]

I've figured out how to hide the folder properly: it cannot be done during the folder change event handler, but it can be done in the UI thread right after.

However, when I do that, I can also properly set the icon. When the icon is set, the folder looks (and acts) like a contacts folder, it syncs, it has a list of contacts, etc. The only issue is that it's in the list of mail folders rather than contact folders. So, unless someone objects, I'll change the icon instead. I'll still pop up the restart dialog, but with a much less stern warning, as the user is free to keep on working with the new contacts folder.

Comment by Patrick Simpson [ 27/Feb/17 ]

This is the new warning. I've also added a debug option to disable the warning.

Comment by Felix Bartels [ 27/Feb/17 ]

Looks good to me

Comment by Patrick Simpson [ 27/Feb/17 ]

This will be in build #133, currently building.

The approach with changing the icon also has the benefit that we don't need to do any further patching after restart, so the flow is a lot simpler. This also prevents any spurious dialogs from popping up.

And furthermore the restart dialog will now close any KOE windows before restarting.

Generated at Sun Aug 19 09:52:42 CEST 2018 using JIRA 7.4.1#74003-sha1:03b99481f2360849188a0c0422a6d3f38eac3534.