6.0.0-git
2019-03-19

[#14513] Changes LDAP Addressbook sync to ActiveSync
Summary Changes LDAP Addressbook sync to ActiveSync
Queue Turba
Queue Version Git master
Type Bug
State Not A Bug
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester oliverafg (at) gmx (dot) de
Created 2016-11-12 (857 days ago)
Due
Updated 2016-11-12 (857 days ago)
Assigned
Resolved 2016-11-12 (857 days ago)
Milestone
Patch No

History
2016-11-12 18:35:08 oliverafg (at) gmx (dot) de Comment #4 Reply to this comment
Hi Michael once more,

I played around with it a little bit.

What works is reset of the ActiveSync devices.

So a quick and dirty workaround would be to offer a kind of cronjob to 
reset activesync devices.
I think once or twice a week should be a good balance between data 
usage / battery drain and a up to date addressbook.

regards
Oliver

2016-11-12 12:55:34 oliverafg (at) gmx (dot) de Comment #3 Reply to this comment
Hi Michael,
This is expected behavior, not a bug.
agree, it is not a bug. It is a feature which is not implemented
ActiveSync polls Horde's History system to detect non-email changes 
(email changes are detected by querying the IMAP server directly). 
Changing some data outside of Horde will of course not be caught by 
Horde.
check
If you want this to work, you would need to implement some decorator 
around the LDAP driver that would synchronize Horde's History system 
with the LDAP backend.  This is similar to how we deal with Kolab 
storage as a backend and detecting changes made by other Kolab 
clients - however, this approach is not feasible for a non-imap 
backend and will not be added upstream.
Hmm, imo this is a very important feature. LDAP/AD is THE backend in 
many companies. A lot of other services use LDAP as backend, in our 
case e.g. phone switch, IM, authentication and native email clients. 
Horde cannot (and here should not) be the master source for those 
systems.

So at this point other systems are writing changes to the LDAP 
directory and of course they should be synchronized to AS-clients.

There is also a real bug, with the multi value field mail on LDAP and 
horde. This avoids to use horde as the single point for updating 
contact information.


2016-11-12 01:35:58 Michael Rubinsky Comment #2
Assigned to Michael Rubinsky
State ⇒ Not A Bug
Priority ⇒ 1. Low
Reply to this comment
This is expected behavior, not a bug.

ActiveSync polls Horde's History system to detect non-email changes 
(email changes are detected by querying the IMAP server directly). 
Changing some data outside of Horde will of course not be caught by 
Horde.

If you want this to work, you would need to implement some decorator 
around the LDAP driver that would synchronize Horde's History system 
with the LDAP backend.  This is similar to how we deal with Kolab 
storage as a backend and detecting changes made by other Kolab clients 
- however, this approach is not feasible for a non-imap backend and 
will not be added upstream.

2016-11-12 00:44:45 oliverafg (at) gmx (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Changes LDAP Addressbook sync to ActiveSync
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hi,

I am not sure if I am doing something wrong. but I think it is a bug.

I use some LDAP backends as personal addressbook, group addressbooks 
(synced) and GAL.

The problem is per definition only for addressbooks synced on the 
mobile devices.

If I change something on the ActiveSync device or the Horde (turba) 
webfrontend, everything is synced fine and almost instant.

If I change it with an LDAP browser or e.g. Evolution, the changed or 
new entries do not show up on the Active Sync devices. Probably horde 
doesn't "want" to ask the LDAP for changes on every heartbeat. the 
only workaround so far, seems to be a complete re-sync triggered by 
horde or the mobile device.

In my opinion two options:
1) Maybe a counter the check for each device after every e.g. 4 hours 
for LDAP changes. This requires synced clocks on horde and the LDAP 
backend or some minutes security.
2) Maybe use a hash table and hash all LDAP entries every 4(?) hours. 
Needs also a counter for each device/user pair.

The counter stuff is bundled to an active devices, because the 
credentials are needed...

Thanks and regards

Saved Queries