Open brad2014 opened 5 years ago
GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/4114 (Allow ordering of user lists), https://github.com/nextcloud/server/issues/3250 (Allow OCS edit user endpoint to edit all user data fields), https://github.com/nextcloud/server/issues/5931 (Address fields missing from contact), https://github.com/nextcloud/server/issues/5542 (Provisioning API: Add email field and allow empty password on user creation), and https://github.com/nextcloud/server/issues/7175 (Allow to search for email address in user management).
Is this Issue still valid in NC21.0.2? If not, please close this issue. Thanks! :)
The presentation order of address elements on the contact detail pane is still upside down for US users, who expect "City, State Zip\nCountry" instead of "PostalCode city\nProvince\nCountry".
Setting the order of fields for addresses in the US. Note that the order of fields depends on the country of the contact address, not the locale of the user.
I'll add, for google-fu, the Thunderbird add-no Cardbook by Philippe Vigneau (https://gitlab.com/CardBook/CardBook) implements a preferences setting for custom address field formatting that can controlled by the value of fields (e.g. format country=US this way, format all others that way). Maybe there is some inspiration there.
That said, this seems like a low priority, unless someone is really hot to work on it...
I'll also note that autocomplete for addresses in the "new event" location field is apparently not implemented (I don't know if it was taken out, or it was never there, or its just broken for me).
Feature request: Allow customization of the presentation order of fields of addresses
The order of elements in the ADR field of a vCard is fixed by RFC 6350, but the order of fields in a written postal address varies by locality. For example, many european countries (e.g. FR, DE) place the postal code before the city name (U.S. and vCard standard is to place the postal code after the state/province). (See UPU standard S42 for the gory specifics).
Example:
vs
The RFC allows a properly presented postal address to be included in the ADR. LABEL:
If the contact list and calendar don't need the individual ADR components, it would be preferable to let the user type in a freeform text label when entering a contact address, and do away with the individual components altogether.
For comparison: I think contact lists like Google Contacts parse user-provided address text in a sophisticated way to extract the components, but NextCloud may be able to just leave them blank. Roundcube lets the sysadmin configure an HTML template (e.g. for Europe,
'{street}<br/>{locality} {zipcode}<br/>{country} {region}'
) into which fields get stuffed, and adjusts the order of the input fields to match the order of the fields in the template. Of course that approach is broken when the user wants to enter an address for a country that uses an address template different from that in the system template.This issue affects data entry and presentation of contacts on the contact detail page, and also the autocompletion of nextcloud calendar event locations, and the presentation in IMip invite email. (There may be other places postal addresses are presented).
This was brought up and discussed previously in nextcloud/calendar#933.