Issue 34909 - cannot access Evolution 2.0 address books
cannot access Evolution 2.0 address books
Status: CLOSED FIXED
Product: Base
Classification: Application
Component: code
OOo 1.1.1
All Linux
: P3 trivial with 5 votes (vote)
: OOo 2.0.1
Assigned To: Frank Schönheit
issues@dba
: oooqa
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-03 04:26 UTC by des
Modified: 2008-05-17 23:35 UTC (History)
9 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments
patch supplied by mmeeks (62.34 KB, application/x-compressed)
2004-12-07 13:49 UTC, Frank Schönheit
no flags Details
review results (5.54 KB, text/plain)
2004-12-10 10:53 UTC, Frank Schönheit
no flags Details
open items (2.01 KB, text/plain)
2005-02-16 10:59 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description des 2004-10-03 04:26:02 UTC
Evolution 2.0 has the user's address book files in ~/.evolution, rather than
~/evolution, as in 1.4. OOo does not seem able to access the new version, and
there is no mechanism to point it to the new directory structure. (As an aside,
changing the 1.4 directory name does not prevent OOo from finding the old
address book).
Comment 1 Frank Schönheit 2004-10-11 14:59:51 UTC
Michael, is it possible that Evolution does not contain the address book
exporter script anymore? I know it has a separated address backend - perhaps the
exporter script was removed in this move?
Comment 2 mmeeks 2004-10-12 16:10:04 UTC
Frank, sadly I don't keep a careful-enough eye on the evo. development in this
area it seems.

Last time - evolution-addressbook-export was in the global path, and (I believe)
OO.o hard-coded some mystic, prefix-dependant path to it.

Now we've put it in some mystic, prefix dependant path (poetic justice methinks :-)

On my machine it is:
/opt/gnome/libexec/evolution/2.0/evolution-addressbook-export

But on RH machines etc. it'd be /usr/libexec/... I guess.
Comment 3 Frank Schönheit 2004-10-13 07:20:25 UTC
Okay, thanks.

Marc, could you please confirm this and then assign the issue to Wind?
Comment 4 sbilsoe 2004-11-09 11:58:19 UTC

//development.openoffice.org/releases/OOo_2_0_timetable.html  2/3 down


	canceled
	PCD Gnome Integration - Extend current solution to import all adressbooks (cp)
	evoab03

Has the cancellation of evoab3 anything to do with this issue ?
Comment 5 Frank Schönheit 2004-11-11 09:29:10 UTC
Not really. evoab3 was about making OOo aware of all address books in evolution,
which should have been independent on making OOo Evo2.0-aware. In the meantime,
it should that you cannot really separate these two, since OOo's way to access
Evo doesn't work anymore with Evo 2.0.

(side note: correcting priority according to
http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority).
Since Ximian (in persona Michael Meeks) contributed back their fixes to make
their Ximian Office (not sure whether this is the proper name :) Evo2.0-aware,
we can now try to fix this for the OOo 2.0 branch.
Comment 6 marc.neumann 2004-11-22 13:02:18 UTC
I can't also access by evolution 1.5.94.1 addressbook -> reassign to windly
Comment 7 wind.li 2004-11-24 06:06:18 UTC
I finally find out the reason why we can't access Evolution 2.0 address books. 
See http://bugzilla.ximian.com/show_bug.cgi?id=69870.
evolution-addressbook-export --format=csv does not work now.
Comment 8 Frank Schönheit 2004-11-25 08:55:44 UTC
grabbing

Thankfully, Ximian already has a patch for this. Michael Meeks offered us those
patches, to be found at http://ooo.ximian.com/patches/evo2/.

I'm planning to do a review of them ASAP (Michael, did you by chance find time
to integrate them into a dedicated CWS?), and then all what's left is to build a
CWS ...
Comment 9 Frank Schönheit 2004-11-25 08:56:04 UTC
accepting
Comment 10 Frank Schönheit 2004-11-25 10:11:14 UTC
forgot: Wind, thanks for finding this issue @ximian! :)
Comment 11 Frank Schönheit 2004-12-07 13:49:31 UTC
Created attachment 20213 [details]
patch supplied by mmeeks
Comment 12 Frank Schönheit 2004-12-10 10:53:38 UTC
Created attachment 20374 [details]
review results
Comment 13 Frank Schönheit 2004-12-10 10:58:43 UTC
I attached the results of the patch review here, instead of pasting them into
the description.

Michael, there are a few points which definately need to be addressed before
putting this into the final product, plus a number of nits which should not
hinder an integration.

I could assist in resolving some of those, but only after I have this thing
compiling, which leads me to:
- Do I see this right that currently, this compiles only on systems where Evolution
  is installed? This could make it somewhat difficult ...
- Where do the needed Evolution include files / libs come from? Is there some
  configuration option to point my build env to them?

Thanks
Frank
Comment 14 Frank Schönheit 2004-12-10 11:05:52 UTC
forget to mention that in the review text file, serious issues are marked with a
'*', everything else with '-'
Comment 15 mmeeks 2004-12-10 15:10:21 UTC
Hi Frank; so - the guy who did much of this work is Jayant:

Jayant - can you work through the problems that Frank has identified, fixing /
responding to the queries one by one ?

Frank - I'm unconvinced by the authentication situation; I suspect there will be
nasty problems here.

The same back-end (evolution) may, or may not require authentication - depending
on a number of factors [ local-file, or remote LDAP, exchange, G/W ], worse the
results returned may depend on whether you are authenticated or not.

Will your higher-level authentication code work with this ?
Comment 16 Frank Schönheit 2004-12-10 15:40:53 UTC
First a general note why your current solution is bad, then ideas how to solve
it :).

A requirement (by definition) for every UNO API is that unless told otherwise,
no component should at its own authority invoke any user interface. If you call
XFoo.doSomething, and this invokes UI, this is considered a bug.
The past has shown that such behaviour would make the API, and thus OOo as a
whole, not scriptable. If everything you do while using the API has the
potential to block you whole script, the API is rendered useless.
I know that this rule has not been followed in OOo 1.x :), but all known places
vialoting it should have been fixed in the meantime.

In general, if your component needs UI, its client either needs to *explicitily*
allow it, or pass a callback to be used when UI is needed.

For SDBC drivers, the idea is that whoever invokes the driver, must pass the
necessaary (authentication) information (which is done in the info sequence in
XDriver::connect), or pass a callback which the driver can use to obtain this
information.



In OOo, the user who creates the database usually should know whether the
backend needs authentication. There's a "User"/"need password" setting for this
in the database properties dialog (data source administration in 1.x).

Shouldn't this also hold for an EvoAB? If I as a user create a "Evolution
address book database" in OOo, shouldn't I know whether this address book
requires authentication? If so, I should enter this in the database properties.
Then OOo will authenticate before connecting, and pass the authentication
information down to the driver.

If for some reason this does not work - i.e., if a user cannot decide on a
per-database basis whether it requires authentication, but this needs to be
decided dynamically at connection time -, then we need to pass down a callback.
Despite what I said in the review.txt, XCompletedConnection would not be a
solution, as it is lacking some information. What we would need is a method
analogous to XDriver::connect, which additionally gets an XInteractionHandler
passed (the usual interaction handler implementation is able to handle
authentication requests).
Comment 17 stx123 2005-01-19 15:59:15 UTC
Hi, as Martin pointed out on the releases list we are coming
closer to 2.0 Beta.
http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=8258
Is your work making progress and would be ready for 2.0
as the target milestone indicates?
Thanks, Stefan
Comment 18 mmeeks 2005-02-09 17:36:48 UTC
Yes - it is progressing well; we've checked the data into the evoab201 cws - and
we're waiting for Frank's final review / approval etc. Re-assigning to Frank.
Comment 19 Frank Schönheit 2005-02-10 10:32:43 UTC
Jayant and Michael, thanks for your work on this! I'll care for this CWS ASAP
(which is next week).
Comment 20 Frank Schönheit 2005-02-16 10:59:05 UTC
Created attachment 22697 [details]
open items
Comment 21 Frank Schönheit 2005-02-16 11:01:02 UTC
fs->jayant: attached you find a list of open issues with the code, mostly minor
ones, where only 4 are serious enough to block the integration.

I'm going to play with building this thing ....
Comment 22 marc.neumann 2005-04-22 09:35:48 UTC
retarget to 2.0.1
Comment 23 marc.neumann 2005-04-27 15:03:32 UTC
*** Issue 40317 has been marked as a duplicate of this issue. ***
Comment 24 marc.neumann 2005-04-27 15:04:53 UTC
have a look on issue 40317 also
Comment 25 verthezp 2005-12-07 20:31:09 UTC
Issue 40317 is not solved in 2.0.1 RC2 as packaged by the Fedora Core 4
update openoffice.org-...-2.0.1-143.2.1.

As already mentioned in that issue, this makes the integration with
evolution pointless, or at least very unusable...

Since issue 40317 has been marked duplicate of the current issue, this
cannot be set as resolved.
Comment 26 mmeeks 2005-12-08 10:20:21 UTC
Caolan - might be interesting; Frank - any idea why this is marked 'Resolved
Fixed' seemingly without a comment ?
Comment 27 Frank Schönheit 2005-12-08 12:01:03 UTC
Not really. Probably because there was a wild mix: 2 different drivers, plus
some initial bug in the CSV exporter in Evo2 which affected one of the drivers.

I think this issue here was (finally) used as "implement the new driver", not as
"Evo2-access doesn't work anymore" ....


Which driver is part of Fedora's OOo build - libevoab1 or libavoab2?
Comment 28 verthezp 2005-12-08 20:03:05 UTC
From what I see, they are both in there:

/usr/lib/openoffice.org2.0/program$ ls -l libevo*
-rwxr-xr-x  1 root root 282624 Dec  4 18:24 libevoab1.so
-rwxr-xr-x  1 root root 196116 Dec  4 18:24 libevoab2.so

I can understand that the reason for this bug was to implement the
driver, but then my original bug should not have been made duplicate
of this one...  Should I reopen Issue 40317 ?
Comment 29 Frank Schönheit 2005-12-19 08:47:49 UTC
Yes, you might want to do so.
Comment 30 ace_dent 2008-05-17 21:31:50 UTC
The Issue you raised has been marked as 'Resolved' and not updated within the
last 1 year+. I am therefore setting this issue to 'Verified' as the first step
towards Closing it. If you feel this is incorrect, please re-open the issue and
add any comments.

Many thanks,
Andrew
 
Cleaning-up and Closing old Issues
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html
Comment 31 ace_dent 2008-05-17 23:35:02 UTC
As per previous posting: Verified -> Closed.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew