All users were logged out of Bugzilla on October 13th, 2018

Address Book Export in tab/txt format, then import and it fails

VERIFIED FIXED in mozilla1.2beta

Status

--
major
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: nbaca, Assigned: cavin)

Tracking

Trunk
mozilla1.2beta
x86
Windows ME

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
Branch build 2002-07-01: WinMe

Overview: Select an address book, export in txt or tab format, then import the
same file and it fails.

Steps to reproduce:
1. Select an address book which is populated with some cards
2. Select Tools|Export
3. In the Export Address Book dialog select txt (or tab) format in the pull down
menu and give the file a name (i.e. test.txt or test.tab)
4. Select Tools|Import
5. Select the Address Books radio button, select the "Text file (LDIF, tab, csv,
txt) option, Next.
6. For the Files of Type pull down select the appropriate extension so you can
see the file
7. Select the file (i.e. text.tab)

Actual Results: The Import Address Book dialog appears displaying an option to
move the fields around. The "First Name" field is present but look at the record
to the right. It displays all the data separated by a pipe sign. Select the OK
button and the name of the address book is present but it is blank, no cards
appear in the right pane.

Additional Information:
- Export ldif, import ldif = ok
- Export csv, import csv = ok
(Reporter)

Comment 1

17 years ago
Marking nsbeta1 so this is considered fixed for this release.
Keywords: nsbeta1
(Reporter)

Comment 2

17 years ago
Created attachment 90021 [details]
All data is separated by pipe sign next to the First Name field
(Reporter)

Comment 3

17 years ago
Additional Information:
Using the same file (i.e. test.tab), I can import it into 4.x and it imports
successfully. 
(Reporter)

Comment 4

17 years ago
Marking major since exporting/importing in txt or tab format is completely
broken at this point.
Assignee: racham → cavin
Severity: normal → major
I believe I caused this regression.  it has to do with a card with multiple line
in the notes field.  This regressed with my fix to get multiple line notes
fields to work with ldif.

I'm not sure why it affects txt,tab but not csv.

here's what we found:

when exporting, make sure you first card has a first name and multiple lines in
the notes field.

when you export, you'll see CRs (or LFs, not sure) in the line.

We should see how 4.x exported multiple notes lines when we exported to
txt,tab,or csv, and follow that.  (assuming it works in 4.x)

interesting note, nbaca says that when she exports from 7.0 to tab, 4.x is able
to import it.

the bug may therefore be in the *import* code, not the export.  and we need to
handle multiple line values.

my opinion is that we can ship with this, since we encourage people to use LDIF
for import and export.
(Assignee)

Comment 6

17 years ago
nbaca's exported .tab file contains 5 addresses and one of the addresses has 6 
lines of notes. The notes represented in the exported file as 5 separated lines 
with the 1st note being part of the address line itself (as the last field). So 
the file looks something like ('^' represents a tab delimiter):

John1^Smith^John1 Smith^^jsmith1@netscape.com . . .  
John2^Smith^John2 Smith^^jsmith2@netscape.com . . .  
John3^Smith^John3 Smith^^jsmith3@netscape.com . . .  
John4^Smith^John4 Smith^^jsmith4@netscape.com . . .
John5^Smith^John5 Smith^^jsmith5@netscape.com . . . Note1
Note2
Ntoe3
Ntoe4
Note5
Note6

In nsTextAddress::DetermineDelim(), where we figure out what delimiter we should 
use to parse the import file, we end it up picking comma as the delimiter 
instead of tab because there are equal number of tab and comma lines in the file 
(ie, first 5 lines are tab delimited and last 5 are comma delimited). Had the 
file contained one less note then tab would have been chosen as the delimiter 
(meaning that it would have worked).

When exporting addresses with multiple lines of notes, 4.x makes all notes into 
a single note field with adjacent notes separated by two spaces. Using the above 
example, the address line for John5 Smith looks like:

 John5^Smith^John5 Smith^^jsmith5@netscape.com . . . ^Note1  Notes2 ... Note6

I think we should do the same when exporting multiple notes. This will make the 
existing parsing code stays the same. All we have to do is to add code to join 
all notes together during export and to break notes apart during import.

Comment 7

17 years ago
Due to the fact that it only happens with tab/txt and with notes that go beyond
5 lines, I think we can live with this for Mach V rtm.  I'm not removing the
nsbeta1 since it can be used for the next release.
(Assignee)

Comment 8

17 years ago
Actually it happens when the number of address lines is less than or equal to 
the notes lines, and I think it would not happen very often.
(Assignee)

Comment 9

17 years ago
On import, 4.x does not break concatenated notes apart (ie, there will be only 
one single line for notes after import).
(Assignee)

Comment 10

17 years ago
Created attachment 90537 [details] [diff] [review]
Proposed patch, v1

Concatenate all notes into a single line.
Comment on attachment 90537 [details] [diff] [review]
Proposed patch, v1

R=ducarroz
Attachment #90537 - Flags: review+
Comment on attachment 90537 [details] [diff] [review]
Proposed patch, v1

needs work.

you are doing more work than you need to.  
In this case you are copying the value and checking IsEmpty() in all cases.
also, the column name should always be in the right case, so you don't need
to do a strcasecmp.  strcmp is enough.	also, you can use nsCRT::CR and
nsCRT::LF
which makes it more readable.

I think you want to replace

rv = importService->SystemStringFromUnicode(value.get(), valueCStr);

with:

// comment...
if (!strcmp(EXPORT_ATTRIBUTES_TABLE[i].abColName, kNotesColumn)) {
  nsAutoString tempStr(value.get());
  if (!tempStr.IsEmpty()) {
    tempStr.ReplaceChar(nsCRT::CR, ' ');
    tempStr.ReplaceChar(nsCRT::LF, ' ');
  }
  rv = importService->SystemStringFromUnicode(tempStr.get(), valueCStr);
}
else {
  rv = importService->SystemStringFromUnicode(value.get(), valueCStr);
}
Attachment #90537 - Flags: needs-work+
(Assignee)

Comment 13

17 years ago
Created attachment 90567 [details] [diff] [review]
Proposed patch, v2

Incorporated Seth's comments.
Attachment #90537 - Attachment is obsolete: true
Comment on attachment 90567 [details] [diff] [review]
Proposed patch, v2

sr=sspitzer
Attachment #90567 - Flags: superreview+
Comment on attachment 90567 [details] [diff] [review]
Proposed patch, v2

R=ducarroz
Attachment #90567 - Flags: review+
Comment on attachment 90567 [details] [diff] [review]
Proposed patch, v2

R=ducarroz
(Assignee)

Comment 17

17 years ago
Fix checked in to the trunk.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

17 years ago
Reopening because I found an additional problem on Mac 9.1 related to notes.

Branch build 2002-07-12: Mac 9.1
Problem: On the mac the original cards are present but extra cards are created.
Steps to reproduce:
1. Create an address book with three cards 
2. In one of the cards includes notes (3 lines of text) such as:
"one
 two
 three" 
3. Export in text format (txt, tab or csv)
4. Import

Actual Results: The original cards are present but 2 more cards are present. The
first extra card has "two" for the First Name and the other extra card has
"three" for the First Name. Interesting that the original card w/notes no longer
has notes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Target Milestone: --- → mozilla1.2beta
(Assignee)

Comment 19

16 years ago
This was fixed only on the trunk but not the branch.

But there's another problem with the latest trunk build. The problem is that we 
export fields that are not supposed to be exported. For example, fields like 
work phone type, default email column, etc still show up in the exported .tab 
and/or .csv files (as fields with no value). The fix is to not write out the 
delimiter associated with the fields that are not supposed to be exported. A 
patch is coming.
(Assignee)

Comment 20

16 years ago
Created attachment 100779 [details] [diff] [review]
Proposed patch, v1

Don't write out the delimiter if the field is to be ignored (for export). Also,
cellular number type should not be exported.
Comment on attachment 100779 [details] [diff] [review]
Proposed patch, v1

R=ducarroz
Attachment #100779 - Flags: review+
Comment on attachment 100779 [details] [diff] [review]
Proposed patch, v1

sr=sspitzer

thanks for cleaning up my bad code.
Attachment #100779 - Flags: superreview+
(Assignee)

Comment 23

16 years ago
Fix checked in to the trunk.
(Assignee)

Comment 24

16 years ago
Marking fixed. Please reopen it if this needs to be on the branch.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 25

16 years ago
Trunk build 2002-11-08-13: WinMe
Trunk build 2002-11-21: Linux 8, Mac 10.1.3
Verified Fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.