Task aperti

FairConnect vuole lo stesso valore nel campo del partner commerciale e in quello del partner tecnico: il codice PAD del Service Point. Per tua decisione è una regola provvisoria, quindi ogni campo legge da una variabile se portare il codice del partner o quello della sede (FC_ONEPLATFORM_COMMERCIAL_PARTNER_CODE e FC_ONEPLATFORM_TECHNICAL_PARTNER_CODE). Oggi valgono SERVICE_POINT tutte e due.

In staging OPEN e CLOSE si chiamano senza autenticazione, e il backend lo fa già quando l'URL del token è vuoto. L'URL di staging (http://192.168.122.28:8095) va scritto nella configurazione di stage, con URL del token e client id vuoti.

Per le prove c'è un partner (PR00001762) con un Service Point (SP00006829) che ha a magazzino 4 SafeDrive e 1 SecureDrive. FairConnect chiede se deve essere lei a pubblicare quei dati sulle code Kafka.

Il webhook d'esito è il punto aperto. FairConnect non vuole la callback sotto /auth/** del BFF e la vuole esposta dal backend. Propone anche che l'esito arrivi nel corpo della callback, senza rileggerlo con la GET. Se n'è parlato nell'incontro del 30 settembre, ma il file del task non ne riporta ancora l'esito.

Su stage e produzione il corredo va caricato a mano dalle maschere di amministrazione, perché lì i dati di esempio non vengono applicati.

Lo stesso vale per le imposte. Negli altri ambienti la tabella delle aliquote parte vuota, e senza aliquota nessun premio porta l'imposta, senza che nulla lo segnali. In ogni ambiente nuovo, prima del primo preventivo, servono due passi dalle maschere. Il primo è inserire l'aliquota del ramo furto e incendio, cioè il 12,50% più l'1,00% di addizionale. Il secondo è classificare in quel ramo i quattro pacchetti Covéa e le tre garanzie VAN.

I tre PDF contrattuali non stanno nel repository: vanno ricopiati a mano su ogni ambiente nuovo.

Le anagrafiche del primo rilascio (partner, sedi e venditori) non esistono ancora. Non si inseriscono da noi: arrivano dalla sincronizzazione con PAD.

Lo storico e il blocco della vendita ci sono già. Manca la terza fase: la mail che avvisa quando la formazione sta per scadere. Il piano è scritto, ma non c'è ancora una riga di codice. Serve anche il nome dell'evento e del modello di mail, che deve darci FairConnect.

Non è mai partita la parte sull'informativa precontrattuale, che deve riportare da sola il codice RUI, la sezione e la data di iscrizione del venditore.

Prima di chiudere il task restano due verifiche: che su stage e produzione i dati dei venditori siano quelli attesi al rilascio, e una prova completa in locale partendo dai dati.

Quando l'immagine nuova gira in stage, si tolgono dalla configurazione il vecchio host e la vecchia porta.

Infine va misurato in stage se il timeout di 2 secondi basta con la latenza vera della VPN.

Il blocco dell'amministratore backoffice, consegnato il 30 settembre, ha 101 casi in undici aree, tutti eseguiti in locale. Durante la verifica sono stati corretti otto difetti, fra cui un errore 500 nell'Audit preventivi e la paginazione rimasta in inglese.

La prima decisione: se serve un blocco anche per l'operatore backoffice. Ha un menu diverso dall'amministratore (vede Preventivi, Polizze, Questionari, Configurazione, Documenti e Impostazioni, ma non Partner, Sedi, Segnalatori e Operatori), quindi oggi non è coperto.

La seconda: che cosa fare di undici rilievi del backoffice emersi durante le prove. I più pesanti sono tre. L'email di un operatore eliminato non si può riusare. Un partner può avere un solo venditore iscritto al RUI, contro la regola che dà a ogni venditore la propria iscrizione. In vendita del solo dispositivo la dashboard segnala come bloccanti situazioni che non bloccano nulla. L'elenco completo è nel file del task.