Sunday, November 5, 2023
4 changes · 17.0
Resolved issues and error corrections
A debug console.log statement was accidentally left in the account reports widget code and has been removed. This cleanup ensures the application runs cleanly without unnecessary debug output in production.
Original PR description
Forgot to remove a `console.log`.
Miscellaneous changes
It is not possible to add to comparison a product without variant. But before this commit, if you add the product to the wishlist, it is possible to add it to comparison. This commit prevents this button from appearing in case the product has no variant. Solves #139175 Forward-Port-Of: odoo/odoo#140174
Original PR description
It is not possible to add to comparison a product without variant. But before this commit, if you add the product to the wishlist, it is possible to add it to comparison. This commit prevents this button from appearing in case the product has no variant. Solves #139175 Forward-Port-Of: odoo/odoo#140174
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail aliases on `account.journal`, journal entries can end up with a fiscal position from the default company of the user that the account.move creation runs as, or the import fails with an error `'Draft Entry' belongs to company X and 'Fiscal Position' belongs to another company.` While `account.move
Original PR description
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail…
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail aliases on `account.journal`, journal entries can end up with a fiscal position from the default company of the user that the account.move creation runs as, or the import fails with an error `'Draft Entry' belongs to company X and 'Fiscal Position' belongs to another company.` While `account.move`'s `_compute_fiscal_company_id` calls `account.fiscal.position`'s `_get_fiscal_position` with the correct company, it passes one or two `res.partner` records to this method that are still browsed with the default company of the executing user which can result in a fiscal position from that company instead of the company of the journal entry. _Current behavior before PR:_ Entry is not created or is created with a fiscal position from another company than the company of the entry. _Desired behavior after PR is merged:_ Entry is created with a fiscal position from the right company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#138722
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function. This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the compa
Original PR description
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch…
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function. This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the company selector ; respecting the hierarchy of branches, with parent companies coming first. This was spotted in Accounting, with the following setup: - A company named "main", with one branch called "branch". - "branch" has one sub-branch called "branch branch". - Enable "main" and all its sub branches in the selector ; "main" is the active company. Here are the issues that were found in Accounting: 1) Click on the "new" button in the Customer Invoices' tree view. Don't change anything in the form that opens, and check the value in the company_id field of the invoice being created. It should be "main", but it's "branch" instead. 2) (when applying the fix commit on the enterprise branch related to this one) When printing an accounting report, the route called to generate the file restores the active companies from the options' multi_company key https://github.com/odoo/enterprise/blob/16.0/account_reports/controllers/main.py#L21 . Because of that, if the report does not support multicompany, but only branches of the active company (see corresponding enterprise commit for details), if the first company in this list is one of the branches instead of the main company, the companies computed for the report will be different. In our example, "branch" will be first in the list, so the options for the file export will be computed with "branch" as main company, enabling only its branches that are selected in self.env.companies ; so only "branch" and "branch branch" will be in the report ; which is wrong, as we also want "main". Forward-Port-Of: odoo/odoo#139217