This is related to the export issue in http://studios.thoughtworks.com/discussion/forums/7/topics/569 which was fixed in version 2.0.1 but this one deals with tab characters 0×09. Note that I was using Version 2.0.1 for this. Here’s the scenario: I created a card and when editing the description I pasted in text from an email message that looked something like this in the edit window (hope this comes across in the forum):

—-Original Message-—
> From:<tab>Bobby
> Sent:<tab>Bobby
...

The important thing here is the <tab> above was an actual tab character and was in several places in the body of the description. Mingle accepted this just fine when I saved the card and in fact interprets the leading > on the lines as special formatting that I hadn’t seen in the Wiki formatting page, but it looked nice.

Then I used the Export to Excel feature, selected all, copied, pasted to Excel, all without a problem. The tabs in the Description didn’t appear to be a problem for Excel, everything lined up just fine. But here’s where the problem came:

In Excel I did Ctrl-A to select all and Ctrl-C to copy the stuff I’d just pasted there. Then I went to Mingle’s Import from Excel feature, pasted into the box and clicked “Next to preview”. Mingle hemmed and hawed a bit but then ended up failing to show the preview, complaining that ”> Sent:” is not a valid card number.

My guess is the export worked ok because the Description field came out with quotes around it, but when I did the Ctrl-A in Excel it didn’t wrap the Description in quotes. Thus the tabs in the Description field got interpreted as delimiters on the import attempt.
Sure enough if I remove the tabs from the Descripton everything works fine in both directions.

Since you can’t control what Excel does (I was using Excel 2007 but I’d bet earlier versions would do the same) I’d recommend Mingle simply filter out any tab characters in any descriptions, just not allow them. This is what we call the “Henny Youngman Solution” from the old one liner: Man: “Doctor, Doctor! It hurts when I do that!” Doctor: “Don’t do that.”

Sure you can just tell folks not to use tabs, but since your application allows them you’ve left it in a situation that it cannot import what it just exported. By forcing tabs to be replaced, say, by a single space (or even offer a configurable space-to-tab value the user can set, which I think is overkill considering how web browsers treat spaces and tabs) when the description (or any other field) enters the database you end up reserving tab for that special use. Then just add some caveats to the documenation around the Import from Excel section noting that tabs in any of the cells will probably cause problems with the import.

Hello sydd, you are correct. We cannot accept tabs in the content of tab separated import data. That said, there is a possibility that such data could get in – which would be through the method you just described. We look to revisit this is a future release.