maemo.org Bugzilla – Full Text Bug Listing
|Summary:||USSD codes are not recognized in chat|
|Product:||[Maemo Official Applications] Chat & Call & SMS||Reporter:||Attila Csipa <attila.csipa>|
|Status:||RESOLVED FIXED||QA Contact:||im-chat-bugs|
|Priority:||Low||CC:||andre_klapper, mikhail.zabaluev, quim.gil|
SOFTWARE VERSION: Maemo 5, 1.2009.41-10 EXACT STEPS LEADING TO PROBLEM: Receive a message referring to a USSD code (*123*45# like), mostly in automated messages from operators. Click/save code. EXPECTED OUTCOME: Initiate request or add to contacts ACTUAL OUTCOME: Only a fragment of the code is detected/highlighted. A USSD code of *121*2# appears as '121' REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: This is obviously linked to https://bugs.maemo.org/show_bug.cgi?id=5357 but since it is already assigned, it would be nice to handle this problem in conjunction with that. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168pre) Gecko/20090916 Ubuntu/8.04 (hardy) Shiretoko/3.5.4pre
Bug filed in internal bugzilla
Also, please update to 1.2009.42-11. 1.2009.41-10 is outdated.
(I don't work on this product, but I'm curious.) I'm assuming that USSDs can be dangerous and that users are unlikely to understand what they do. (please correct me if i'm wrong) Do you expect these to work from a google chat / skype chat, or only from an sms view? if only from an sms view, should they work from any sender or only senders w/ 4/5 digit numbers?
As for dangerous, IMO it as dangerous as any other 'regular' number, as those can harbor high fee or automated services, too. A confirmation of "This is a supplementary service call number. Are you sure ?" or sorts would be IMHO enough of a warning, but I guess it's more of a policy question. Skype/XMPP is an interesting angle - those are not related to your cellular provider, so it makes far less sense to parse them there (who would send you USSD codes ? friends ?), so, apart from the reason of consistency, it makes sense to draw a line there (however, I would suggest ignoring the whole code in that case, not treat it as partial numbers as now). I don't have enough info to say whether 4/5 sender is a good filtration or not (i.e. Can it be forged ? Are there providers who define a longer (or missing) sender ?)
This has been fixed in package rtcom-messaging-ui 1.2.11-2+0m5 which is part of the internal build version 2009.52-9 (Note: 2009/2010 is the year, and the number after is the week.) *#1234# and +440000000000*56 are properly highlighted. A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).