Tickets :: [#7319] Add different import methods or logics for syncml vs. inter-application imports

6.0.0-alpha14

7/2/25

Summary	Add different import methods or logics for syncml vs. inter-application imports
Queue	Synchronization
Queue Version	Git master
Type	Enhancement
State	Rejected
Priority	1. Low
Owners	Horde Developers (at)
Requester	patrick.abiven (at) apitech (dot) fr
Created	09/10/2008 (6139 days ago)
Due
Updated	01/28/2016 (3443 days ago)
Assigned	10/24/2010 (5365 days ago)
Resolved	01/28/2016 (3443 days ago)
Milestone
Patch	No

01/28/2016 04:30:05 PM	Jan Schneider	State ⇒ Rejected

10/17/2012 08:44:22 PM	Michael Rubinsky	Comment #6 State ⇒ Feedback Milestone ⇒	Reply to this comment
Remove as a show stopper. Imports work fine and are added to the default_* source. Not really sure how else this would work, even with a dedicated method since we allow multiple sources per user, but clients don't get to specify multiple sources. We also have a parameter since H4 for the format the data is being imported in. If still needed, would have to target for H6 since changing something like this would be a BC break.

03/31/2011 11:40:28 PM	Jan Schneider	Milestone ⇒ 5

10/24/2010 12:14:43 PM	Jan Schneider	Assigned to Horde Developers State ⇒ Assigned Version ⇒ Git master Milestone ⇒ 4

09/22/2008 11:59:02 AM	Jan Schneider	Summary ⇒ Add different import methods or logics for syncml vs. inter-application imports

09/22/2008 11:58:07 AM	Jan Schneider	Priority ⇒ 1. Low Type ⇒ Enhancement State ⇒ Accepted

09/19/2008 08:48:41 AM	patrick (dot) abiven (at) apitech (dot) fr	Comment #5	Reply to this comment
Regarding the default_dir vs. sync_books, there is not much we can do at the moment, because the import function is not only used for SyncML but for other imports too. As a workaround for our specific needs, we have modified: - lib/SyncML/Device/Backend/Horde.php, function addEntry, if the $database is set to 'contacts', then we call the '/import' function with a specific value for the third argument. - turba/lib/api.php, function _turba_import, if $import_source argument is set to our specific value, then we retrieve the address book from prefs['sync_books'] and not from prefs['default_dir'] Regards Patrick

09/11/2008 01:12:43 PM	Jan Schneider	Comment #4	Reply to this comment
[Show Quoted Text - 11 lines][Hide Quoted Text] Upgrading from Horde 3.1 to Horde 3.2 raises an issue about the format of the pref['default_dir'] which contained 'localsql' (Horde 3.1) and should now contain 'firstname.lastname' (Horde 3.2). I have no idea what you mean with this sentence. We had a Horde 3.1 platform, and now we are moving to Horde 3.2 but we are keeping the same database. So values of user options are kept (from horde_prefs table). We notice that the format of the ['default_dir'] option has changed between Horde 3.1 (it was localsql) and Horde 3.2 (it is now firstname.lastname). Is "firstname.lastname" the user name, i.e. the name that users use to login with? Otherwise it doesn't make any sense, because the address book names have nothing to do with names. If this is the user name, then this is the correct behavior, if you use shares with the localsql source. Read the upgrading instructions and check the mailing list archive. Regarding the default_dir vs. sync_books, there is not much we can do at the moment, because the import function is not only used for SyncML but for other imports too.

09/11/2008 01:04:20 PM	patrick (dot) abiven (at) apitech (dot) fr	Comment #3	Reply to this comment
Upgrading from Horde 3.1 to Horde 3.2 raises an issue about the format of the pref['default_dir'] which contained 'localsql' (Horde 3.1) and should now contain 'firstname.lastname' (Horde 3.2). I have no idea what you mean with this sentence. Hello Sorry for my poor report. We had a Horde 3.1 platform, and now we are moving to Horde 3.2 but we are keeping the same database. So values of user options are kept (from horde_prefs table). We notice that the format of the ['default_dir'] option has changed between Horde 3.1 (it was localsql) and Horde 3.2 (it is now firstname.lastname). Regards Patrick

09/11/2008 12:57:11 PM	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
Upgrading from Horde 3.1 to Horde 3.2 raises an issue about the format of the pref['default_dir'] which contained 'localsql' (Horde 3.1) and should now contain 'firstname.lastname' (Horde 3.2). I have no idea what you mean with this sentence.

09/10/2008 11:28:03 AM	patrick (dot) abiven (at) apitech (dot) fr	Comment #1 Priority ⇒ 1. Low State ⇒ Unconfirmed Patch ⇒ No Milestone ⇒ Summary ⇒ Add new contact uses [default_dir] and not [sync_books] Type ⇒ Bug Queue ⇒ Synchronization	Reply to this comment
Hello Adding a new contact through SyncML uses the _turba_import function (turba/lib/api.php) which retrieves the adress book from pref['default_dir'] and not from pref['sync_books']. Upgrading from Horde 3.1 to Horde 3.2 raises an issue about the format of the pref['default_dir'] which contained 'localsql' (Horde 3.1) and should now contain 'firstname.lastname' (Horde 3.2). Regards Patrick