|
|
this can be checked as solved, but i will need more context to know if it is good enough:
* do we want a UI to allow the officer go throught all the cases?
right now the officer can
1) create a custom measure
2) link a form or SKIP to the measure
3) select the program
4) change the context
the measure is relative to the decision (so for a new decision it will need to make all the steps again to configure the same measure)
the measure, once configured in the decision wizard, it can be referenced as "active measure", "expiration measure" or "rule measure"
I'm sure that this configuration can set all kind of possible custom measure but I'm not sure about the specifics of this use case so it may be good to have a way to test just to be sure that the current impl is not too much complicated for this use cases that you provided |
|
|
|
My problem is that this is a bit too difficult for some of the common cases, specifically address (postal, sms, email) validation and showing "arbitrary" messages via "info" measures to the customer. Those should be *easy* to do as one-offs, and not require complex steps like above. I don't yet have a *good* design for this, but what I'm basically asking is for an easy way to specify *certain* measures (and maybe we literally hard-code them for TOPS and/or other setups!) with custom context (where the SPA even understands (!) the context and its fields). So something where I can pick a new measure "check postal address" and it then asks me to enter name + address, or new measure "show message to customer" and I can enter some free-form text. These are simply too common to be complicated. |
|
|
|
ACK, then lets create son convention over the name which I think is something we can use to signal from the server, where the configuration of the program is, and the client SPA.
I propose using the start of the measure name to signal the SPA what the measure is about and then the SPA renders some specific logic, we can add this to the documentation of the server to implement. So for example measure that starts with `verify_email_*` , `verify_phone_*`, `verify_postal_*` and `verify_postal-ch_*` then server should:
- have a program that redirect to the challenger
- receive address_type in the conext, values could be "email" | "phone" | "postal" | "postal-ch"; https://docs.taler.net/core/api-challenger.html#get--config
- receive "read_only" which signal if the customer can change the address or not
- receive fields listed on the `challenger/config` endpoint to set the default value in the form
and client should:
- show custom form relative to the address_type (to make this more simple) (address_type is defined by the server measure name)
- search in the attributes of the current decision if there is a GANA field related to the `address_type`, the allow the officer to select THAT address
- if unselected it will allow customer to specify one
- if selected it should show a read_only toggle |
|
|
|
I guess we could do this with certain "magic" prefixes. Just needs to be documented -- and Ideally use values already used by the TOPS deployment, because changing anything has shown to result in bugs... |
|
