[MIG] l10n_it_sct_cbi: Migration to 18.0

[monen17]

Migrazione standard da 16.0 (https://github.com/OCA/l10n-italy/tree/9f74d1d62e6e531c8e513ad27308f9fd9fa0fa01/l10n_it_sct_cbi).

Durante le prove ho notato un typo nella documentazione, è in un commit dedicato perché va back-portato (issue #4919).

È possibile verificare la validità dei file generati su https://www.cbiservice.com/correttoresepa.php, selezionando l'opzione: SCT - CBIBdyPaymentRequest 00.04.01 (new).

Dipende da:

• [18.0][FIX] account_payment_order: Manager can create partner bank accounts bank-payment#1500

[monen17]

/ocabot migration l10n_it_sct_cbi

[Borruso]

LGTM

[eLBati]

Riporto anche qui:

la PR OCA/bank-payment#1500 sembra quindi sbagliata. Il suo stesso test "An Account manager can create partner bank accounts" verifica uno scenario che non deve essere possibile: per creare i conti l'utente deve essere nel gruppo group_account_payment.
Direi quindi che la #4920 va adattata di conseguenza, mettendo l'utente nel gruppo necessario

[monen17]

Riporto anche qui:

la PR OCA/bank-payment#1500 sembra quindi sbagliata. Il suo stesso test "An Account manager can create partner bank accounts" verifica uno scenario che non deve essere possibile: per creare i conti l'utente deve essere nel gruppo group_account_payment. Direi quindi che la #4920 va adattata di conseguenza, mettendo l'utente nel gruppo necessario

Come ho spiegato in OCA/bank-payment#1500, diversi test falliscono semplicemente perché account_payment_order è installato.
Ad esempio in questa PR, senza la modifica di OCA/bank-payment#1500, fallirebbero i test di l10n_it_account_vat_period_end_settlement (https://github.com/OCA/l10n-italy/actions/runs/17929742581/job/50984344296#step:8:424) che non ha nulla a che fare con questa migrazione.

Quindi ho pensato di fare una correzione in quel modulo; se quella non va bene potete proporre soluzioni alternative? Oppure ancora meglio fare una PR al mio branch?
Non credo sia il caso di mettere uno switch per dire "se account_payment_order è installato, allora fai cose diverse", e non mi vengono in mente altre soluzioni accettabili.

[TheMule71]

Riporto anche qui:
la PR OCA/bank-payment#1500 sembra quindi sbagliata. Il suo stesso test "An Account manager can create partner bank accounts" verifica uno scenario che non deve essere possibile: per creare i conti l'utente deve essere nel gruppo group_account_payment. Direi quindi che la #4920 va adattata di conseguenza, mettendo l'utente nel gruppo necessario

Come ho spiegato in OCA/bank-payment#1500, diversi test falliscono semplicemente perché account_payment_order è installato. Ad esempio in questa PR, senza la modifica di OCA/bank-payment#1500, fallirebbero i test di l10n_it_account_vat_period_end_settlement (https://github.com/OCA/l10n-italy/actions/runs/17929742581/job/50984344296#step:8:424) che non ha nulla a che fare con questa migrazione.

Quindi ho pensato di fare una correzione in quel modulo; se quella non va bene potete proporre soluzioni alternative? Oppure ancora meglio fare una PR al mio branch? Non credo sia il caso di mettere uno switch per dire "se account_payment_order è installato, allora fai cose diverse", e non mi vengono in mente altre soluzioni accettabili.

Ho aggunto un mio commento a OCA/bank-payment#1500

Qui una soluzione sarebbe rimettere a posto i permessi del modello che dà problemi, dovrebbe essere uno tra account.model_account_payment account.model_account_payment base.model_res_bank, o magari a tutti e tre. Facendo l'override in ir.model.access.csv.

Sono d'accordo che il bug è in account_payment_order, ma se insistono che hanno ragione...

[monen17]

Ho aggunto un mio commento a OCA/bank-payment#1500

Grazie! Vediamo cosa dicono, magari a te rispondono, ma una review invece? 😁

Qui una soluzione sarebbe rimettere a posto i permessi del modello che dà problemi, dovrebbe essere uno tra account.model_account_payment account.model_account_payment base.model_res_bank, o magari a tutti e tre. Facendo l'override in ir.model.access.csv.

Sì ma in che modulo? Altri moduli del repo che non dipendono da account_payment_order hanno i test che falliscono.
Ho pensato di fare qualcosa in l10n_it_account, però andrebbe aggiunta la dipendenza da account_payment_order, e quindi tutto il repo dipenderebbe da quel modulo 🫤
Poi staremmo anche cambiando una funzionalità (il cambio di permessi) che quel modulo vuole espressamente aggiungere.
Non so, secondo me l'unica potrebbe essere provare a mettere questo modulo come ribelle e quindi testarlo da solo, a parte, però la lascerei proprio come ultima strada.

Sono d'accordo che il bug è in account_payment_order, ma se insistono che hanno ragione...

Sisì capisco anche il loro punto di vista, però bisogna trovare un punto d'incontro.
Se un modulo cambia un flusso di Odoo core (in questo caso dei permessi) che tutti gli altri si aspettano funzioni come in Odoo core, di solito è il modulo che si deve adeguare e rendere la modifica attivabile da configurazione.

[monen17]

/ocabot rebase

[OCA-git-bot]

Congratulations, PR rebased to 18.0.