Tuesday, November 19, 2024
10 changes · 17.0
Resolved issues and error corrections
Posted invoices using early payment discounts can now have analytic distribution updates applied without incorrectly blocking the change. This prevents an error when adjusting reporting allocations while keeping protections in place so only the related discount lines can be changed.
Original PR description
### Steps to reproduce the issue: 1. Create a Payment Term with Early Discount and Reduced Tax set to "Always (upon invoice)" 2. Create an Invoice with two Lines with Taxes, add the Payment Term and…
### Steps to reproduce the issue: 1. Create a Payment Term with Early Discount and Reduced Tax set to "Always (upon invoice)" 2. Create an Invoice with two Lines with Taxes, add the Payment Term and Confirm 3. In the Journal Items, select one of the Invoice Lines and change its Analytic Distribution 4. Receive the error: > You cannot modify the taxes related to a posted journal item, you should reset the journal entry to draft to do so. ### Explanation: This is due to the behaviour of `line_ids` with `invoice_payment_term_id.early_pay_discount_computation == 'mixed'`. When adding `analytic_distribution` to one of `invoice_line_ids`, `account.move.line` representing the Early Payment Discount are rewritten to match the new distribution: - existing lines can have their values adjusted or can be removed - new lines can be created If `state == 'posted'`, operations performed on the existing lines are blocked. ### Fix reasoning: We will allow for modifications on `epd` lines if `analytic_distribution` is being modified through a context key. We will also ensure that only `epd` lines can be modified or removed. opw-4247756
Sales orders created from billable project tasks are now confirmed only after their order lines are saved. This prevents customers from receiving premature confirmation emails with empty or $0 quotation documents while still ensuring work starts only on confirmed orders.
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app…
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/enterprise/pull/73492 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar reminders now work for recurring meetings that end after a set number of repeats or continue indefinitely. This ensures users receive expected notifications for upcoming recurring events, reducing missed meetings.
Original PR description
Steps to reproduce: - Calendar > New > Tick 'Recurrent' - 'Until' => 'Number of repetitions' or 'Forever' - Set meeting start time in 5 mins - Add reminder => Notification - 15 Minutes > Save The notification is not sent, this is due to the use of 'until' to fetch the last event date of recurrent meetings despite that field only being set if the recrrence type is 'End date'. We want to check that date to avoid sending notifications for past meetings, but 'Number of Repetitions' recursions use a count instead of a date, and 'Forever' obviously doesn't need a date. Using the meeting end date instead should do the trick since it will always be in the future at the moment we want to send the reminder and it should never go over the last event date since no meeting record will be created after the recurrence ends anyway. opw-4247282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures electronic invoicing customization rules are correctly recognized when country-specific modules extend them. It prevents a crash when creating or saving a company that uses an existing electronic invoicing participant identifier, such as in Japan.
Original PR description
The method has an api.model while it is inherited (and designed as such) in other modules. It causes issues if you create a company with an existing participant in the country of these other modules and with the default eas. Example: create a company with the module l10n_jp_ubl_pint installed, Japan as country and put as Tax number the endpoint of an existing participant When saving, it will traceback, as the key is not in the dict --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project updates now correctly include material costs when a project uses an analytic plan other than the default Projects plan. This prevents project profitability figures from missing costs, giving managers a more accurate view of project performance.
Original PR description
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except…
Steps to reproduce: - Install Accounting > Settings > Enable 'Analytic Accounting' - Project App > New > Project Settings > Edit Analytic plan - Change Plan from 'Projects' to any other (except Internal) - Manufacturing > Operations > Manufacturing Orders > New - Product: 'Table Top' - Miscellaneous tab > Analytic distribution: <Project account> - Confirm > Produce All > Set quantities & Validate - Project > ':' Menu > Project Updates (Dashboard in 18.0+) - The cost of materials ($160) is not deducted in Project costs Analytic distributions include different categories for each plan, this is reflected in DB with a different column for each plan, account_id/x_plan2_id/x_plan3_id/... which contain the project's analytic account. In version 18.0 and above we allow each project to have several analytic accounts (for the project, department, ...) but prior to that we relied on plan_id to differentiate the project account category. When checking for analytic lines to populate the project updates we check the `account_id`, meaning only lines with projects having analytic plan 'Projects' would pass that filter domain. We instead want to grab the account_id from any of the plan columns. opw-4282092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounts created for branch companies are now correctly linked to matching account groups from the parent company. This helps businesses using branch structures keep financial reporting and account organization consistent across the company hierarchy.
Original PR description
### Steps to reproduce the issue: 1. Make sure you are in a company that is not a branch 2. Create a branch company 3. In the parent company, create an account group 4. In the branch company, create an account that should be set in the account group 5. The branch account is not set in the account group ### Explanation: When creating an account, we will enter `_adapt_accounts_for_account_groups` with a value for `account_ids`. As can be seen, `company_ids` is then assigned `account_ids.company_id.root_id.ids` which only corresponds to the id of the root company, not its branches. ### Fix reasoning: As asked by TSB, `account.group.company_id` can not have a `parent_id`, redirecting default value to `root_id`. `_accessible_branches` is only looking for active companies, the objective is to retrieve all children of `root_companies` (recursively). opw-4192988
Odoo now limits partner lookup by company when sending emails to addresses shared by multiple companies. This prevents access errors and ensures sales quotations and other emails are sent using the correct company-specific contact.
Original PR description
## Issue: When we have two partners with the same email address but in different companies, when trying to send an email to one of them, the system will raise an access error because it will try to…
## Issue: When we have two partners with the same email address but in different companies, when trying to send an email to one of them, the system will raise an access error because it will try to access the partner from the other company. ## Steps to reproduce: - modify the email template for the "Sales: Send Quotation" `email to` field to for example: `test@example.com` - in a multi company environment with two companies, create a new odoo user with the same email: `test@example.com` having access to both companies - logged in as the odoo user, create a new partner with the same email - create a new quotation with the user's partner as a customer and try to send the quotation - the system will raise an access error ## Solution: - in the `_find_or_create_from_emails` method of the res.partner model, we applied the company-based filtering to the search for the existing partner with the given email address to avoid accessing partners from other companies. OPW-4043762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Belgian POS blackbox records use the cashier assigned to the order, or safely fall back to the POS user when needed. It helps prevent mismatches between blackbox logs and Odoo records, and avoids errors on the IoT Box when cashier data is missing.
Original PR description
The changes proposed in this commit alter the fallback cashier when sending data to the blackbox. Before this commit, we were not checking for the truthiness of the return value of PosStore.get_cashier() and were falling back to PosStore.user only if pos_hr was not installed. Furthermore, we were checking for the current cashier rather than the one specified on the order. This could lead to 2 potential errors - a discrepancy between what has been logged to the blackbox and the data in Odoo - the cashier variable is undefined, leading to a traceback on the IoT Box After this commit, the cashier from the order will be used if existing or the code will correctly fall back to PosStore.user. opw-4182434 opw-4293988
This update fixes an issue where email notifications were sent prematurely when creating sales orders, leading to inaccurate quotation documents. The change ensures the sales order is confirmed after the order line is created, preventing work on potentially cancelled quotations. This improves data accuracy and user experience.
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/odoo/pull/183586 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402
This update resolves an error that occurred when editing barcode scanning records, specifically during rapid switching between the barcode view and the detailed record. The fix ensures the barcode component correctly updates database information, preventing a 'undefined record' error. This improves the reliability of the barcode scanning feature.
Original PR description
### Steps to reproduce: - Create a delivery order for 2 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend by clicking on the…
### Steps to reproduce: - Create a delivery order for 2 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend by clicking on the prodcut name. - Come back to the record the faster you can. #### > Error in Owl lifecycle: undefined record in get moveIds ### Cause of the issue: Since the barcode app relies on stock move line's data to generate its main component it is necessary to split moves in DB when you exit the barcode app in order to rerender the main component with appropriate data the next time you enter the barcode. Currently this split is done `onWillDestroy`: https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/components/main.js#L105-L107 https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 However, if you come back to the barcode app fast enough you will start the creation of a new barcode main component before this rpc call has ended, in turn you will modify the content of the component before it has even mounted (even prior to the assignment of this.record) and owl will therefore destroy that component and recreate a new one with the appropriate content. But since this non-mounted component is destroyed it triggers the onWillDestroy and since it has no record yet it triggers an error by trying to access `this.moveIds`: https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/models/barcode_picking_model.js#L656-L658 ### Fix: Since we only want to trigger our `_onExit` method to update DB's data if the component has been mounted and since the `this.record` will always exist in that case, we should use the onWillUnmount hook rather than the onWillDestroy. Follow-up of c16acf3617442d3048f6a1246a2bc826af3c02fd (fixed in forward ports post 17.0). opw-4232106