After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 666942 - [m-b-p-i] Add length attribute to specify length of replacement
[m-b-p-i] Add length attribute to specify length of replacement
Status: RESOLVED WONTFIX
Product: NetworkManager
Classification: Platform
Component: Mobile broadband
git master
Other Linux
: Normal normal
: ---
Assigned To: Aleksander Morgado
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-12-28 11:15 UTC by Guido Günther
Modified: 2015-02-25 14:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add length attribute to ussd top-up code element. (1.14 KB, patch)
2011-12-28 11:16 UTC, Guido Günther
none Details | Review
Swisscom codes are 14 digits long. (756 bytes, patch)
2011-12-28 11:17 UTC, Guido Günther
none Details | Review

Description Guido Günther 2011-12-28 11:15:30 UTC
Hi,
the attached patch adds a length attribute to the ussd top-up code. This will help GUIs to check if the top-up code has the correct length. The providers I know of seem to use a fixed top-up code length. If not we might need to extend this with a max_len later. Does this look sane?
Comment 1 Guido Günther 2011-12-28 11:16:12 UTC
Created attachment 204282 [details] [review]
Add length attribute to ussd top-up code element.
Comment 2 Guido Günther 2011-12-28 11:17:04 UTC
Created attachment 204283 [details] [review]
Swisscom codes are 14 digits long.
Comment 3 Pavel Simerda 2012-07-25 15:19:07 UTC
This is about:

https://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders/

Dan, who maintains the provider database? Could this be applied/rejected?
Comment 4 Lubomir Rintel 2015-02-10 13:41:57 UTC
Aleksander, it think you'll be able to decide if this makes sense or not (I'm not sure given no support in guis). Please have a look.

Thank you
Comment 5 Aleksander Morgado 2015-02-10 15:17:27 UTC
(In reply to Guido Günther from comment #0)
> Hi,
> the attached patch adds a length attribute to the ussd top-up code. This
> will help GUIs to check if the top-up code has the correct length. The
> providers I know of seem to use a fixed top-up code length. If not we might
> need to extend this with a max_len later. Does this look sane?

I don't think this is worth it. This is just to kind of 'prevalidate' the code before actually sending it to the operator (e.g. so that the UI shows a warning if not enough characters are given). Additional prevalidations could include "digits-only", or "min-length", and so on...

The real validation is anyway done when the CODE (e.g. the one you get from a top-up scratch card) is sent via USSD commands anyway: the code will not work if not all the characters are given, of course.

I'm not really in charge of this module, but I'd wontfix it.
Comment 6 Lubomir Rintel 2015-02-10 15:51:34 UTC
Guido: I'm closing this due to reasons explained by Aleksander. If you disagree, feel free to reopen.

Thank you!
Comment 7 Guido Günther 2015-02-10 16:50:26 UTC
This can be very useful to have some feedback in the gui (like acivating the send button after N digits). Otherwise there 's little way to indicate to the user that he entered enough data. gnome-prepaid-manager would use this (although I've not worked on it for some time).
Comment 8 Aleksander Morgado 2015-02-11 08:29:43 UTC
(In reply to Guido Günther from comment #7)
> This can be very useful to have some feedback in the gui (like acivating the
> send button after N digits). Otherwise there 's little way to indicate to
> the user that he entered enough data. gnome-prepaid-manager would use this
> (although I've not worked on it for some time).

It is useful, but it is totally optional. I mean, the sent CODE will still be validated against the operator systems, and it will either fail or succeed based not only on the length, but also on the CODE content. It just is too much work to maintain such a list for a very little gain...