[12.0] [FIX] l10n_it_fiscalcode_sale: change module dependency

[primes2h]

Il modulo l10n_it_fiscalcode_sale permette di mostrare il codice fiscale del cliente nella stampa del preventivo / ordine di vendita.
Dato che i preventivi/ordini di vendita vengono aggiunti installando sale_management (applicazione "Vendite"), il modulo dovrebbe di conseguenza dipendendere da quest'ultimo e non da sale.

La situazione attuale porta al seguente problema.
In una installazione Odoo con ad es. fatturazione elettronica, imposta di bollo e dichiarazione di intento (per obbligo dei clienti), il modulo l10n_it_fiscalcode_sale viene installato in modo automatico anche se non necessario.

Questa PR corregge il problema.

Vedi anche #3105

[OCA-git-bot]

Hi @eLBati,
some modules you are maintaining are being modified, check this out!

[matteoopenf]

Ma il report che eredita nelle View è del modulo sale non l'altro. Non mi sembra corretta quindi la pr .

l10n-italy/l10n_it_fiscalcode_sale/views/sale_order_report.xml

Line 3 in abdc072

[primes2h]

Ma il report che eredita nelle View è del modulo sale non l'altro. Non mi sembra corretta quindi la pr .

l10n-italy/l10n_it_fiscalcode_sale/views/sale_order_report.xml

Non vedo il problema, visto chesale è il modulo base e quindi dipendenza dell'applicazione Vendite (sale_management).

È il comportamento attuale che non è corretto.
Installando l10n_it_fiscalcode_sale o l10n_it_account_stamp_sale mi aspetto che nell'interfaccia siano poi presenti i preventivi/ordini di vendita, visto che sono indicati nel README dei due moduli.

Line 3 in abdc072

Questo commit è relativo al file it.po del modulo cespiti.

[matteoopenf]

Ma il report che eredita nelle View è del modulo sale non l'altro. Non mi sembra corretta quindi la pr .
l10n-italy/l10n_it_fiscalcode_sale/views/sale_order_report.xml

Non vedo il problema, visto chesale è il modulo base e quindi dipendenza dell'applicazione Vendite (sale_management).

È il comportamento attuale che non è corretto. Installando l10n_it_fiscalcode_sale o l10n_it_account_stamp_sale mi aspetto che nell'interfaccia siano poi presenti i preventivi/ordini di vendita, visto che sono indicati nel README dei due moduli.

Line 3 in abdc072

Questo commit è relativo al file it.po del modulo cespiti.

devo aver sbagliato a linkare il commit chiedo venia.

In ogni caso solitamente se si eredita qualcosa da un modulo esso si mette come dipendenza, perchè così si è certi dalla sua installazione, in alcuni casi non mettere la dipendenza causa errori strani o comportamenti inattesi.

[primes2h]

Ma il report che eredita nelle View è del modulo sale non l'altro. Non mi sembra corretta quindi la pr .
l10n-italy/l10n_it_fiscalcode_sale/views/sale_order_report.xml

Non vedo il problema, visto chesale è il modulo base e quindi dipendenza dell'applicazione Vendite (sale_management).
È il comportamento attuale che non è corretto. Installando l10n_it_fiscalcode_sale o l10n_it_account_stamp_sale mi aspetto che nell'interfaccia siano poi presenti i preventivi/ordini di vendita, visto che sono indicati nel README dei due moduli.

Line 3 in abdc072

Questo commit è relativo al file it.po del modulo cespiti.

devo aver sbagliato a linkare il commit chiedo venia.

In ogni caso solitamente se si eredita qualcosa da un modulo esso si mette come dipendenza, perchè così si è certi dalla sua installazione, in alcuni casi non mettere la dipendenza causa errori strani o comportamenti inattesi.

In generale sono perfettamente d'accordo con te.
In questo caso caso la certezza dell'installazione è abbastanza palese visto che senza sale non funzionerebbe nemmeno sale_management.

[matteoopenf]

Ma il report che eredita nelle View è del modulo sale non l'altro. Non mi sembra corretta quindi la pr .
l10n-italy/l10n_it_fiscalcode_sale/views/sale_order_report.xml

Non vedo il problema, visto chesale è il modulo base e quindi dipendenza dell'applicazione Vendite (sale_management).
È il comportamento attuale che non è corretto. Installando l10n_it_fiscalcode_sale o l10n_it_account_stamp_sale mi aspetto che nell'interfaccia siano poi presenti i preventivi/ordini di vendita, visto che sono indicati nel README dei due moduli.

Line 3 in abdc072

Questo commit è relativo al file it.po del modulo cespiti.

devo aver sbagliato a linkare il commit chiedo venia.
In ogni caso solitamente se si eredita qualcosa da un modulo esso si mette come dipendenza, perchè così si è certi dalla sua installazione, in alcuni casi non mettere la dipendenza causa errori strani o comportamenti inattesi.

In generale sono perfettamente d'accordo con te. In questo caso caso la certezza dell'installazione è abbastanza palese visto che senza sale non funzionerebbe nemmeno sale_management.

Ok che l'altro modulo la garantisce.

Non capisco tuttavia il vantaggio di togliere una dipendenza del genere.

[matteoopenf]

anche perchè con il cambio di pricing di Odoo non si presenta più il problema di upsell per app in più installate e cose del genere

[primes2h]

In ogni caso solitamente se si eredita qualcosa da un modulo esso si mette come dipendenza, perchè così si è certi dalla sua installazione, in alcuni casi non mettere la dipendenza causa errori strani o comportamenti inattesi.

In generale sono perfettamente d'accordo con te. In questo caso caso la certezza dell'installazione è abbastanza palese visto che senza sale non funzionerebbe nemmeno sale_management.

Ok che l'altro modulo la garantisce.

Anche il modulo Odoo sale_margin fa la stessa cosa.
Dipende da sale_management ma mi pare che erediti solo le viste di sale.

https://github.com/OCA/OCB/blob/7790dc120d2b4cdd5309a4a9a576121fcc0fe400/addons/sale_margin/__manifest__.py#L15

https://github.com/OCA/OCB/blob/16.0/addons/sale_margin/views/sale_order_views.xml

Non capisco tuttavia il vantaggio di togliere una dipendenza del genere.

Non è questione di vantaggi, è che l'installazione del modulo non porta a quello che è indicato nel suo README. Come ho scritto sopra:

Installando l10n_it_fiscalcode_sale o l10n_it_account_stamp_sale mi aspetto che nell'interfaccia siano poi presenti i preventivi/ordini di vendita, visto che sono indicati nel README dei due moduli.

Inoltre come effetto collaterale viene installato anche nei casi in cui non è previsto che lo sia (vedi descrizione della PR).

[eLBati]

LGTM

[TheMule71]

/ocabot merge patch

[OCA-git-bot]

What a great day to merge this nice PR. Let's do it!
Prepared branch 12.0-ocabot-merge-pr-3106-by-TheMule71-bump-patch, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 37d9d78. Thanks a lot for contributing to OCA. ❤️