Several telephone numbers per account: one primary, unique across the instance

tiagoagueda commented

2026-09-07 14:42:55 +00:00

Owner

Observation

allow a user having multiple phone numbers, but all of them have to be platform wise
unique and one have to be defined as primary, as it happens with e-mails

What exists

Profile.phone is a single CharField, stored in international form (+33612345678) by
the PhoneField in core/phone_field.py. One number, no uniqueness, no primary.

Email addresses already work the way this asks: allauth's EmailAddress gives an account
several, exactly one primary, each verified independently, and unique across the
instance. So there is a shape to copy, and its edges are already known.

What this asks for

A PhoneNumber model owned by a person, with:

several per account, added and removed like email addresses;
exactly one primary, and the invariant enforced where it cannot be dodged rather
than in a form — a database constraint plus the service that sets it;
unique across the instance, on the normalised international form, so that two
accounts cannot both claim +351912345678.

The three things to decide before writing any of it

1. Instance-wide uniqueness is a disclosure. It is worth being explicit, because the
project's first commitment is that one person's data never reaches another's. If a number
must be unique across the instance, then "this number is already in use" tells whoever
typed it that somebody else on this server has it -- which is a real fact about another
account, leaked to anybody who can add a number. Email has the same property and allauth
answers it in a specific way; whatever is done here should be a deliberate choice with the
same care, not an inherited default. Options: refuse with a vague message, refuse plainly,
or take it silently and let an administrator resolve the collision. This needs deciding
first because it shapes the constraint, the form and the tests.

2. Uniqueness of what, exactly. +351912345678 and 00351912345678 and
+351 912 345 678 are one number written three ways, and only the stored international
form is comparable. Postulo deliberately keeps an unparseable number exactly as typed
(phones.py says so, and means it: refusing to save it would be the worst outcome). So a
number that could not be parsed has no normalised form, and cannot participate in a
uniqueness constraint at all. The rule probably has to be: unique among numbers that
parsed, ignored for those that did not.

3. Verification, or the absence of it. An email address is unique and verified, and
the verification is what makes uniqueness meaningful -- otherwise anybody can squat any
address. Postulo cannot send an SMS and should not start; that is an outbound channel, a
cost and a dependency the project does not have. So these numbers will be unique but
unverified, which means the first account to type a number owns it. Worth stating in the
interface rather than discovering.

Scope

PhoneNumber model, owner-scoped like everything else, with the primary constraint.
A migration that moves the existing Profile.phone into the first row and makes it
primary, losing nothing.
Settings -> Your details grows an add/remove/make-primary list, the way email addresses
already have one.
The primary number is what a CV and a cover letter render, so nothing downstream needs
to know there are several.
tests/security/ gets the ownership sweep, since this is a new table holding a personal
detail.

Classification

Enhancement. Not breaking for anybody's data -- the migration carries the existing number
across -- but it changes a documented model field, so the wiki and the API schema move
with it.

## Observation > allow a user having multiple phone numbers, but all of them have to be platform wise > unique and one have to be defined as primary, as it happens with e-mails ## What exists `Profile.phone` is a single `CharField`, stored in international form (`+33612345678`) by the `PhoneField` in `core/phone_field.py`. One number, no uniqueness, no primary. Email addresses already work the way this asks: allauth's `EmailAddress` gives an account several, exactly one `primary`, each `verified` independently, and unique across the instance. So there is a shape to copy, and its edges are already known. ## What this asks for A `PhoneNumber` model owned by a person, with: - **several per account**, added and removed like email addresses; - **exactly one primary**, and the invariant enforced where it cannot be dodged rather than in a form — a database constraint plus the service that sets it; - **unique across the instance**, on the normalised international form, so that two accounts cannot both claim `+351912345678`. ## The three things to decide before writing any of it **1. Instance-wide uniqueness is a disclosure.** It is worth being explicit, because the project's first commitment is that one person's data never reaches another's. If a number must be unique across the instance, then "this number is already in use" tells whoever typed it that *somebody else on this server has it* -- which is a real fact about another account, leaked to anybody who can add a number. Email has the same property and allauth answers it in a specific way; whatever is done here should be a deliberate choice with the same care, not an inherited default. Options: refuse with a vague message, refuse plainly, or take it silently and let an administrator resolve the collision. This needs deciding first because it shapes the constraint, the form and the tests. **2. Uniqueness of what, exactly.** `+351912345678` and `00351912345678` and `+351 912 345 678` are one number written three ways, and only the stored international form is comparable. Postulo deliberately keeps an unparseable number exactly as typed (`phones.py` says so, and means it: refusing to save it would be the worst outcome). So a number that could not be parsed has no normalised form, and cannot participate in a uniqueness constraint at all. The rule probably has to be: unique among numbers that parsed, ignored for those that did not. **3. Verification, or the absence of it.** An email address is unique *and verified*, and the verification is what makes uniqueness meaningful -- otherwise anybody can squat any address. Postulo cannot send an SMS and should not start; that is an outbound channel, a cost and a dependency the project does not have. So these numbers will be unique but unverified, which means the first account to type a number owns it. Worth stating in the interface rather than discovering. ## Scope - `PhoneNumber` model, owner-scoped like everything else, with the primary constraint. - A migration that moves the existing `Profile.phone` into the first row and makes it primary, losing nothing. - Settings -> Your details grows an add/remove/make-primary list, the way email addresses already have one. - The primary number is what a CV and a cover letter render, so nothing downstream needs to know there are several. - `tests/security/` gets the ownership sweep, since this is a new table holding a personal detail. ## Classification Enhancement. Not breaking for anybody's data -- the migration carries the existing number across -- but it changes a documented model field, so the wiki and the API schema move with it.

tiagoagueda added this to the 0.3.0 milestone

2026-09-07 14:42:55 +00:00

tiagoagueda added the

enhancement

tier

2

labels