|Title||The TeamTrack integration fails with non-ASCII characters|
|Assigned user||Gareth Rees|
|Description||The tTrack integration does not cope with non-ASCII characters. For instance, "é" (character 0xe9). If this character is placed in a TeamTrack field, it gets into Perforce as "ÿffffffffffe9".|
Note that the first character is 0xff. Note also that the number of f's seems to depend on the exact platform: it's four on sandpiper (suggesting a 24-bit encoding) and ten on the reporting user's machine (suggesting a 48-bit encoding ?!). This encoding also appears in the log output; I don't think the P4DTI is doing it. Going the other way, putting "é" into a Perforce job causes the P4DTI to fail when trying to update tTrack (no message from the TeamShare API).
|Analysis||My best guess is that the TeamShare API uses this encoding, so non-ASCII characters are encoded before we see them. Possibly this is some standard Windows thing. In any case, I think our tTrack interface should fix these characters before they get into Python (and on the way back from Python also). This is complicated by the apparently variable length of the encoding, and by the question of how we handle characters which are more than one byte.|
The Bugzilla integration handles ISO 8859-1 characters OK in both directions, so I think this is definitely tTrack or the TeamShare API.
It's a TeamShare API problem. TeamShare promise that it will be fixed in TeamTrack 4.5. GDR 2001-02-19.
Fixed in TeamTrack 4507. Tested. GDR 2001-02-21.
|Created by||Nick Barnes|
|Created on||2001-01-29 11:27:02|
|Last modified by||Gareth Rees|
|Last modified on||2013-09-16 11:15:38|
|History||2001-01-29 NB Created.|
2001-02-19 GDR Added note to analysis.
2001-02-19 GDR Downgraded to optional.
2001-02-21 GDR Noted fix.
|8858||closed||2001-02-21 19:00:39||Gareth Rees||Merged branch/2001-02-21/teamtrack-4507 into version 1.0 (no changes were actually made, but this merge records the success of the branch).|