(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #330769 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=330769 Imported into Bugzilla on 02/04/99 16:16) Related to bug 329988 and bug 330386 Build: PPC Oct 20.2 Nova build installed on PPC 8500/180, OS 8.5 Win32 Oct 20.2 Nova build installed on Compaq Deskpro P133, NT 4.0 Problem: Using Todds directory server 'Snafu', I replicated the directory successfully. After deleting an entry on the server, I tried to replicate again. It failed to removed the deleted ldap entry from the local copy after going offline. Note: Todd and Scott created a utility called 'repltest' that allows you to delete an entry from the server. Steps to reproduce problem: 1) Create a new directory entry for Todd's directory server "snafu" Description: Snafu LDAP server: snafu.mcom.com Server Root: airius.mcom port: 389 2) Select Snafu and click on the Property/Get Info button off the tool bar 3) Click on Offline Setting tab 4) Check the option to mark this directory for download 5) Click on the Update button The progress dialog appears displaying the number of ldap entries being replicated. 6) Go offline by clicking on the offline icon on the bottom left corner of the window. With Snafu still selected, it should display all the names replicated 7) Go online 8) Use Repltest utility to delete an ldap entry from the server The utility will tell you what name it deleted 9) Click on the Property button to bring up the Snafu LDAP Server Properties window. 10) Click on the Offline Setting tab and click on the Update button 11) Go offline 12) Select the Snafu directory. Notice all the names are displayed but the name deleted from the server has NOT been removed from the local copy.

Setting TFV to 4.51. Deletes don't work because the database is not indexed by dn. If we index the database by dn, that requires a format change. One other possibility for 4.51 would be to stuff the dns in the index field (which IS indexed). Since LDAP entries don't have nick names this might be a viable solution.....

Added yoel and bfox to the cclist, when will we know if this makes this the 4.5.1 release?

Scott, do you know something about the feasibility of this that I don't? I didn't think this was doable in 4.51.

At the time I set a TFV to 4.51, we were setting a lot of bugs that weren't going to get fixed in 4.5 to 4.51.... This problem is very very hard. I thought we weren't going to promise this for 4.51. I'd like to move it to 5.0 The only thing we could try to do for 4.51 (and I'm not sure if we can do it) is store the dn in the nick name field for LDAP entries.....

TFV 5.0 > store the dn in the nick name field for LDAP entries We could do that, but I'd be a little concerned that someone had remapped nickname to something else of their choosing.

will we have LDAP replication in 5.0? qa contact to pmock

Reassigning to myself for M8.

won't be fixed for a while

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

We're not doing LDAP for PR1, so this bug does not need to be fixed until after PR1

M15

LDAP replication is not going to make Seamonkey. Moving onto the helpwanted list.

4.x codebase. INVALID.

If Netscape brings over its LDAP code, this might still be interesting, but we can get to it via the ldap meta bug.

Verified as invalid.