View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010581 | Taler | merchant backoffice SPA | public | 2025-11-10 23:43 | 2025-11-16 21:27 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | ||
| Priority | urgent | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 1.0 | ||||
| Target Version | 1.2 | ||||
| Summary | 0010581: Profiles to simplify merchant backend | ||||
| Description | The current menu structure is WAY to complex for merchants, especially as it shows them many options that may not apply to their user type. Please do the following: * rename "Interface" to "Personalization" * under Interface, add a new drop-down setting "Profile" with choices like - Farm shop (Orders, Templates) - Online Point of sale (Orders, inventory, categories) - Offline Point of sale (Orders, inventory, categories, Templates, OTP devices) - Digital publishing (Orders, Templates, soon: Token families) - E-commerce (Orders, Inventory, Webhooks) - Vending machine (Orders, soon: templates with v1) - Expert (all stable, including bank account adding *with* revenue API) - Developer (all) Naturally, we always show "bank accounts" and "access tokens" and --if action is required or in expert/dev mode-- the KYC status. Clemens may (eventually) give you a longer list of profiles and which menu items to enable for each (the above is just a first rough cut), so make sure to make it easy to extend the list. The existing settings "Advanced order creation" becomes part of 'expert', and 'developer mode' is also obsoleted by the above choice. Like the existing other interface settings (language and date format), the new option should be persisted client-side in local storage. | ||||
| Tags | No tags attached. | ||||
| related to | 0010596 | resolved | sebasjm | Taler | Taler Merchant Backend SPA, "KYC status" menu [nice-to-have for target version 1.2] |
| has duplicate | 0010591 | closed | Florian Dold | Taler | Taler Merchant Backend: Profile creation for merchant user groups [nice-to-have for target version 1.2] |
|
|
should we have a default ? Maybe also being able to select the profile on self provision. I suspect that this is going to be saved on local storage? That will be lost if opened from another browser |
|
|
Yes, I know local storage won't be available in another browser. I still think this is the right choice for this setting for now. As for a default, I'm not sure we can safely pick one. Maybe best to ask the user explicitly to provide this (so if the option is not set, show a dialog to ask them what profile they want to use)? |
|
|
Hernâni and me were asked to provide insights from our Merchant Backend testing. We filled in a feature matrix today with our comments and recommendations. Clemens will probably condense the findings and forward them. There are some hints from my side to render to the main menu list a better structure, so better wait for Clemens' summary (if any). Here is one other hint I would like to share now and here when looking at the description above: Farm shop owners would likely be pleased to see the "inventory" option in the main menu as they are often not disposing of an ERP program or inventory management app and could be found of our FLOSS solution (or maybe give up an existing non-free software for inventory management). So better keep the options orders, inventory, templates for farm shops. |
|
|
Well, *today* the inventory management wouldn't work for them, as the QR code templates wouldn't work with the inventory. So that makes no sense. Once Bohdan has finished the templates v2 implementation, I agree: then we should enable the inventory. |
|
|
"Interface" should be renamed to "Personalisation" |
|
|
Stefan: that's already the first bullet point of the description. Please avoid adding noise. |
|
|
British English, please. |
|
|
Spec for this: https://docs.taler.net/design-documents/074-merchant-backend-simplification.html |
|
|
I've elaborated on DD74 some more... |
|
|
i have implemented the first iteration https://docs.taler.net/design-documents/074-merchant-backend-simplification.html#proposed-solution-iteration-1 with vlada and florian feedback at 8c8e80a88 |
|
|
I just build the merchant backend, still get what seems to be the old SPA. Did you update it in merchant.git? |
|
|
Ah, found the change, it defaulted to 'expert' (which it probably should not). Also, you did not change the menu "Interface" to "Personalization". Furthermore, the "Advance order creation" and "Advance instance settings" should both be removed, they become part of the "Expert user". "Token Families" should for now *only* be activated for a "Merchant type" of "Developer". Not sure "Merchant type" is the right term, we had previously discussed other names, but I can live with this if that is the consensus. |
|
|
"In person point of sale." has a period at the end, which should be removed. |
|
|
And finally do install a spell checker, it really cannot be that hard! "venfing machine" must be "vending machine". I also don't know if any of these merchant type names are the ones we agreed. Please do stick to DD74! |
|
|
I've now put quotes in DD74 around the _exact_ strings that should be used in English by the SPA for menus and personalization settings. I hope this is now unambiguous. |
|
|
> Ah, found the change, it defaulted to 'expert' (which it probably should not). default on setting.json was not yet implemented also setting this value on self provision is a good idea. still missing. > Also, you did not change the menu "Interface" to "Personalization". Furthermore, the > "Advance order creation" and "Advance instance settings" should both be removed, they become part of the "Expert user". we said that this was not part of iteration one, but there you go i have implemented this now. The only one that can create orders manually is the "expert user" so i see no reason for the filter on the view (with the filter i mean the advance-order-creation which show/hide some fields) > "Token Families" should for now *only* be activated for a "Merchant type" of "Developer". There is no "developer", only expert mode and is what the profile "developer" is in DD74. After talking with vlada and florian we decided that "developer mode" or "developer" type was wrong since no user will claim to be this type of merchant. No sense at all. We suggested "system administrator" (which may be the view of a person doing the setup). Also developer-mode will still have more options which are not related to merchant API and have no garantee to work or have nice error messages (since developer know this). Here "expert user" (aka developer in dd74) is a user that read every part of the documentation, the power user. |
|
|
Eh, but that's the point: we don't want merchants to claim to be developers, that mode is there to hide features that are experimental/not complete/under development, like token families! We *also* need expert, which should have everything turned on that we consider *stable*. |
|
|
Yeah, we should probably expose some setting in /config as the preferred default to use for new logins. Is there some preferred set of values I should use in the config option? |
|
|
This are the one i'm using now. export type Personas = | "expert" | "offline-vending-machine" | "point-of-sale" | "digital-publishing" | "e-commerce"; > Eh, but that's the point: we don't want merchants to claim to be developers, that mode is there to hide features that are experimental/not complete/under development, like token families! Ok, we should add this definition then. Expert (all stable) vs "developer mode on" (all stable + beta features + custom dev tools). > "Token Families" should for now *only* be activated for a "Merchant type" of "Developer". I will take that as "remove token families from expert since is not stable". |
|
|
/config has a new field "default_persona". Note that I am *also* allowing/documenting "developer" as a valid option. Oh, and default is "expert", so if the SPA does not understand the value, it should default to "expert". |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-11-10 23:43 | Christian Grothoff | New Issue | |
| 2025-11-10 23:43 | Christian Grothoff | Status | new => assigned |
| 2025-11-10 23:43 | Christian Grothoff | Assigned To | => sebasjm |
| 2025-11-11 17:56 | sebasjm | Note Added: 0026385 | |
| 2025-11-11 18:00 | Christian Grothoff | Note Added: 0026386 | |
| 2025-11-11 20:38 | Stefan | Note Added: 0026387 | |
| 2025-11-11 21:05 | Christian Grothoff | Note Added: 0026389 | |
| 2025-11-12 23:13 | Stefan | Note Added: 0026412 | |
| 2025-11-12 23:15 | Christian Grothoff | Note Added: 0026413 | |
| 2025-11-12 23:15 | Stefan | Relationship added | related to 0010591 |
| 2025-11-12 23:20 | Stefan | Note Added: 0026414 | |
| 2025-11-12 23:33 | Stefan | Relationship added | related to 0010596 |
| 2025-11-12 23:44 | Christian Grothoff | Priority | high => urgent |
| 2025-11-12 23:44 | Christian Grothoff | Target Version | 1.5 => 1.2 |
| 2025-11-13 17:25 | Florian Dold | Relationship replaced | has duplicate 0010591 |
| 2025-11-13 17:30 | Florian Dold | Note Added: 0026427 | |
| 2025-11-13 17:39 | Christian Grothoff | Note Added: 0026428 | |
| 2025-11-15 22:24 | sebasjm | Note Added: 0026467 | |
| 2025-11-16 14:36 | Christian Grothoff | Note Added: 0026487 | |
| 2025-11-16 14:38 | Christian Grothoff | Note Added: 0026488 | |
| 2025-11-16 14:39 | Christian Grothoff | Note Added: 0026489 | |
| 2025-11-16 14:41 | Christian Grothoff | Note Added: 0026490 | |
| 2025-11-16 15:01 | Christian Grothoff | Note Added: 0026491 | |
| 2025-11-16 20:48 | sebasjm | Note Added: 0026494 | |
| 2025-11-16 20:50 | Christian Grothoff | Note Added: 0026495 | |
| 2025-11-16 20:52 | Christian Grothoff | Note Added: 0026496 | |
| 2025-11-16 21:06 | sebasjm | Note Added: 0026497 | |
| 2025-11-16 21:27 | Christian Grothoff | Note Added: 0026498 | |
| 2025-11-16 21:27 | Christian Grothoff | Note Edited: 0026498 |
