View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005859 | Taler | merchant backoffice SPA | public | 2019-08-28 22:41 | 2021-08-24 16:23 |
| Reporter | Florian Dold | Assigned To | sebasjm | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.8 | ||||
| Summary | 0005859: back office lacks in user experience and functionality | ||||
| Description | Currently it is not really clear at all what the back office does from just looking at it. It also doesn't do basic stuff like show the contents of contract terms. | ||||
| Tags | No tags attached. | ||||
| has duplicate | 0006586 | closed | Christian Grothoff | Implement back-office only in UI + merchant backend API. |
|
|
The goal here should be to create a stateless frontend for the merchant's backend similar to what exists for LibEuFin. |
|
|
We now have a design document for the UI: https://docs.taler.net/design-documents/014-merchant-backoffice-ui.html |
|
|
I pushed a initial version with preactjs, swr and unfetch as runtime dependencies. * swr is a elegant way to transform async fetching into hook domain with nice features. MIT license * axios, since is being used in the wallet * preact, a light version of react. MIT license as dev tool dependencies being use: * bulma: its some sass templates to build custom css to use with components. its architecture lets use variables, imports and lot of functionality from sass with the final product being a simple css import. Mit license * typescript, off course * jest, enzyme: for unit testing. MIT License both * storybook: really good for visual testing, it help rendering a component in a particular state using stories (similar a unit tests). MIT license About the decision of bulma and preact: I was initial looking into a full reactjs and https://material-ui.com/ . I familiar with MaterialUI since I used previous projects. Is complex, complete and with a lot of option for different use cases. For this project, as far I know about the long term objective, having a light client with good web performance is being preferred instead of a more complex and heavier jack-of-all-trade library. Also the ability of hack the UI look and feel with old school css I think is more suitable for Taler, rather than a css-using-javascript (https://cssinjs.org/?v=v10.5.1) or server-side-rendering. That being said, the discussion is open if any of my assumptions were not the best. Css template were copied from https://github.com/vikdiesel/admin-one-vue-bulma-dashboard, they are under MIT license |
|
|
0005859:0017512: I agree with your analysis so far, nothing sounds unreasonable (alas, I'm not the expert in what might be the best tools for some of these). |
|
|
Looks all good to me! |
|
|
I get error for DELETE http method calling the merchant so I will add Access-Control-Allow-Methods: * This will impact into TALER_MHD_reply_cors_preflight into the exchange source code Is there a validation of min and max in the delay of default_pay_delay and default_wire_transfer_delay fields ? Where can I get the stringo format of payto_uris field? |
|
|
CORS: OK. There are no minimum/maximum ranges for the delays. RFC 8905 specifies the payto:// format. |
|
|
I have pushed a working version (rev 71ecdb3), it should be used with merchant compiled using the latest exchange for the DELETE to work (rev 7adf9f17) I will be working on documentation, testing, refactoring some parts. Right now the login is pretty basic, ask for a token when gets 401 and saves it into localStorage for every request until logout. I will be reading the design documents to get the details and expect some question about it. Any feedback will be appreciated |
|
|
Great, please just get started with the documentation, in particular how to run it. That'll help us provide you with feedback ;-). |
|
|
Right, README.md should clear. I have pushed some more information into revision cfc7555. (system requirements, environment, installation) If any more need, please let me know. |
|
|
Last version pushed have internationalization implemented (rev 5010f9a) For anyone that want to check/develop the look and feel but doesnt have a taler merchant running, using `yarn storybook` is the way to go |
|
|
Testing merchant backend found that 1.- "Max wire fee" overrides "Max deposit fee", should be fixed in the backend. 2.- Duration fields have minimum, it seems that the server expects al last 000 in the format. Is this expected or should be fixed in the backend? 3.- There were some random seg faults in the merchant. |
|
|
1: thanks for the report, when exactly does this happen? Should be trivial to fix. 2: Hmm. We do have a round-time requirement, but I thought that didn't apply to the JSON transmissions. Will need to check with Florian. 3: For segfaults, please try to always provide either: gdb stack trace, valgrind crash report, or a way to reproduce. If you don't know how, ask and I'll explain tonight. |
|
|
1.- Yes, it was. Fix in merchant rev 79653dff 2.- Ok, I will fix the frontend meanwhile. 3.- Ok, yes I know how but was not my focus. If I manage to reproduce it I will send more info. |
|
|
Pushed another version (d37369b) with these changes [1], the list of next steps are in the TODO file at the root of the project. I tried running it against https://backend.demo.taler.net/private/instances but still getting connection errors. I see that the OPTION request return 401 if it doesnt have the "Authorization:" header. [1] * take the url where the spa was loaded as a default backend url * let the user change the backend url when ask for the auth token * button of the form to the right * refactor the popup to be a page * add supported currency for Amount fields (like taler bank) * rename name to business name * change auth field to have a checkbox that activate the validation and show an input to set the token * rename PayTo URI to bank account * change id input to reflect that is going to be use in the url (prepend the backend url as a non editable and put the input after) * refactor create page * add the information popup into the fields to help with the description (like https://b2b.dab-bank.de/smartbroker/) * take default lang from the browser for localization * take the currency from merchant-backend |
|
|
Suppose the following scenario * merchant-backend has a default secret for management that allows lists instances (GET /private/instances) and create new ones (POST /private/instances) * user create a new instance id ABC with auth token SECRET * request to update (PATCH /private/instance/ABC) or query (GET /private/instance/ABC) must now go with the secret Bearer secret-token:SECRET should the user be prompted for new auth token whenever it needs? (bad experience) should the user be asked for multiple token and map them with the instance? should the backend allow the secret from the default instance to query and update instances? |
|
|
modifying payto_uri doesnt work as expected, see https://bugs.gnunet.org/view.php?id=6755 |
|
|
About 0005859:0017540 : My feelings are pretty strong that the ideal result would be this: - I would store the backend URL + SECRET in the local storage, possibly all combinations known to the frontend. So once I logged into an instance, I don't have to type the password again, even if I switched instances and logged into another one. - HOWEVER, on logout, _all_ of them should be cleared, not only the instance the user is currently logged into. - IMO the default instance secret should ONLY be for the default instance, and must not be used to gain access to other instances (other than by resetting the other instance's secret, which is somewhat visible to the 'victim' who's control got usurped). |
|
|
ACK I was assuming 1 backend url with just 1 token to be configured. Now if the current endpoint ends it /private/instances/<id> and it gets a 401, ask for a token and save it in localstorage with BACKEND_KEY-<id> On logout, remove BACKEND_KEY and search of every localStorage key with pattern BACKEND_KEY-<id> |
|
|
sebasjm: I think we should consider this bug resolved, and for other 'details' that might be missing open new 'small' bugs. |
|
|
agree |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-08-28 22:41 | Florian Dold | New Issue | |
| 2019-09-16 09:29 | Christian Grothoff | Severity | minor => feature |
| 2020-08-28 23:57 | Christian Grothoff | Assigned To | => tanhengyeow |
| 2020-08-28 23:57 | Christian Grothoff | Status | new => assigned |
| 2020-08-28 23:58 | Christian Grothoff | Note Added: 0016792 | |
| 2020-10-11 21:15 | Christian Grothoff | Target Version | => 0.9 |
| 2020-10-11 21:15 | Christian Grothoff | Relationship added | has duplicate 0006586 |
| 2021-02-01 12:37 | Florian Dold | Assigned To | tanhengyeow => |
| 2021-02-01 12:38 | Florian Dold | Note Added: 0017483 | |
| 2021-02-03 23:40 | Christian Grothoff | Assigned To | => sebasjm |
| 2021-02-08 16:05 | sebasjm | Note Added: 0017512 | |
| 2021-02-08 17:16 | Christian Grothoff | Note Added: 0017513 | |
| 2021-02-08 17:41 | Florian Dold | Note Added: 0017514 | |
| 2021-02-10 18:07 | sebasjm | Note Added: 0017516 | |
| 2021-02-10 20:15 | Christian Grothoff | Note Added: 0017517 | |
| 2021-02-10 21:35 | sebasjm | Note Added: 0017518 | |
| 2021-02-10 21:41 | Christian Grothoff | Note Added: 0017519 | |
| 2021-02-11 13:47 | sebasjm | Note Added: 0017520 | |
| 2021-02-11 23:31 | sebasjm | Note Added: 0017521 | |
| 2021-02-12 06:42 | sebasjm | Note Added: 0017522 | |
| 2021-02-12 11:10 | Christian Grothoff | Note Added: 0017523 | |
| 2021-02-12 15:33 | sebasjm | Note Added: 0017525 | |
| 2021-02-17 14:40 | sebasjm | Note Added: 0017539 | |
| 2021-02-17 19:34 | sebasjm | Note Added: 0017540 | |
| 2021-02-17 20:07 | sebasjm | Note Added: 0017541 | |
| 2021-02-17 21:10 | Christian Grothoff | Note Added: 0017544 | |
| 2021-02-17 22:12 | sebasjm | Note Added: 0017546 | |
| 2021-08-01 12:23 | Christian Grothoff | Note Added: 0018043 | |
| 2021-08-01 12:23 | Christian Grothoff | Product Version | => git (master) |
| 2021-08-01 12:23 | Christian Grothoff | Target Version | 0.9 => 0.8 |
| 2021-08-01 15:13 | Christian Grothoff | Category | other => merchant backoffice SPA |
| 2021-08-02 16:47 | sebasjm | Status | assigned => resolved |
| 2021-08-02 16:47 | sebasjm | Resolution | open => fixed |
| 2021-08-02 16:47 | sebasjm | Note Added: 0018051 | |
| 2021-08-24 16:23 | Christian Grothoff | Status | resolved => closed |
