-
-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FIX]l10n_it_vat_statement_communication risolve il problema della regola multi company non funzionante #4353
base: 16.0
Are you sure you want to change the base?
Conversation
8854e04
to
275ad87
Compare
573f374
to
695fd8d
Compare
@tafaRU per caso si può mergiare anche questa? |
@matteoopenf sistema il nome dei commit e della PR per favore |
ps. si possono squashare o ne servono 2? |
695fd8d
to
0d43222
Compare
…typo in name of the id of the rule
0d43222
to
e6723b3
Compare
fatto |
@OCA/local-italy-maintainers posso chiedere una review? Grazie! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grazie della PR!
Capisco la correzione del typo, ma potresti chiarire come mai questo typo causa dei problemi?
"Migration of l10n_it_vat_statement_communication - unlink" | ||
" previous multi company rule for 'comunicazione.liquidazione' model" | ||
) | ||
old_vat_comm_multi_company_rule_ref.unlink() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non credo che ricreare la regola sia safe: l'utente potrebbe averla modificata (in fondo è per quello che è noupdate
), oppure se fosse collegata ad altri record tramite campi relazionali il collegamento sparirebbe.
Normalmente quando una migrazione deve modificare dei record noupdate
è sufficiente aggiornare il record, in questo caso però non si sta modificando il record ma il suo ir.model.data
, quindi la migrazione dovrebbe recuperare l'ir.model.data
e modificarlo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, lo script di migrazione mira a ricreare la regola, che in ambienti migrati resta alla vecchia versione https://github.com/OCA/l10n-italy/blob/12.0/l10n_it_vat_statement_communication/security/security.xml#L9 causando problemi con ambienti multicompany perché il campo usato nella rule potrebbe non corrispondere al valore della proprietà company nell'env che da 14.0 viene usato per molti dei casi; il modificare ir_model_data è solo una correzione ortografica, comunucazione
non lo trovo corretto
Oltretutto aggiornare il record della rule modificando il campo domain_force, è lo stesso che farla ricreare; in entrambe i casi se è stata modificata a mano, le modifiche vanno perse; per quanto riguarda il cambiare l'xmlid si può anche tralasciare
"Migration of l10n_it_vat_statement_communication - unlink" | ||
" previous multi company rule for 'comunicazione.liquidazione' model" | ||
) | ||
old_vat_comm_multi_company_rule_ref.unlink() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, lo script di migrazione mira a ricreare la regola, che in ambienti migrati resta alla vecchia versione https://github.com/OCA/l10n-italy/blob/12.0/l10n_it_vat_statement_communication/security/security.xml#L9 causando problemi con ambienti multicompany perché il campo usato nella rule potrebbe non corrispondere al valore della proprietà company nell'env che da 14.0 viene usato per molti dei casi; il modificare ir_model_data è solo una correzione ortografica, comunucazione
non lo trovo corretto
Oltretutto aggiornare il record della rule modificando il campo domain_force, è lo stesso che farla ricreare; in entrambe i casi se è stata modificata a mano, le modifiche vanno perse; per quanto riguarda il cambiare l'xmlid si può anche tralasciare
risolve #4354