[14.0][FIX] - l10n_it_fatturapa : get the correct preview style #2964
Conversation
|
Hey @michelerusti, thank you for your Pull Request. It looks like some users haven't signed our Contributor License Agreement, yet.
Appreciation of efforts, |
|
devi firmare la CLA |
| @@ -107,7 +107,7 @@ def get_fattura_elettronica_preview(self): | |||
| xsl_path = get_resource_path( | |||
| "l10n_it_fatturapa", | |||
| "data", | |||
| self.env.company.fatturapa_preview_style, | |||
| self.company_id.fatturapa_preview_style, | |||
There was a problem hiding this comment.
Visto #2965 (comment)
self.company_id non punta alla company corrente ma a quella usate per creare l'attachment.
There was a problem hiding this comment.
Si hai ragione, mi son confuso.
L'errore però sussiste perchè (quando multi-company) self.env.company estrae la company impostata di default nel profilo dell'utente ma la stampa deve avvenire con il template relativo all'azienda in uso.
Sbaglio?
There was a problem hiding this comment.
self.env.company estrae la company impostata di default nel profilo dell'utente
Quello è self.env.user.company_id.
self.env.company è la company correntemente selezionata. In teoria.
There was a problem hiding this comment.
Inizialmente lo pensavo anche io ma entrando in debug mi porta quella di default, confermato anche cambiando il default e vedendo i risultati diversi
Però non ho trovato documentazione ufficiale a riguardo
There was a problem hiding this comment.
I sorgenti sono qui.
https://github.com/odoo/odoo/blob/062fb69f346873fe05ebb5d429ab3535fd1df5cc/odoo/api.py#L537-L565
prende la prima tra le allowed_company_ids
se non ci sono, il default dell'utente.
There was a problem hiding this comment.
Dunque penso che, selezionare il template relativo alla company che ha generato l'allegato sia corretto, in quanto altrimenti la funzione di selezione template nelle impostazioni perde di utilità e può creare confusione visto che quelli delle companies diverse dalla default non sono mai accessibli.
Sono d'accordo con questo pensiero, anche perché se l'attachment è stato importato per una company X è giusto avere la preview con lo stile settato nella company X.
There was a problem hiding this comment.
@michelerusti
La miglior soluzione è capire perché in quel caso non funziona self.env.user.company_id. Nella issue non ci sono istruzioni per riprodurre il problema, anche perché c'è scritto "ogni tanto". Bisogna capire quando succede esattamente, in modo da riuscire a riprodurre il problema, e poi capire perché succede.
Sono d'accordo con questo pensiero, anche perché se l'attachment è stato importato per una company X è giusto avere la preview con lo stile settato nella company X.
Questo non è quello segnalato nella issue. Nella issue ho chiesto esplicitamente quale fosse il comportamento desiderato, ci sono due possibilità:
- si usa il template della company selezionata come corrente dall'utente (
self.env.user.company_id); - si usa il template della company che ha emesso la fattura a cui è legato l'attachment (
self.company_id).
Sono due comportamenti diversi. È stato scelto il primo.
There was a problem hiding this comment.
@TheMule71
Si, effettivamente c'è stata un po' di confusione durante tutta questa PR e proverò a fare un sunto della situazione e del perchè penso che la proposta sia valida.
L'errore segnalato nella issue deriva proprio dalla confuzione che si crea utilizzando il self.env.user.company_id
L'utilizzo (non mio) di "ogni tanto" è motivato dal fatto che la gestione attuale del template crea confusione in quanto, come dicevo prima, il template di risposta è sempre quello di default utente. La descrizione di come replicare il problema mi sembra ci sia
Il problema deriva dall'assenza di un self.env.context all'interno del controller segnato nel mio commento sopra
Quindi, a meno che esista un modo che non sono riuscito a trovare di accedere al context con le allowed_company cercare di recuperare quello è sbagliato dal principio.
Quindi, andando avanti in questa PR, alla luce di queste scoperte, propongo di utilizzare self.company_id diversamente da come è stato fatto attualmente per effettivamente utilizzare dei valori ai quali possiamio accedere e, come condiviso con @TonyMasciI , migliorare l'esperienza utente in quanto a coerenza d'uso.
Potrei ricredermi e cambiare idea se ci fosse un modo di accedere alle allowed_company_ids dal controller in questione ma non sono riuscito a trovarlo.
There was a problem hiding this comment.
ll modo corretto è tramite self.env.user.company_id. Quello accede agli allowed_company_ids, e fa la cosa giusta.
Su carta almeno.
Se in pratica non funziona, bisogna fixare il bug. In sostanza non va cambiato self.env.user.company_id, va fatto funzionare.
There was a problem hiding this comment.
Ah ok, allora eventualmente ci sarà da sistemare quella parte di codice!
Ad ogni modo, anche una volta fixato, mi sento di portare avanti l'idea che sia meglio usare il self.company_id invece di quello delle allowed_companies anche per gli altri motivi portati sopra.
Pensi sia accettabile?
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
Corregge #2965 per 14.0