Psi Jabber Client

See this page for instructions on how to use Flyspray: http://psi-im.org/wiki/Flyspray

Please Note!

Please do not create tasks here without discussing your bug or feature request on the forums or groupchat psi@conference.psi-im.org, *and* getting explicit confirmation by a developer to add it to flyspray.
Tasklist

FS#210 - Commas in contacts' names

Attached to Project: Psi Jabber Client
Opened by Mircea Bardac (IceRAM) - Tuesday, 03 February 2004, 18:49 GMT-4
Last edited by Kevin Smith (kev) - Friday, 16 November 2007, 03:27 GMT-4
Task Type Bug Report
Category UserInterface
Status New
Assigned To Francisco Joaquín Rodríguez Prados (sabaoth)
Operating System All
Severity High
Priority Very Important
Reported Version 0.9.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Commas in contacts' names lead to doubled messages.
Prevent using commas there or fix the behaviour in another way.

Forum topic: http://forum.psi-im.org/thread/1270
This task depends upon

Comment by Maciek Niedzielski (machekku) - Tuesday, 15 March 2005, 08:20 GMT-4
How about Thunderbird-like multiple address fields? Allowing only one address in each field would solve the problem with wrongly interpreted commas.
Moreover, this would be useful when we get Extended Stanza Addressing implemented in Psi.
Comment by Kevin Smith (kev) - Thursday, 17 March 2005, 05:58 GMT-4
<mawis>
I am using the Debian package 0.9.3-1 of Psi and just discovered that when I sent a message to a user, that has the nickname [RFL, 109.3fm] the message window opens and the recipient address is "[RFL, 109.3fm] <user@example.com>"

When I sent the message, Psi sends out to messages, one to [RFL and another to user@example.com.

I think the "," must be escaped before copying it to the message dialog, if this sign is used as a delimiter for specifying multiple recipient addresses.

With this bug, a user might generate nicknams, that cause Psi to send CCs of messages sent to this user to another address.
Comment by Francisco Joaquín Rodríguez Prados (sabaoth) - Sunday, 05 June 2005, 12:12 GMT-4
darcs patch over the mainline 5/6/2005
Comment by Francisco Joaquín Rodríguez Prados (sabaoth) - Sunday, 05 June 2005, 13:00 GMT-4
Done. Now The names are enclosed in double quotation marks (") as they are in the standard e-mail way. Double quotation marks in nicknames are turned into single quotation marks (') when displaying the names in the message dialog, so there are no conflicts.
Comment by Trejkaz (trejkaz) - Friday, 10 June 2005, 09:09 GMT-4
Actually I think the "standard" email way is to quote the string and then replace
"
with
\"
Comment by Francisco Joaquín Rodríguez Prados (sabaoth) - Friday, 10 June 2005, 17:45 GMT-4
I thought the users could think that's some kind of bug, and try to delete the '\'. So turning every " in the name into a ' makes any bad - I guess - and seems more clear to me - even thought the "standard" is escaping the "s...
Comment by Trejkaz (trejkaz) - Friday, 10 June 2005, 22:52 GMT-4
So does this confusion happen in all email clients which already do this?
Comment by Francisco Joaquín Rodríguez Prados (sabaoth) - Saturday, 11 June 2005, 10:21 GMT-4
I don't think so. But in email clients is quite easy to realize when a piece of text which is suposed to be an e-mail address is so or not:

[A-Za-z._-]+@[A-Za-z._-]+.[A-Za-z]+ or whatever format an e-mail address has (I gess it is in the RFC).

In the code there's not such check. I thought of that, but would suppose big changes in the source - such as adding QRegExp - so I thought in that (temporal?) solution which was fast and needed no testing.
Comment by Peter Schwindt (schwindp) - Thursday, 15 November 2007, 13:31 GMT-4
Very good evening.

Since this is a very annoying behaviour of Psi (even in 0.11), will this be fixed in near future? The severity of this bug already is high but unftly noone took care of it for more than 2 years. :-/
Comment by Peter Schwindt (schwindp) - Thursday, 15 November 2007, 13:41 GMT-4
To add more information regarding the bug:

This also occurs on subscription requests. So if you have an incoming request from someone you already added to your roster (and used a comma in the name you assigned to the person), the outgoing subscription ACK will go to two JIDs, the name being split at the first comma :-/

Loading...