| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009736 | Taler | exchange AML backoffice (SPA) | public | 2025-04-15 16:44 | 2025-06-12 22:29 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | ||
| Priority | urgent | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.0 stretch goals | Fixed in Version | 1.0 stretch goals | ||
| Summary | 0009736: Design change (?): need to be able to provide context when adding measure (est 8h - due date 6/6) | ||||
| Description | When an AML officer requests an address validation, we have three cases: 1) the AML officer needs a *specific* address to be validated (read_only:true) 2) the AML officer needs an address to be validated, but the customer might correct it and validate another (read-write), and 3) the customer can enter any address freely. right now, the SPA only allows picking measures from the pre-defined list, and adding a new measure to that list just to provide the specific address of that customer seems wrong. So clearly we *should* allow a context to be provided or edited (!) for the respective measure in this dialog. | ||||
| Tags | compliance | ||||
|
|
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... |
|
|
After some testing i will change the approach, I'm using the context instead of the measure name Example reference [kyc-measure-verify-link] CHECK_NAME = askEmail CONTEXT = {"domain":"taler.net","measure-type":"verify","challenge-type":"email"} PROGRAM = validEmailDomain VOLUNTARY = NO [kyc-measure-correct-link] CHECK_NAME = askEmail CONTEXT = {"domain":"taler.net","measure-type":"correct","challenge-type":"email"} PROGRAM = validEmailDomain VOLUNTARY = NO [kyc-measure-specify-link] CHECK_NAME = askEmail CONTEXT = {"domain":"taler.net","measure-type":"specify","challenge-type":"email"} PROGRAM = validEmailDomain VOLUNTARY = NO I will be updating the docs and the spec in the ansible configuration |
|
|
The Exchange KYC operator: ``` Using the OAuth 2.0 logic with the /setup endpoint it is possible to pass Challenger the address to validate via the context of the KYC check. To do so, the address type specific address data must be provided in a field initial_address of the context object. ``` So we can use the measure as a template and from the aml used the initial_address to create the 3 cases. We still need the challenge-type in the measure context to signal the SPA that this measure can be used as template (And the check will effectively be used to validate/correct the address type) |
|
|
When the measure have context key "challenge-type" with value "email" or "phone" or "postal" then the SPA will have a special UI that simplify the setup. 1) When selecting the active measure: * a new button is shown this will open the measure edition to create a custom measure with new values. 2) When editing a measure: * The form is simplified, check and program fields are removed and the officer can only edit the context * Read only is shown as a flag * The input fields correspond to the challenge type * The form can be switched to the normal one Tested with challenger image.png (24,327 bytes) image-2.png (24,327 bytes) |
|
|
effe8b919..cbf261e2b |
