You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the demo data there are some phone extensions that are, for example, Ext. 4385 and others that are x42. The delimiter (Ext. or x) should be stripped out of the data so that field only contains the extension number. The client can then set a delimiter so it's consistent in presentation across all entries. If a customized delimiter is needed (though I don't see why this would be necessary) that can be a setting in https://github.com/codeforamerica/ohana-web-search/blob/master/config/settings.yml
The text was updated successfully, but these errors were encountered:
This is an Open Referral data standard issue. v0.2 of the spec currently does not specify the formatting of the extension field. If you think the extension field should only contain a number (I think that's probably a good idea), then please add a comment to the spec. Once the spec is finalized, I will update the API to enforce that rule.
On the other hand, if the spec does not enforce a digit-only rule, then the API should not alter the data that is stored in the database. It would then be up to the client to format the data to suit its needs.
So, since this is not a bug in the API code, I will close this issue.
In the demo data there are some phone extensions that are, for example,
Ext. 4385
and others that arex42
. The delimiter (Ext.
orx
) should be stripped out of the data so that field only contains the extension number. The client can then set a delimiter so it's consistent in presentation across all entries. If a customized delimiter is needed (though I don't see why this would be necessary) that can be a setting in https://github.com/codeforamerica/ohana-web-search/blob/master/config/settings.ymlThe text was updated successfully, but these errors were encountered: