Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?
Self-hosted
If you are self-hosting, what version of Baserow are you running?
version 2.3.3
If you are self-hosting, which installation method do you use to run Baserow?
Docker version 29.6.2, build dfc4efb
What are the exact steps to reproduce this issue?
The phone field doesn’t format or validate as expected.
Formatting: The documentation says “It formats the string of numbers into a standardized, readable format (e.g., +1 (555) 123-4567).” No formatting seems to actually happen in practice. Whatever I enter stays exactly as I entered it. I’ve tried 5556666, 4445556666, 14445556666, and +14445556666. None display any differently than entered.
Validation: The documentation says “It automatically checks that the entered value is a plausible phone number, preventing simple data entry errors.” As far as I can tell, validation only ensures no letters and some special characters are entered. I can enter any number of digits (I tried 1 digit and 60 digits) and it’s accepted as is. When I click it, it provides a tel: link with exactly the digits entered.
I’ve tested on my local Docker instance as well as in the cloud at baserow.io. I’ve also tested in both Firefox and Chrome. I couldn’t find any reported bugs and ChatGPT is stumped too.
Validates that the value contains only supported characters (0-9 , + , ( , ) , - , spaces, # , * , N , and X ), with a maximum length of 100 characters.
Renders the value as a clickable tel: link.
It doesn’t automatically format, standardize, or verify phone numbers. Thanks again for helping us improve the docs!
Thank you for the reply. I’m glad the docs now align with the operation of the field in practice. Any chance we might get the ability to enforce a particular format? It would be useful to specify a desired display format when creating/editing the field.
Hey @KG5000, I discussed this with the team. We don’t plan to change the Phone number field itself, but we understand your use case and think a more flexible solution could work better.
For example, we could introduce input masks that let users define a specific format for a field, either through advanced settings or as a separate field type. This would also be useful for other types of data, not just phone numbers.
I’m not sure how masks would work in practice. I’d have to see it, but it could possibly be a good solution. My original suggestion of specifying formatting in the field settings seems more intuitive in my mind. Much like the “format cells” function in Excel. You have the option of selecting a number of different preset formats or you can create a custom format. Something like that for the phone field would follow convention and be obvious to the builder of the table. But maybe the masks idea would be just as useful. I wouldn’t know until I try it.
