Thursday, January 23, 2025
17 changes
1 change
Resolved issues and error corrections
Invoice report templates for Brazil, Colombia, and Peru were adjusted to match the updated invoice title structure. This keeps localized invoice and proforma invoice titles displaying and translating correctly for users in those countries.
Original PR description
*l10n_br_edi,l10n_co_dian,l10n_pe_edi In the related community commit, we restructure the invoice titles to allow for correctly translating proforma ones. This commit adapts some l10n templates that inherit the adapted structure. Related to https://github.com/odoo/odoo/pull/189664
16 changes
Resolved issues and error corrections
The scheduler now reports progress as it completes key background tasks for inventory, point of sale, and expiry alerts. This makes long-running automated maintenance easier to monitor and helps administrators understand whether scheduled work is moving forward.
Original PR description
This commit makes use of the ir.cron.progress feature in the stock scheduler. The first approach is to simply count how many tasks have been completely done among the 5 currently available
* stock
- trigger orderpoints
- merge quant & delete 0 quant
- reserve confirm stock move
* point_of_sale
- close session
* product_expiry
- make alerts on expired lots
They will be split in 5 different crons later to be able to count exactly the remaining records number to manage in each sub tasks.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMessages that start a sub-thread now keep their intended formatting when users open and participate in that thread for the first time. This prevents HTML formatting from appearing as plain text, improving readability in Mail discussions.
Original PR description
Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to…
Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to reproduce: - Post a message as user A - Create a thread from this message as user B - User A accesses this sub-thread and posts a new message -> User A sees 1st message with bad formatting This happens because on sub-thread join, the data of sub-thread info are fetched, and since the sub-thread is created from a message, the channel info data also contains the message data. This data was inserted without `html: true`, leading to message body being inserted in a non-trusted way in JS models, causing this formatting issue. This commit fixes the issue by flagging the insert with `html: true`, as this is from trusted origin and content is trusted, so the message body is inserted to be used properly in message component. Note that this behaviour applies to html fields, which message body is. The insert `html: true` is assessed for data on all targeted html fields. task-4506489
This fixes an issue in the Mail chatter where choosing a mention after replacing selected text could trigger an error. The editor now refreshes its selection correctly, making mention insertion more reliable for users composing messages.
Original PR description
**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls…
**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls `updateHints`, which relies on `getSelectionData`. However, `this.activeSelection` retains the outdated selection due to conditions like `documentSelectionIsInEditable` and `!this.activeSelection.anchorNode.isConnected` being `false`. As a result, `this.activeSelection` reflects `a[b]` while the DOM selection has already updated to `a[]`, leading to invalid offsets. **Solution**: Call `this.dependencies.selection.focusEditable();` during `onSelect` to ensure the selection is updated to reflect the editor state rather than the mention state. **Steps to Reproduce**: 1. Open the chatter. 2. Add some text. 3. Select a portion of the text. 4. Type `@`. 5. Select an item (person) from the mention list. 6. Observe a traceback error. opw-4498165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Closing a Point of Sale session no longer incorrectly shows a warning that another user is closing it. This avoids unnecessary page reload prompts and makes the end-of-day closing flow smoother for store staff.
Original PR description
- The `login_number` can be a string so we need to use "==" to avoid unexpected behaviour. - This fix an issue where each time you close a PoS session a popup appears with the message "The session is being closed by another user. The page will be reloaded". This was caused by the comparison of a string and an integer. task-id: 4485659 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This corrects an upgrade script that was producing inconsistent view definitions when converting older tree views to list views. It helps ensure system upgrades apply cleanly and avoids malformed configuration in updated installations.
Original PR description
since the pr https://github.com/odoo/odoo/pull/189883, the file updates made are not consistent: 'list<editable="bottom">'.
This fixes an issue where employee logins in Point of Sale could trigger a console error after locking and re-entering a session from the payment screen. Cashiers can now resume the session more reliably without encountering that disruption.
Original PR description
Before this commit: - Enable the "Log in with employees" - Log in as any employee, add a product, and go to the payment screen - Lock the session - Enter the session again This sequence of actions would result in an error in the console. opw-4435559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where certain loyalty reward product rules could fail to load because the system read them in the wrong format. Loyalty promotions using true/false conditions should now work reliably in Point of Sale without triggering errors.
Original PR description
Before this commit, `domain['reward_product_domain']` was being evaluated with `ast.literal_eval` while containing JSON-style booleans (`true/false`). That caused a `ValueError` because `true/false` are invalid in Python syntax. With this commit, we now use `json.loads` to parse the domain string, which correctly handles JSON booleans without error. opw-4458627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how imported vendor bills are classified as manually edited, so users are only prompted to enable automatic posting when the system has correctly detected repeated unchanged bills. It also prevents localization-related background processing from incorrectly marking bills as edited, improving reliability for companies using Egyptian e-invoicing features.
Original PR description
In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he…
In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he wants to activate the feature. To detect whether the user has modified the imported bill or not, we use a new field `is_manually_modified` which is always set to `True` when the bill is edited except for automatic flows (OCR, CRON, email). test_autopost_bills will fail when the l10n_eg_edi_eta module is installed. This is due to fact that calling import_facturx will end up calling _extend_with_attachments, which in turn changes the value of l10n_eg_eta_json_doc_id.raw which triggers the computes that depend on it. This is why we add the context key before calling _extend_with_attachments. Moreover, in the same function, a savepoint is created, triggering a flush that triggers the recomputes. A savepoint is created without the context, therefore we flush right before we create the savepoint. runbot-110629
[1] adds a settings entry in CRM for ringover As this was done in stable the .pot file should have been updated [1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859
Original PR description
[1] adds a settings entry in CRM for ringover As this was done in stable the .pot file should have been updated [1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859
The Viva Wallet payment webhook is now correctly marked as able to update records. This prevents unnecessary warning messages in logs while keeping payment processing behavior unchanged.
Original PR description
Since #584a172, controller endpoints can specify `readonly=False` if they are expected to write to the DB. The webhook endpoint for Viva Wallet was previously not specified this way, which leads to a warning being logged. This commit simply adds `readonly=False` to the webhook endpoint to prevent the warning. task-4472274 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where opening the Gantt view for restaurant appointments could use the wrong underlying record type. This prevents potential loading errors and helps staff access appointment scheduling views reliably.
Original PR description
Before this commit, opening the calendar event Gantt view called the `calendar.event` model, but the `appointment.type` ID was passed. This mismatch could lead to an error when attempting to load the view. opw-4493685
This update adjusts an internal test so it matches how follow-up reporting works in version 18.0, where the partner ledger is used. It helps prevent false test failures while still checking that the right accounting lines are recovered.
Original PR description
The test breaks https://github.com/odoo/odoo/pull/184482 In 18.0, partner ledger is used for the followup. Keep the test as it still assess we recover the lines correctly.
This fixes a payroll accounting test setup issue that could appear when Belgian payroll was installed before Australian payroll. The change ensures contract creation uses the correct payroll structure information, making the test reliable across localization combinations.
The Executive Summary report now uses the correct revenue line when calculating net profit margin. This helps businesses see a more accurate profitability percentage after recent Profit and Loss report changes.
Original PR description
The REV line was introduced in 18.0 when revamping the P&L, here: https://github.com/odoo/enterprise/commit/cbe74884b937f630cf1d2ccf475a04e70b6f4669 Following this change, this line should be used in the formula of the Net profit margin of the Executive Summary, as stated here https://www.investopedia.com/terms/n/net_margin.asp
Saudi payroll bank details are now managed only from the relevant bank or bank account form, avoiding duplicate editing places. The settings page now warns users when required bank information is missing, helping prevent payroll configuration mistakes without blocking setup unnecessarily.
Original PR description
Task URL: https://www.odoo.com/odoo/project.task/4184694 Changes: - Remove fields l10n_sa_bank_account_id, l10n_sa_bank_establishment_code, & l10n_sa_sarie_code from res.config.settings so that it can only be edited in the bank/bank acc. form view. - Show warning if one of the fields (l10n_sa_bank_id, l10n_sa_bank_establishment_code, l10n_sa_sarie_code) is not set. - Adjust width for l10n_sa_bank_account_id
Accounting reports with period-based date selectors now handle jumps of more than 365 years correctly. This prevents incorrect dates when users navigate very far backward or forward in reports such as tax reports or profit and loss statements.
Original PR description
In accounting reports that use periods (like the tax report or profit and loss), the date selector is broken when you try to go back or forward for more than 365 years. The reason is that it was computing the resulting year by looping over the number of years to go back/forward, and each time adding or subtracting the number of years as days. When over 365, it would go back/forward more than 1 year per iteration. This commit fixes the issue. [task-4410887](https://www.odoo.com/odoo/project.task/4410887)