Thursday, February 5, 2026
33 changes · 19.0
Enhancements to existing features
Expense bills paid by the company now carry the payment reference notes onto the related payment line. This gives accounting teams clearer context and better traceability, matching how standard invoices already behave.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244392 Forward-Port-Of: odoo/odoo#241353
This update enhances the booking view in the Odoo Enterprise system by adding breadcrumbs. This provides clearer navigation for users, making it easier to understand their location within the booking process and improving the overall user experience. The change was implemented to streamline workflow and reduce potential confusion.
Original PR description
In this commit: - Enable breadcrumbs for the booking view by explicitly allowing them in the action context. Task:5490961
Resolved issues and error corrections
POS self-order confirmation emails for delivery and takeout now display order totals with the correct currency symbol and local number formatting. This makes customer emails clearer and more professional, reducing confusion over order amounts.
Original PR description
**Problem:** POS self-order confirmation emails (delivery and takeout) display the order amount without the currency symbol and proper formatting. **Steps to reproduce:** 1. Create a POS self-order…
**Problem:** POS self-order confirmation emails (delivery and takeout) display the order amount without the currency symbol and proper formatting. **Steps to reproduce:** 1. Create a POS self-order with delivery or takeout 2. Preview or send the confirmation email 3. Observe the amount displays without currency symbol or formatting **Current behavior:** Email shows amount as a plain number (e.g., "2.0") without currency symbol or locale-specific formatting. **Expected behavior:** Email should display amount with currency symbol and proper formatting based on user's locale (e.g., "2,00€", "$2.00", etc.). **Cause of the issue:** The email templates used direct field output `t-out="object.amount_total"` which renders only the numeric value without any formatting. This bypasses Odoo's standard currency formatting that handles both the symbol and locale-specific decimal/thousand separators. **Fix:** Use the `format_amount()` helper function which properly formats monetary values with currency symbols and locale-appropriate separators. The function takes the amount and currency as parameters and returns the fully formatted string respecting the user's language settings. opw-5485801
Fixed an issue where images placed inside links would jump to full width after being resized. This keeps edited content looking as intended and avoids frustrating layout changes for users working with images in the HTML editor.
Original PR description
Problem: Resizing an image inside a link causes it to snap to 100% width on mouseup. Cause: The percentage calculation uses the parent element's width as reference. When the parent is inline (like `<a>`) or has fit-content width, its width equals the image width, resulting in 100% every time. Solution: Find the first ancestor with content width larger than the image and use it as reference for the percentage calculation. Steps to reproduce: - Add an image inside a link - Resize the image - Observe the image snaps to 100% width on release opw-xxxx --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment method options linked to archived journals are now hidden when editing a contact. This prevents users from accidentally choosing outdated payment methods while preserving the journal configuration in case it is reactivated later.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245947
Forward-Port-Of: odoo/odoo#240369This fix prevents problems when renaming a custom field that is inherited by other records. Odoo now removes the automatically generated inherited fields first, helping avoid database conflicts and keeping customizations reliable.
Original PR description
When renaming a custom field that is inherited, first remove the generated inherited fields from the database. task-5172546 backport of #240603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Expenses app now keeps its empty-state upload area properly positioned when there are no expenses to process and filters are removed. This prevents the receipt upload prompt from overlapping dashboard or search areas, giving users a cleaner and more reliable screen.
Original PR description
Steps to reproduce: 1. Open the Expenses app and navigate to 'Expenses to Process'. 2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears. 3. Remove filters. 4.…
Steps to reproduce: 1. Open the Expenses app and navigate to 'Expenses to Process'. 2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears. 3. Remove filters. 4. The layout becomes 'disturbed'—the upload overlay misaligns and overlaps the dashboard. Issue: The issue occurred because the SCSS selector was incorrectly targeting the combination of .hr_expense and .o_list_view. In the Odoo DOM structure, the hr_expense class is added to the Renderer via XML, while o_list_view is assigned to the main Controller. Because the selector never matched an actual element, the min-height: 100% rule remained inactive. Without a stable minimum height, the Renderer container collapses when empty. This prevents the 'Pink Overlay' from having a stable anchor point, leading to layout shifts and visual interference with the Search Panel and Dashboard headers. Solution: Update the SCSS selector to target &.o_list_renderer and &.o_kanban_renderer. This ensures the rule correctly matches the element carrying the hr_expense class. By forcing a min-height: 100% !important on the renderer itself, the container remains stable regardless of the data count. This provides a consistent workspace for the 'No Content' helper to render without disrupting the surrounding flexbox layout. opw-5452618
The Attendance kiosk now points users to an RFID device listing on Amazon.com with broader delivery availability. This prevents users in the United States from landing on a blank or unavailable product page when trying to buy a compatible device.
Original PR description
Steps to reproduce: ----------------------------------- 1. Install the Attendance module with demo data 2. Go to Kiosk Mode > click on the link to 'Buy an RFID Device' 3. On the opened Amazon page, change the delivery country to United States Observation: ----------------------------------- The Amazon product page becomes blank after switching the delivery country to the United States Issue: ----------------------------------- The link redirects to the French Amazon website (`amazon.fr`) with a merchant that does not ship RFID devices to the United States Solution: ----------------------------------- Update the link to use `amazon.com` instead of `amazon.fr`. Change the merchant ID to one with broader delivery availability, including the United States. opw-5479568
This fixes an issue in the HTML editor where pasting text or an image URL into an empty or fully selected link could place the new content inside the old link instead of replacing it. Users can now paste content more reliably when editing links, reducing formatting mistakes and cleanup work.
Original PR description
Problem: When pasting text or a image URL inside an empty link, or when the link is fully selected, the link is not removed and replaced by the pasted content. Instead, the text or URL is inserted…
Problem: When pasting text or a image URL inside an empty link, or when the link is fully selected, the link is not removed and replaced by the pasted content. Instead, the text or URL is inserted inside the link, which is not the intended behavior. Cause: When pasting text or a image URL, and a command is triggered from the powerbox via `openPowerboxOnUrlPaste`, we call `addStep` after the content insertion. This step not only inserts the content but also removes the link if it was fully selected (via `before_paste_handlers`). However, `onApplyCommand` then restores the state to before the content insertion and link removal. The command (e.g. “Embed Image”) is executed on that restored state, where the selection is collapsed inside the link. As a result, the inserted content ends up inside the link instead of replacing it. Solution: In this situation, fully select the link before inserting the content. This allows the `insert` logic to correctly replace the link with the pasted text or URL. task-5386862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247205
This change replaces an unstable automated test in the Manufacturing app that was causing inconsistent nightly test failures. It helps keep release validation dependable without changing business workflows or user-facing behavior.
Original PR description
Issue ----- The tour added in commit 6927265 was failing in nightly. The attempted fix in 246bf1d resolved the first problem but raised some new non-deterministic issues. ----- Errors 237956, 238469 & 238470 Forward-Port-Of: odoo/odoo#246687
This fix ensures automated checks for website course pages wait until the discussion area has fully loaded before continuing. It reduces false test failures and helps maintain confidence that course-related website features work as expected.
Original PR description
### Before commit Some tours did not wait for the portal chatter to load when needed: - `portal_chatter_bundle`: the `run` function creates a promise but the tour finishes before it resolves. - `fullscreen_slide_text_highlights`: `PortalChatterService` adds an element in the DOM while the selection is updated in the `selectText` tour step. This caused the following warning to show: ``` should not have any "characterData", "remove" or "add" mutations in current step when you update the selection ``` ### Fix Properly wait for `portalChatterReady` to resolve before proceeding with the rest of the tour steps. (Also fixed the typo in the filename `slide_portal_chatter_bundle.js`) runbot-229803 Forward-Port-Of: odoo/odoo#247203
Changing the language for a syntax-highlighted code block now returns users directly to the code area so they can keep typing without an extra click. This removes a small interruption in the editing workflow and makes working with formatted code snippets smoother.
Original PR description
**Description of the issue:** - When a user changes the language of a syntax-highlighted code block, the editor loses focus from the code input. As a result, the user must manually click back into…
**Description of the issue:** - When a user changes the language of a syntax-highlighted code block, the editor loses focus from the code input. As a result, the user must manually click back into the code block to continue typing **Steps to reproduce:** - Insert a syntax-highlighted code block. - Click the language dropdown to change the syntax highlighting language. - Select a different language from the dropdown. The language dropdown closes correctly after selection. Focus does not return to the code block input. Instead, focus remains on the dropdown button. **Cause:** - Although focus is explicitly set back to the code block input after selecting a language, closing the dropdown restores focus to the element that was active when the dropdown was opened . As a result, the input does not receive focus. **Solution:** - For the language selector dropdown, set focusToggleOnClosed = false so that closing the dropdown does not restore focus to the dropdown button. - For the copy button, prevent focus on pointerdown. task-5785595
This fixes a timing issue in the website menu editor where the option to create a new page could fail to appear if a user saved a new menu item quickly. The system now rechecks whether the page exists after editing, so users get the correct next-step prompt when adding website menus.
Original PR description
Since commit 45e15673a70cf770d8e343a0a3b805eccdbed0d1, the information about whether a page of a menu exists is fetched asynchronously. Thus, when the dialog to change the url is closed to save the change, the value whether the page exists may not be in sync with the url. This commit checks the url again after the edit dialog is closed to correctly suggest to create a page. Steps to reproduce: - Open website builder - Click on the header - Click on "Edit Menu" - Click "Add new menu" - Type a title for which there is no existing corresponding page and _quickly_ click "Continue" - Bug: The button to suggest to create a page does not appears task-5474734
Vendor bill and refund payable lines now use the bill reference when no payment reference is entered. If a payment reference is later changed, the payable line label is updated too, improving clarity in accounting records and payment follow-up.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864 Forward-Port-Of: odoo/odoo#247191 Forward-Port-Of: odoo/odoo#221491
This update fixes an issue where opening chat during a meeting could cause the page to crash. Users can now use meeting chat reliably when typing indicators are shown, reducing disruption during online conversations.
Original PR description
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
The Website image gallery now keeps the height chosen by the user instead of reverting when images are reordered in a carousel. This makes page editing more predictable and prevents unintended layout changes on published website pages.
Original PR description
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The…
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281 Forward-Port-Of: odoo/odoo#242958 Forward-Port-Of: odoo/odoo#126766
This update corrects an issue where project forms, accessed through SmartButtons, were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing editing, ensuring users can now fully interact with project forms. The reason for this initial setting remains unclear.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#105225This update resolves an issue where toggling the Studio feature in Odoo Enterprise would sometimes disrupt the layout of form stat buttons. Now, the stat button layout remains consistent regardless of whether Studio is active, ensuring a better user experience when designing and editing forms.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309
This update resolves a technical problem with the way sale commission IDs were generated, preventing errors caused by IDs exceeding JavaScript's maximum safe integer limit. The change increases the range of IDs allowed for the 'plan_id' field, significantly expanding the number of commissions that can be tracked without causing errors. This improves system stability and scalability.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable.
This update corrects a technical issue causing duplicate Worldline receipts to be generated in POS transactions. The fix ensures receipts are only added when a transaction is fully completed, improving the accuracy of sales records. This resolves a reported problem impacting transaction reporting.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655
This update fixes an issue where appraisal templates couldn't select departments without a linked company. The fix ensures all departments are visible in the dropdown, improving usability and preventing employees from being restricted to departments with company associations. This resolves a bug impacting template configuration.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581This update resolves an issue that prevented the 'hr_expense_stripe' module from installing correctly in countries without Stripe integration (like Romania). The fix removes a redundant constraint that triggered the error, ensuring proper installation and functionality across all supported localizations.
Original PR description
[FIX] hr_expense_stripe: error when installing loca not supported Step to reproduce the bug: - install 'hr_expense_stripe' - try to install a localization where Stripe is not available (e. g. Romania) - The error raise This is due to an @api.constrains that can be removed no-task
This update adjusts the scheduling of a daily report generation process. By extending the cron interval to 9999 months, the automatic execution is disabled, preventing unnecessary database activity and improving system performance. This change ensures the real-time, trigger-based workflow remains efficient.
Original PR description
The cron interval is updated from 1 day to 9999 months to effectively Disable automatic execution. The workflow is fully real-time and trigger-based, and running this cron Daily would unnecessarily wake up registries and databases. task-5885482
This update fixes an issue where the quantity displayed after exiting a barcode MRP operation was not accurately reflecting the remaining quantities. Specifically, the system incorrectly handled move quantities when the operation was completed, leading to display discrepancies. This ensures accurate quantity tracking within the MRP process.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update resolves a bug that incorrectly flagged journal entries with mixed expense and revenue accounts (without deferred dates) as invalid. Previously, the system enforced a strict rule about matching deferred entry generation methods. Now, the validation only applies when actual deferred dates are configured, improving usability for common miscellaneous operations.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update resolves a bug where the POS ID wasn't correctly sent to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, and a related change restricts blackbox device selection in the POS configuration, improving data integrity and security.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update fixes a potential issue where bank reconciliation cron jobs would fail if notification emails couldn't be sent. Now, notifications are queued for later delivery, ensuring the cron job completes successfully and avoids rescheduling the next day. This improves the reliability of bank statement reconciliation.
Original PR description
[FIX] account_accountant: cron auto reconcile - mail notification concurency The aim of this commit is to prevent the cron from failing due to an issue in sending notification in the post_commit hook. Context: The issue was spotted on odoo.com while import bank statement transaction Before this commit: Failing to write on mail_notification during the post_commit hook could make the entire cron fail and be reschedule to the next execution date. (The next day by default) After this commit: The mail_notification are put in the mail queue to be sent later on. Task-id: None
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. Now, reloading the spreadsheet after deleting archived revisions correctly applies the most recent changes, ensuring data integrity and preventing data loss.
Original PR description
Steps to reproduce - create a spreadsheet - do a few changes - leave the spreadsheet (to snapshot) - reopen the spreadsheet - do a few more changes - from another tab, go to Settings/Technical/Revisions - delete all archived revisions - reload the spreadsheet => the last changes are lost and new changes are no longer saved.
This update resolves an issue where sign requests created on older Odoo versions (prior to 16.0) would fail due to missing communication company information. The fix automatically uses the user's company date format in these cases, ensuring sign requests can be processed without errors.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price charge products from the sync process, ensuring smoother integration with UrbanPiper.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a problem with Indian GST reports where test cases were failing due to a recent community fix. The test cases have been updated to correctly reflect the new label format that includes the bill reference, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update resolves a technical issue related to how time off is reported to the next month. A rounding error was causing incorrect work entries, preventing employees from properly deferring time off. This fix ensures accurate reporting and avoids potential payroll discrepancies.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours
This update fixes a bug that prevented users from accessing the signature request feature on mobile devices. The issue stemmed from a difference in how the action was displayed on mobile versus desktop, specifically related to the search view. This change ensures that all users can now initiate signature requests via the mobile app.
Original PR description
Steps:
- Install `industry_fsm`
- Be on mobile (via dev tools it's ok)
- Have minimum one task
- Go to My tasks
- Click on the first kanban record
- Cog Menu -> you don't have "Request signature"
- If you do the same on Desktop (or with a bigger screen) you will
In mobile view, the action only has the form view, so the search view is not loaded. This means that the condition checking that “message_ids” is in the search view does not work on mobile. This commit fixes the problem by using the model in the environment via `env.model.root.fields` to find `message_ids`.
opw-5485720