[19101] in Athena Bugs
chfn enforces non-standard phone number format
daemon@ATHENA.MIT.EDU (John Hawkinson)
Tue Jul 24 13:19:42 2001
Date: Tue, 24 Jul 2001 13:19:40 -0400 (EDT)
Message-Id: <200107241719.NAA28830@multics.mit.edu>
To: bug-moira@mit.edu
cc: bugs@mit.edu
From: John Hawkinson <jhawk@MIT.EDU>
Hi.
The "chfn" client seems to enforce a phone number format
requirement:
| [coleco-sidewinder!jhawk] ~> chfn
| ...
| Home phone number (Ex: 3141592) [+1 781 262 3180]: +1 617 699 0524
| Phone numbers can contain only digits.
Generally in the past I've gotten around this by using another client,
like mrtest.
But really, I don't think the restriction has a good place there.
The standard ISO phone number format is the one I prefer to use,
and it includes a + to signify the country code.
I don't think there's any strong requirement for data validation of
the moira field. In a perfect world, perhaps MITDIR might be updated
from moira, but I don't think that's a good reason to reject
non-fully-numeric strings.
Is there a good reason to not rip out lines 224-252 of
moira/clients/chfn/chfn.c?
In another bit of irony, the office phone field is much shorter
than the home phone field--I can fit a full phone number in the
latter, but in the former, I must remove spaces. is there
any reason not to bump up the office_phone to 16?
[coleco-sidewinder!jhawk] ~moiradev/src/db> grep hone schema.sql
home_phone VARCHAR(16) DEFAULT CHR(0) NOT NULL,
office_phone VARCHAR(12) DEFAULT CHR(0) NOT NULL,
xphone1 VARCHAR(12) DEFAULT CHR(0) NOT NULL,
xphone2 VARCHAR(12) DEFAULT CHR(0) NOT NULL,
Though, thinking about it, it seems like it would be optimal for the
field to be a little larger anyhow, to accomodate 3-digit country codes:
0 1 2
12345678901234567890
+999 617 253 7788
it seems like 20 digits would be a good number, safely keeping space
for countries with really long phone numbers, etc.
Thanks.
--jhawk
p.s.: Am I screwing myself somehow with the + in my phone numbers?
