After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 274393 - Changes to LDAP search base setting are not saved
Changes to LDAP search base setting are not saved
Status: RESOLVED DUPLICATE of bug 274308
Product: evolution
Classification: Applications
Component: Contacts
2.2.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-04-05 04:51 UTC by Matt Brown
Modified: 2005-08-18 17:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matt Brown 2005-04-05 04:51:53 UTC
Description of Problem:
When editing the settings of an LDAP address book the search base field is
not saved when it is modified.

Steps to reproduce the problem:
1. Create a new LDAP address book 
2. Right click on the Address Book in the left hane pane and select Properties 
3. On the detail tab of the properties window modify the search base field
4. Click OK
5. Open the Address Book properties again 


Actual Results:
The search base field retains the value it was given when the address book
was first created

Expected Results:
The search base field should contain the modified value set in Step 3

How often does this happen? 
Every time you edit the properties and attempt to change the search base

Additional Information:
Comment 1 Evan Prodromou 2005-05-20 13:33:15 UTC
PROBLY but not necessarily related: changing the port for the addressbook
doesn't seem to get saved, either. This is pretty crummy for ActiveDirectory
servers, which have a more standards-compliant service on port 3268.
Comment 2 Bojan Smojver 2005-05-25 02:36:51 UTC
This is in Red Hat bug database too:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158153
Comment 3 Ryan Baumann 2005-06-15 16:34:28 UTC
This bug is fixed if you're using the CVS HEAD version of evolution-data-server.
Here's what was happening:

-absolute uri gets set the first time (can apparently only be set directly once,
looking at e_source_set_absolute_uri)
-absolute uri gets read as values for the GUI
-e_source_set_relative_uri is called with any changes you make in the properties
-relative uri gets changed
-absolute uri *should* get changed with e_source_build_absolute_uri when
e_source_set_relative_uri is called, but it doesn't (this is fixed on CVS HEAD
for evolution-data-server)

Now that e_source_set_relative_uri changes the absolute uri properly, it works
as expected.
Comment 4 Matt Brown 2005-06-16 13:21:01 UTC
Hmm, 

It's definitely much much better, but it's still does not exhibit the expected
behaviour in my opinion. The change is certainly reflected in the UI immediately
now, but I am still required to close evolution and start it again before the
change takes effect. Is there a reason why the change to the search base cannot
take effect immediately?

Steps to Reproduce:

1) Start with an LDAP addressbook that is correctly configured and working
2) Search for a contact, observe that contact is found
3) Change search base to be invalid using procedure described in original report
4) Observe that on reentering properties dialog the UI is indeed updated
5) Observe that queries to the LDAP server still use the original search base
and results are returned fine
6) Close evo and restart
7) Try a search, observe it fails as query is made with the invalid search base
set in step 3
8) Reset search base to correct value
9) Observe that address book still doesn't work
10) Close and restart evo
11) Address book now works again

Comment 5 Ryan Baumann 2005-06-16 16:58:24 UTC
Re #4: I agree, but I think what you're describing in this comment is a separate
  issue already covered in Bug 273290.
Comment 6 Matt Brown 2005-06-16 21:12:28 UTC
OK. I agree that this bug is fixed. I'm happy for it to be closed. Doesn't look
like I can do it however as it was imported from the Ximian bugzilla and hence
I'm not actually recorded as the reporter.

Thanks for the fix. 
Comment 7 Luis Villa 2005-08-18 17:34:17 UTC

*** This bug has been marked as a duplicate of 274308 ***