Thunderbird can have multiple profiles which all can have multiple address books. Extend our mork-based driver so that it can access all of them.
Extracts from past email to the Mailing list about this:
"sdbc:address:thunderbird" would get the abook.mab from the default
profile, but "sdbc:address:thunderbird:/home/user/backup/blah.mab"
would open file /home/user/backup/blah.mab
This would be useful to open .mab files that come from backups, that
are copied from other computers or other users, etc.
Actually, I can see another specific case, which is to access other
profiles than the default. It would be nice not to hard-code the full
path there, so maybe something like
to open the profile called "FOO" in profiles.ini?
In connectivity/source/drivers/mork/MConnection.cxx, I see:
OUString defaultProfile = m_pProfileAccess->getDefaultProfile(::com::sun::star::mozilla::MozillaProductType_Thunderbird);
Not sure what object m_pProfileAccess is, but if it has something like
we should be in business?
So maybe change the "file path" case to
for more clarity?
> At least I am not aware how you can open backup address book in
> Only thing that worked for me is to replace the deafult one from the
> user profile.
There is a bit better. In Icedove 3.0.11:
Press button "Address Book" or CTRL-SHIFT-b or menu tools / Address Book
In new window, menu File / New / Address Book
Enter name "My backup from tape/other computer/..."
This creates a new .mab file; overwrite *that* one instead of the
default one :)
This begs the question: can our Icedove/Thunderbird integration open
these other .mab files "easily"? Does the user have to give the
filename (abook-1.mab, abook-2.mab, abook-3.mab, ...) or the name?
Sadly, the name-to-filename mapping is stored in prefs.js:
user_pref("ldap_2.servers.jsddshjds.description", "my backup from tape 12/2/2012");
Which means yet another file to parse for the full completely
user-friendly case of "show the same list as Thunderbird, let the user
choose-by-click one of them" :-| And also that's even more of an
"internal implementation detail of Icedove/Thunderbird" than the .mab
file format is.
If we do that, we should store (in the sdbc: URL) the *internal* name
(in my example: "jsddsgjds"), which is basically (an unification /
drop spaces version of) the name the address book had at creation
time, but that does not change when the address book is renamed.
Or (I'm thinking out loud here) the filename, e.g. abook-4.mab... That
also does not change, but may be easier to use. On the other hand, a
disadvantage is that if the address book is deleted, the filename gets
recycled by the next address book to be created, so suddenly we'd be
silently opening another address book.
Comments in bug 57419 and bug 51004 by "Nick222" seem to suggest that at least the lack of the "multi address book" part could be a regression; I'm not sure what the user was saying exactly. Maybe not.
I couldn't say this is an enhancement. Thunderbird collects the addresses in one addressbooks and has another addressbook for personal addresses. I was irritated to see a connection to thunderbird without any addresses in my addressbook. So I moved one address to the personal addresses and could see, that only this (empty) addressbook is shown by Base.
Adding self to CC if not already on
Technically, this is also a regression compared to pre-mork days, maybe except the "multi-profile" part.
I still think it would be useful to be able to open an arbitrary .mab file, even it is not configured to be used in any Thunderbird profile, and even though (actually, *especially* since) Thunderbird is not able to do that.
Since the initial bug description is a but confused, here's a summary:
sdbc:address:thunderbird all address books in the default profile (including those created with menu File / New / Address Book)
sdbc:address:thunderbird:file:/home/user/backup/blah.mab gets that specific address book (and its lists, assuming this is stored in the .mab file)
sdbc:address:thunderbird:profile:FOO all address books in the "FOO" profile of Thunderbird/Icedove.
(The part about "we should store (in the sdbc: URL) the *internal* name" is nonsense, since when we use a profile, we don't have the address book name in the URL...)
Thinking aloud now... if we add schema support to the mork driver, we could have, in the "access by (default or non-default) profile" case, different schemas to access the address books by their different names:
1) name as displayed in Thunderbird (maybe only for the non-default address books... Maybe not that good an idea, since that name is NOT UNIQUE in Thunderbird/Icedove...)
2) "internal name" (more stable, probably guaranteed without spaces in it)
3) filename (is that a good idea... not sure)
So maybe we have only one name, the "internal name" anyway. <shrug>
(Schema support is still a good thing to separate address books from lists. And then we can have something like an INFORMATION_SCHEMA to show the "internal (table) name to display name" mapping.)
(In reply to Lionel Elie Mamane from comment #4)
> Since the initial bug description is a but confused, here's a summary:
is a *bit* confused
Sorry, too high level for me.
As this is a regression in functionality, but apparently a result of a deliberate change of library rather than a bug in an unknown commit, setting:
Whiteboard -> bibisectNotNeeded
Also, we should allow the user (through the SDBC URL) to select one of thunderbird, seamonkey (and firefox?) specifically; currently the first of seamonkey, thunderbird, firefox is taken automagically (but see bug 39279), and the others are simply unavailable.
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded)
I do not understand how an enhancement request could be a bug report about regression too. If it worked before and the current behavior is resulting from a deliberate change, then it is not an enhancement.
Changing enhancement for normal bug.
Currently, LO Base 5.1 is able to import multi address books in a Thunderbird user profile. When imported you can edit the database properties and choose between all thunderbird profiles. So, for me, LO works as expected by this bug report.
Closing as WorksForMe. Please, feel free to reopen if you disagree.
Best regards. JBF