| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009612 | Taler | merchant backend | public | 2025-03-12 15:28 | 2025-05-10 02:11 |
| Reporter | Dana Dram | Assigned To | sebasjm | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.14 | ||||
| Target Version | 1.0 | Fixed in Version | 1.0 | ||
| Summary | 0009612: Address setup has a lot of fields that are not necessary | ||||
| Description | In the Settings menu, under the Address section (also applicable to the Jurisdiction section), the form currently includes multiple fields for entering address details, such as "Address," "Building," "Building Number," "Street," and "Postal Code." This results in a lengthy and cumbersome form that requires users to fill out numerous fields, leading to potential frustration and a slower input process. To improve usability, two potential solutions are proposed: - Consolidate Address Fields: Simplify the address setup process by merging all these fields into a single "Address" field. The consolidated field would include a placeholder or hint text (e.g., "Enter your full address: Street, Building Name, Building Number, Postal Code") to guide users on how to format their input. This approach would make the form shorter, more user-friendly, and quicker to complete. - Remove the Address Field: Alternatively, remove the general "Address" field and retain only the other specific fields (e.g., "Building Name",” Building Number”, "Street", "Postal Code"). This option would reduce redundancy while still capturing detailed address information. | ||||
| Additional Information | Also applies to the Jurisdiction section. | ||||
| Tags | No tags attached. | ||||
| I *think* this might be a case of a bad label. I *think* that the "address" line you are talking about is intended for things like c/o addresses and other "complications". The problem we have is that *sometimes* some APIs require *structured* address data, so they want the street/city/district/country to be explicitly marked, and extracting that from one "big" free-form address field is, well, hard to automate. So I don't think we should go down that route. But of course you are right, the current layout suggests to most users to enter their address twice, which is equally wrong. Sebastian: am I right the "address" is actually translated into "additional address lines", like for c/o? Would it be reasonable to rename the label to "c/o" or something equivalent? Please propose a fix that matches what the code does... | |
| No sure what the definition of `c/o addresses` is but this is mapped to the field `address_lines` here https://docs.taler.net/core/api-merchant.html#tsref-type-Location. I will change the label and move it to the bottom image.png (55,489 bytes) | |
| 93673f197..e5a4f2bcc | |