Daily updates from Odoo
Navigate
Branch
Monday, April 22, 2024
63 changes
2 changes
Miscellaneous changes
In this commit: ================== Invisible the 'Removal strategy' field when selecting the other location type except the Internal location. task-3555853 Forward-Port-Of: odoo/odoo#157888 Forward-Port-Of: odoo/odoo#154117
Original PR description
In this commit: ================== Invisible the 'Removal strategy' field when selecting the other location type except the Internal location. task-3555853 Forward-Port-Of: odoo/odoo#157888 Forward-Port-Of: odoo/odoo#154117
Description of the issue/feature this PR addresses: Without sudo, an user in a company can change the type even if somes not done stock.move.line exists. @amoyaux --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160856
Original PR description
Description of the issue/feature this PR addresses: Without sudo, an user in a company can change the type even if somes not done stock.move.line exists. @amoyaux --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160856
19 changes
Enhancements to existing features
Knowledge comments now save a short copy of the text or image area they refer to, so the comment remains understandable even if the original article content changes. Longer saved references can be expanded with a Read More option, improving collaboration and review clarity.
Original PR description
This commit adds the storage of text anchors for comments. Before this commit we didn't store the text's anchors and displayed it dynamically. The advantage of this approach is that we didn't need to store any text inside the DB for each comment => this could've led to big sums of data for not a big gain. The disadvantage is that if the anchor doesn't exist anymore and we lose the context of the comment. Now, a new field `article_anchor_text` stores up to 1200 characters of the anchor's text. When the anchor is longer than 50 chars we display a Read More button that will display the anchor's stored text. task-3672422
Electronic payment flows in Point of Sale now start automatically instead of waiting for extra cashier input. This speeds up checkout, reduces manual steps, and helps customers complete card payments more quickly.
Original PR description
- changed the functionality of the electronic payment button to be automatic instead of waiting for user input. TASK-ID: 2770467 Related: https://github.com/odoo/odoo/pull/153659
The delivery IoT settings screen now presents the Scales feature explanation more clearly. The text is better aligned with its section and separated from the documentation link, making the information easier for users to read.
Original PR description
This PR introduces two minor changes to `stock.picking.type` model: * align the explanation of "Scales" feature with its section. * add a line break between the explanation and the link to the documentation. COM PR: odoo/odoo#159495 Task-3644665
Employee managers now receive the right payroll-related access through their existing contract management role. This keeps payroll collaboration features, such as discussion chatter, limited to appropriate manager users and simplifies permission management.
Original PR description
Make hr_contract_employee_manager imply hr_payroll_employee_manager
Resolved issues and error corrections
This change makes an internal Web Studio test more stable by avoiding a check that depended on unpredictable background request timing. It helps prevent false failures in automated testing without changing user-facing behavior.
Original PR description
The test edit "one2many form view (2 level) and check chatter allowed" was sometimes failing (https://runbot.odoo.com/runbot/build/61498073) This was due to the ordering of some rpc calls in two different services. Those services do not depend on one another, so it is possible that in some situations, their instanciation and the rpc they pass happen in different order. After this commit this is not a problem because we simply don't assert the rpc "/mail/action".
Miscellaneous changes
We don't want to block deleting a journal because there is a rule targetting it. It prevents changing the CoA easily if a transfer model was created while loading the template. Forward-Port-Of: odoo/enterprise#60993 Forward-Port-Of: odoo/enterprise#59547
Original PR description
We don't want to block deleting a journal because there is a rule targetting it. It prevents changing the CoA easily if a transfer model was created while loading the template. Forward-Port-Of: odoo/enterprise#60993 Forward-Port-Of: odoo/enterprise#59547
Steps to reproduce: - Install account_sepa_direct_debit - Create another company - Go to "Invoicing / Configuration / Accounting / Journals" - Configure a journal (e.g. Bank) by adding an IBAN bank account number - Go to "Invoicing / Customers / Direct Debit Mandates" - Create a Direct Debit Mandate (DD Mandate): * Customer: [any customer with an IBAN bank account] (e.g. Gemini Furniture) * IBAN: [IBAN bank account of customer] * Journal: Bank * Start Date: [any] * Company:
Original PR description
Steps to reproduce: - Install account_sepa_direct_debit - Create another company - Go to "Invoicing / Configuration / Accounting / Journals" - Configure a journal (e.g. Bank) by adding an IBAN bank account number - Go to "Invoicing / Customers / Direct Debit Mandates" - Create a Direct Debit Mandate (DD Mandate): * Customer: [any customer with an IBAN bank account] (e.g. Gemini Furniture) * IBAN: [IBAN bank account of customer] * Journal: Bank * Start Date: [any] * Company: [the current company] - Save and validate the DD mandate - Switch to another company - Open Direct Debit Mandate list view Issue: The DD mandate from the other company is displayed. Any user who has access to DD mandates will view the DD mandates from all companies, even those from the companies he has no access. Cause: There is no multi-company rule for "sdd.mandate" model. opw-3769026 Forward-Port-Of: odoo/enterprise#59233
Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user. This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user. Steps to reproduce the issue ============================ 1. Create a new employee 2. Link that employee t
Original PR description
Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is…
Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user. This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user. Steps to reproduce the issue ============================ 1. Create a new employee 2. Link that employee to a new user 3. Remove the user to the employee (unset Linked user field) 4. Log in as that new user 5. Go to timesheets app Current Behavior ================ A traceback is occured because the rpc called returned an empty list instead of a list containing at least one object to get the billable target for the current user. Expected Behavior ================= The grid view of Timesheets app should be loaded as expected and the leaderboard should not be displayed since no data is found to get the billable target for that current user. opw-3862635 opw-3866805 opw-3864353 Forward-Port-Of: odoo/enterprise#61046 Forward-Port-Of: odoo/enterprise#60949
Issue: ------ If we remove the sale order line from a helpdesk ticket, and modify the partner (modify the `is_company` field), the sale order line will be added back to the ticket. Solution: --------- Assuming that this behaviour is due to a limitation in the ORM, it is necessary to modify the dependency of the compute method. This fix performs the same correction on the helpdesk side as the commit: https://github.com/odoo/odoo/commit/5faf5a0dcf4c06716d6a29686d49409b22b05565 opw-387
Original PR description
Issue: ------ If we remove the sale order line from a helpdesk ticket, and modify the partner (modify the `is_company` field), the sale order line will be added back to the ticket. Solution: --------- Assuming that this behaviour is due to a limitation in the ORM, it is necessary to modify the dependency of the compute method. This fix performs the same correction on the helpdesk side as the commit: https://github.com/odoo/odoo/commit/5faf5a0dcf4c06716d6a29686d49409b22b05565 opw-3879079 Forward-Port-Of: odoo/enterprise#61125
Currently, when downloading/loading Worldline lib at the start of Odoo, after doing so we are restarting Odoo at the end of "load_worldline_library.sh" script. This is unnecessary as Odoo is capable of detecting the terminals and communicating with them straight away when it has the library and the linker set up. More annoyingly, this leads to a very tricky bug: Odoo service is being restarted in a subshell. Since Odoo is already running this 2nd service will be blocked, but as soon as t
Original PR description
Currently, when downloading/loading Worldline lib at the start of Odoo, after doing so we are restarting Odoo at the end of "load_worldline_library.sh" script. This is unnecessary as Odoo is capable of detecting the terminals and communicating with them straight away when it has the library and the linker set up. More annoyingly, this leads to a very tricky bug: Odoo service is being restarted in a subshell. Since Odoo is already running this 2nd service will be blocked, but as soon as the primary Odoo service stops, the 2nd one takes the lead. So when restarting Odoo we can get error like "Adress already in use", duplicate code executed and even more dangerousely, duplicate C++/C code running with Worldline and Six, which can lead to race conditions and crashes. task-3873045 Forward-Port-Of: odoo/enterprise#60865
This commit removes the unnecessary "-" (minus) that was mistakenly added before `inputs['ATTACH_SALARY'].name`. This addition was causing a traceback error. task-3794116 Forward-Port-Of: odoo/enterprise#58566
Original PR description
This commit removes the unnecessary "-" (minus) that was mistakenly added before `inputs['ATTACH_SALARY'].name`. This addition was causing a traceback error. task-3794116 Forward-Port-Of: odoo/enterprise#58566
This commit addresses a computed asset failure caused by the inclusion of 'web.editor.frontend.scss' in the 'sign' module manifest since [1] (OWL conversion). A scss variable added in 'fontawesome_overriden.scss' by a related community PR is used in 'web.editor.frontend.scss', leading to a crash during asset computation. This file is now added in the manifest. Related community PR: - https://github.com/odoo/odoo/pull/161770 opw-3747848 [1]:https://github.com/odoo/enterprise/commit/5fa
Original PR description
This commit addresses a computed asset failure caused by the inclusion of 'web.editor.frontend.scss' in the 'sign' module manifest since [1] (OWL conversion). A scss variable added in 'fontawesome_overriden.scss' by a related community PR is used in 'web.editor.frontend.scss', leading to a crash during asset computation. This file is now added in the manifest. Related community PR: - https://github.com/odoo/odoo/pull/161770 opw-3747848 [1]:https://github.com/odoo/enterprise/commit/5fa63a2f284fe93acc0c4d8dc12ee47646703247 Forward-Port-Of: odoo/enterprise#60922 Forward-Port-Of: odoo/enterprise#60894
When using the command palette of Knowledge in dev mode, the system raises the following exception: `Invalid props for component 'Knowledge404Command': unknown key 'name', unknown key 'searchValue', unknown key 'executeCommand', unknown key 'slots'.` To fix the issue, `Knowledge404Command` and `KnowledgeCommand` will extend `DefaultCommandItem` and its props, ensuring that the required props will be maintained in future updates. task-3862285 Forward-Port-Of: odoo/enterprise#60461
Original PR description
When using the command palette of Knowledge in dev mode, the system raises the following exception: `Invalid props for component 'Knowledge404Command': unknown key 'name', unknown key 'searchValue', unknown key 'executeCommand', unknown key 'slots'.` To fix the issue, `Knowledge404Command` and `KnowledgeCommand` will extend `DefaultCommandItem` and its props, ensuring that the required props will be maintained in future updates. task-3862285 Forward-Port-Of: odoo/enterprise#60461
Current behavior: When trying to sell a product with a tax, you get an error saying the tax is not allowed. Also some other things were not working properly after this refactor, https://github.com/odoo/odoo/pull/142566. Like `res_company` should be `this.company` Steps to reproduce: - Setup fiskaly - Create a product with a tax - Try to sell it in PoS opw-3845699 Forward-Port-Of: odoo/enterprise#61051 Forward-Port-Of: odoo/enterprise#60074
Original PR description
Current behavior: When trying to sell a product with a tax, you get an error saying the tax is not allowed. Also some other things were not working properly after this refactor, https://github.com/odoo/odoo/pull/142566. Like `res_company` should be `this.company` Steps to reproduce: - Setup fiskaly - Create a product with a tax - Try to sell it in PoS opw-3845699 Forward-Port-Of: odoo/enterprise#61051 Forward-Port-Of: odoo/enterprise#60074
Commit [1] removed the "Odoo -" prefix in the title of the backend. As a consequence, there was no title left in the home menu, and the url was displayed instead. This commit defines "Home" as title of the HomeMenuAction. [1] odoo/odoo@f3e809a6b7076065e46e466019be4b6b0325371c Forward-Port-Of: odoo/enterprise#61120
Original PR description
Commit [1] removed the "Odoo -" prefix in the title of the backend. As a consequence, there was no title left in the home menu, and the url was displayed instead. This commit defines "Home" as title of the HomeMenuAction. [1] odoo/odoo@f3e809a6b7076065e46e466019be4b6b0325371c Forward-Port-Of: odoo/enterprise#61120
Before this commit, when a confirmed order was canceled, a draft quote subscription_state was set. It would trigger the constraint `sale_subscription_state_coherence` or _constraint_canceled_subscription depnding the version. THis commits ensure to clean the subscription_state of canceled subscription and it set it back to the correct value if the canceled order is set back to quotation. Forward-Port-Of: odoo/enterprise#61053 Forward-Port-Of: odoo/enterprise#60908
Original PR description
Before this commit, when a confirmed order was canceled, a draft quote subscription_state was set. It would trigger the constraint `sale_subscription_state_coherence` or _constraint_canceled_subscription depnding the version. THis commits ensure to clean the subscription_state of canceled subscription and it set it back to the correct value if the canceled order is set back to quotation. Forward-Port-Of: odoo/enterprise#61053 Forward-Port-Of: odoo/enterprise#60908
Before this commit, there was an issue with the line's buttons for the Inventory Adjustment in the Barcode app. The -1/+1 buttons were placed above/below each other instead of being on the same line, causing the edit button and the set button to be misplaced on the left. This commit fixes that, now these buttons will be placed correctly: - On the same height if there is only two buttons; - On two lines if there is four buttons. #### On Desktop - Before:  - After:  #### On mobile - Before:  - After:  Forward-Port-Of: odoo/enterprise#60769
## Description Validating invoices that have a lot of lines that needs to be deferred is taking extremely long time. Most of the bottleneck is from `_generate_deferred_entries`. We've batched some of the ORM calls to avoid repetitive calls to slow methods in `account_move` like `create`, `__set__`, `_post`. ## Benchmark Tested on a saas-16.4 DB: validating an invoice with deferred lines generating on average 12 periods per line | Lines | Before (Timing / Queries) | After (Timing / Qu
Original PR description
## Description Validating invoices that have a lot of lines that needs to be deferred is taking extremely long time. Most of the bottleneck is from `_generate_deferred_entries`. We've batched some of the ORM calls to avoid repetitive calls to slow methods in `account_move` like `create`, `__set__`, `_post`. ## Benchmark Tested on a saas-16.4 DB: validating an invoice with deferred lines generating on average 12 periods per line | Lines | Before (Timing / Queries) | After (Timing / Queries) | % Speed up | |-------|-------------------------------|--------------------------|------------| | 50 | 1 min / 23216 | 33.4 sec / 16713 | 44.3% | | 100 | 3 min / 46736 | 1.3 min / 33557 | 56.7% | | 230 | 17.7 min (timed-out) / 111196 | 3.4 min / 79777 | 80.7% | ## Reference opw-3815242 Forward-Port-Of: odoo/enterprise#59448
Steps to reproduce: ------------------- - create a product with: - recurring - prepaid - create task on order - in the settings, enable "Recurring Tasks" - add "Use Recurring Tasks" to the current user - create a sale order with a recurring plan and the recurring product - confirm the sale order --> the created task is recurring - duplicate the sale order - validate it with a portal user Issue: ------ The task created is not recurring. The two tasks should be recurrent because the
Original PR description
Steps to reproduce: ------------------- - create a product with: - recurring - prepaid - create task on order - in the settings, enable "Recurring Tasks" - add "Use Recurring Tasks" to the current user - create a sale order with a recurring plan and the recurring product - confirm the sale order --> the created task is recurring - duplicate the sale order - validate it with a portal user Issue: ------ The task created is not recurring. The two tasks should be recurrent because the sale order is the same. The user who confirms the sale order must not affect the status of the task. Cause: ------ We check that the user belongs to the `group_project_recurring_tasks` group, which will never be the case for a portal user. Solution: --------- Authorise the creation of the recurring task if the setting is activated. opw-3823250 Forward-Port-Of: odoo/enterprise#60807
42 changes
Security fixes and vulnerability patches
Fixed a security issue where users could view Direct Debit Mandates from companies they don't have access to. The system now properly restricts mandate visibility based on company permissions, ensuring users only see mandates from their authorized companies.
Original PR description
Steps to reproduce: - Install account_sepa_direct_debit - Create another company - Go to "Invoicing / Configuration / Accounting / Journals" - Configure a journal (e.g. Bank) by adding an IBAN bank account number - Go to "Invoicing / Customers / Direct Debit Mandates" - Create a Direct Debit Mandate (DD Mandate): * Customer: [any customer with an IBAN bank account] (e.g. Gemini Furniture) * IBAN: [IBAN bank account of customer] * Journal: Bank * Start Date: [any] * Company: [the current company] - Save and validate the DD mandate - Switch to another company - Open Direct Debit Mandate list view Issue: The DD mandate from the other company is displayed. Any user who has access to DD mandates will view the DD mandates from all companies, even those from the companies he has no access. Cause: There is no multi-company rule for "sdd.mandate" model. opw-3769026 Forward-Port-Of: odoo/enterprise#59233
New functionality added to Odoo
This update adds support for Vietnam's VAT exemption tax category to Odoo's accounting system. The change enables businesses operating in Vietnam to properly classify and track VAT-exempt goods and services, including agricultural products, small business services, financial services, and other categories defined by Vietnamese tax regulations. This ensures accurate tax reporting and compliance for Vietnamese companies.
Original PR description
This commit add a new tax call VAT exemption, read more at https://taxsummaries.pwc.com/vietnam/corporate/other-taxes to understand its usage 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
Enhancements to existing features
This update significantly speeds up the process of validating invoices with deferred expense lines. By optimizing how the system processes multiple deferred entries, validation times are reduced by 44-81% depending on the number of lines, making it much faster to process complex invoices with deferred accounting items.
Original PR description
## Description Validating invoices that have a lot of lines that needs to be deferred is taking extremely long time. Most of the bottleneck is from `_generate_deferred_entries`. We've batched some of the ORM calls to avoid repetitive calls to slow methods in `account_move` like `create`, `__set__`, `_post`. ## Benchmark Tested on a saas-16.4 DB: validating an invoice with deferred lines generating on average 12 periods per line | Lines | Before (Timing / Queries) | After (Timing / Queries) | % Speed up | |-------|-------------------------------|--------------------------|------------| | 50 | 1 min / 23216 | 33.4 sec / 16713 | 44.3% | | 100 | 3 min / 46736 | 1.3 min / 33557 | 56.7% | | 230 | 17.7 min (timed-out) / 111196 | 3.4 min / 79777 | 80.7% | ## Reference opw-3815242 Forward-Port-Of: odoo/enterprise#59448
Payment system log messages now clearly indicate whether a payment request was initiated by a customer or by the system. This improvement makes it easier for business users and support teams to understand payment activity and troubleshoot issues by providing better visibility into who triggered each payment request.
Original PR description
Before this commit: ------------------------- the log message did not clearly indicate who attempted to request a payment. After this commit: ----------------------- the message specifies whether the payment request was initiated by the customer or by the system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The chatter (comments section) in the Documents app was taking up excessive screen space and causing content to overflow, resulting in a poor user experience. This fix removes an outdated styling rule and reuses the proper layout styles from the form view, allowing the chatter to wrap and display correctly without overwhelming the page.
Original PR description
The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX. This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed. Also we actually want to reuse most style of chatter in form view. This commit adds `o-mail-ChatterContainer` classname on same HTML node as `o-mail-Form-Chatter` and adapts style, so that Document can set this classname to reuse style. opw-3681435 https://github.com/odoo/odoo/pull/161940 Before  After 
Fixed an issue where the document preview window remained open even after users changed workspaces, applied filters, or modified tags. The preview now automatically closes when the displayed documents change, preventing users from viewing outdated content. This improves the user experience by keeping the interface in sync with the current document selection.
Original PR description
How to reproduce: - Go to documents - Click on a workspace with documents - Click on a document to preview it - Click on another workspace/select a tags/select a tag group, change the filter/domain The preview is still displayed but shouldn't as we can't see the content of the newly selected/filtered. This fix ensures that the preview is closed in such circumstances. Technical note: the event was already trigerred but on the wrong bus. This fix triggers it on the right one. Solving this problem introduces a new bug because when the new filter excludes the document selected, the first selection is unselect while there are no selection anymore. in that case, we just skip that operation. Task-3624235 Forward-Port-Of: odoo/enterprise#60718 Forward-Port-Of: odoo/enterprise#57237
This fix removes a restriction that prevented users from deleting accounting journals when automatic transfer rules were targeting them. This change makes it easier for businesses to modify their Chart of Accounts structure without being blocked by transfer models created during template setup.
Original PR description
We don't want to block deleting a journal because there is a rule targetting it. It prevents changing the CoA easily if a transfer model was created while loading the template. Forward-Port-Of: odoo/enterprise#59547
Removed an unnecessary Odoo service restart that was occurring when loading the Worldline payment library. This restart was causing duplicate Odoo instances to run simultaneously, leading to system errors like "Address already in use" and potential crashes. The fix ensures the system runs smoothly without these conflicts.
Original PR description
Currently, when downloading/loading Worldline lib at the start of Odoo, after doing so we are restarting Odoo at the end of "load_worldline_library.sh" script. This is unnecessary as Odoo is capable of detecting the terminals and communicating with them straight away when it has the library and the linker set up. More annoyingly, this leads to a very tricky bug: Odoo service is being restarted in a subshell. Since Odoo is already running this 2nd service will be blocked, but as soon as the primary Odoo service stops, the 2nd one takes the lead. So when restarting Odoo we can get error like "Adress already in use", duplicate code executed and even more dangerousely, duplicate C++/C code running with Worldline and Six, which can lead to race conditions and crashes. task-3873045 Forward-Port-Of: odoo/enterprise#60865
This fix resolves an issue where reversed payments created after a POS session closes were not being properly matched with invoices, causing incorrect aged receivables to appear in accounting reports. The fix ensures that when an order is invoiced after session closure, the reversed payment is correctly reconciled with the invoice, eliminating false outstanding balances for customers.
Original PR description
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for the aged receivable report you should see some entries under the partner you selected. - You can also go to the partner form and see that he has some due invoices. opw-3678298 Forward-Port-Of: odoo/enterprise#60248
This fix ensures that company VAT information is properly included when exporting financial reports to PDF format. Previously, VAT details were missing from PDF exports when tax units were not being used. Now the system correctly displays either company VAT or tax unit VAT depending on your configuration.
Original PR description
Before this commit: When exporting a report to a pdf if we were not using tax units there was no VAT After this commit: When exporting a report as pdf company VAT is shown if no tax unit is used. If we are using tax units, then tax units VAT will be shown instead task: 3864218 see: #58361 Forward-Port-Of: odoo/enterprise#61023 Forward-Port-Of: odoo/enterprise#61011
This fix ensures that the manufacturing picking type option for component lot creation is now properly recognized and applied during production work orders. Previously, this setting was being ignored because the system wasn't always able to identify which production order was active. This fix restores the intended functionality so that your configured picking type preferences are respected.
Original PR description
The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified.
This fix resolves a bug where removing a sale order line from a helpdesk ticket would cause it to be automatically re-added when the customer information was updated. The change corrects how the system tracks dependencies between helpdesk tickets and sale orders, ensuring that manual removals are properly respected.
Original PR description
Issue: ------ If we remove the sale order line from a helpdesk ticket, and modify the partner (modify the `is_company` field), the sale order line will be added back to the ticket. Solution: --------- Assuming that this behaviour is due to a limitation in the ORM, it is necessary to modify the dependency of the compute method. This fix performs the same correction on the helpdesk side as the commit: https://github.com/odoo/odoo/commit/5faf5a0dcf4c06716d6a29686d49409b22b05565 opw-3879079
Fixed an issue where Facebook stickers sent in comments were appearing as blank bubbles in the feed. Now stickers display properly as images. When a comment contains only a sticker without text, it will show without the blue message bubble for a cleaner appearance.
Original PR description
Purpose ======= Currently, if someone sends a sticker in a Facebook comment, a blank bubble is displayed in the feed view. Instead we want to display the sticker. Task-3595484 Forward-Port-Of: odoo/enterprise#54188
This fix resolves a frustrating issue where users couldn't reserve products in a Make-to-Order chain after moving inventory with immediate transfers. The system was looking for products in their original location, but they had been moved elsewhere. The fix updates the reservation logic to properly handle moved products and maintain accurate inventory tracking.
Original PR description
A lot of users don't understand why they can't reserve after moving a product with an immediate transfer. It's due to the double check of _action_assign that check where the move orig stored the product and check the quants for this exact location. In our case the product was moved so the match doesn't work. We introduce an new parameter to check if modifying the behavior on those cases would work. When _free_reservation is call on a move.line we expect to never find it at this place anymore (except if we bring it back). Then we drop the reservation base on MTO process and only check if there is a quantity in a sub location of the stock.move 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 Forward-Port-Of: odoo/odoo#154912
Forum comments were appearing too close together, making them difficult to distinguish visually. This fix adds proper spacing between comments on forum posts, improving readability and the overall user experience when viewing discussions.
Original PR description
task-3870118 -------------------- This PR aims to fix an issue on forum posts, about comments being placed directly next to each other without having a gap between them, making it harder to visually recognize items at first glance. To handle this issue, we simply add a `d-flex gap-x` utility classes to ensure these elements receive some spacing between them. | 17.0 | 17.0-fix-forum-comment-spacing-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/a86dd9d7-37e4-4783-8d7f-73bdc6605edf"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/f253452a-3b52-499f-a7c2-4d3e102ab5a4"> |
This fix resolves a crash that occurred when users clicked the "Set Location" button in the calendar view. The issue affected users of the HR Homeworking and Appointment modules. The underlying cause was incomplete error handling in the calendar code, which has now been corrected to prevent the application from crashing in this scenario.
Original PR description
17.0 saas~17.1 Steps to reproduce: - install `hr_homeworking` - open calendar and click on "Set Location" - it will give a traceback (same thing can be checked by installing `appointment` too) Cause: if condition in `onDateClick` method is missing one edge case where `info.jsEvent` can be undefined. Fix: handled missing edge cases in `onDateClick` method. task-3790418
This fix improves the French FEC financial report by removing unnecessary zero-balance lines from the initial balance section. Previously, when businesses had many settled transactions from previous periods (common in e-commerce with thousands of customers), the report would include thousands of zero-balance lines that added no value. Now only accounts with actual balances are included, making reports cleaner and more manageable.
Original PR description
**Description of the issue/feature this PR addresses:** Before this PR initial balance include line with a null balance. In database with lot of partner (e-commerce), the initial balance balance are huge. - Create e-commerce - Sale and invoice to 100 000 different customer in 2023, all invoice are paid - In 2024 extract a FEC --> Issue : in the initial balance there are 100 000 lines with a zero balance. This lines don't need to be included in the FEC. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160639 Forward-Port-Of: odoo/odoo#141321
This update resolves display problems in the Time Off module's forms across multiple views (Gantt, Calendar, and standard form). The status bar no longer overlaps with content and text is properly displayed without truncation, improving the user experience when managing time off requests.
Original PR description
With this commit, on several form view (gantt, calendar and form view) the status bar does not overlap and the text is no longer truncated. task-3849814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an inconsistency where invoice previews in the customer portal displayed as final invoices, but downloads showed draft/proforma versions. Now the preview correctly displays as a draft invoice, matching what customers will actually download. This ensures transparency and prevents confusion about invoice status before official approval.
Original PR description
Issue ----- If an invoice is created, but not yet "Send & Print", the portal preview shows a normal invoice, but when "Download"ed from the portal preview, a proforma invoice is downloaded. The download behavior is intended since the client shouldn't be able to get a "final" invoice themselves, before the accountant generates one with "Send & Print". However, the HTML preview should also show a proforma invoice to be consistent with this, so the user downloads what they see. Steps ----- - Create a new invoice: Accounting -> Customers -> Invoices -> New -> ... - Go to portal by clicking on "Preview". - You'll see a normal invoice. Now click "Download". - A proforma invoice is downloaded. Cause ----- The HTML-rendered invoice in the portal preview isn't configured to be proforma. opw-3848049
This fix resolves an issue where updating purchase order quantities could cause errors when a purchase order has multiple open shipments. The system now correctly identifies which shipment to update based on the specific order line being modified, rather than always using the first available shipment. This ensures accurate inventory management and prevents processing errors in complex purchase scenarios.
Original PR description
Description of the issue/feature this PR addresses: In systems were POs can have multiple open pickings, updating the Purchase quantities can lead to errors due to the current behaviour. Current behavior before PR: Before the fix, the picking used to create the new stock moves resulting from changes in the purchased quantity is simply taking the first available picking of the Purchase. This causes problems when you handle Purchase Orders with multiple open pickings, as the correct picking to use when the quantity is updated is not always taken. Desired behavior after PR is merged: After the fix we give priority to evaluate open pickings already related to the line we are updating. We fallback to the same behaviour as before is none is available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161452
The chatter (messaging panel) in the Documents app was taking up excessive screen space and causing content to overflow, resulting in a poor user experience. This fix removes an outdated styling rule and reorganizes the CSS classes to properly allow the chatter to wrap and flex, making better use of available space and improving the overall layout.
Original PR description
The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX. This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed. Also we actually want to reuse most style of chatter in form view. This commit adds `o-mail-ChatterContainer` classname on same HTML node as `o-mail-Form-Chatter` and adapts style, so that Document can set this classname to reuse style. opw-3681435 https://github.com/odoo/enterprise/pull/60772 Before <img width="1278" alt="before" src="https://github.com/odoo/odoo/assets/6569390/ec3c2004-dee2-4367-85bf-0806e07cb424"> After <img width="1280" alt="after" src="https://github.com/odoo/odoo/assets/6569390/0bcdc4af-0487-46e7-a245-4aa37028ead6">
This update removes a reference to an outdated app action feature that was removed in version 17.0. The change prevents installation errors in the configuration installer module, which was using this deprecated feature. This is a cleanup fix that ensures the system installs smoothly without encountering errors related to removed code.
Original PR description
Since 17.0, the tag `apps` of ir.action.client was removed with the legacy code of javascript. This commit removes the only usage in `res.config.installer` (not used in standard) to avoid a traceback at install. Fixes #160293
This update allows users to change the chart of accounts template even when using demo data. Previously, the system prevented these changes to maintain data safety. Now, demo mode users can freely switch chart templates without restrictions, making product demonstrations smoother and ensuring accounting tests run reliably regardless of when templates are loaded.
Original PR description
When in demo mode, we always want to be able to change the CoA * to remove friction when demoing: no need to be overly safe * to ensure that `test_all_l10n` always works even if we load a CoA in `<res.company>.create` 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 Forward-Port-Of: odoo/odoo#159488
This fix ensures that discounts applied to sales orders are now properly displayed when printing DDT (Documento di Trasporto) delivery reports in Italy. Previously, discounts were missing from the printed reports even though they were applied to the original quotation, which could cause confusion about the actual pricing on delivery documents.
Original PR description
Issue: Discounts are not displayed in DDT Steps to reproduce: - create a quotation with a sale line having a discount - smart button delivery > set qty > validate - Print Ticket link: [odoo/task#3745866](https://www.odoo.com/web#model=project.task&id=3745866) opw-3745866 Forward-Port-Of: odoo/odoo#159325
This fix resolves an issue where users couldn't create return pickings for products with very small quantities (like 0.01 grams). The system was incorrectly rejecting valid returns with an error message. The fix corrects how the system checks whether a quantity is zero, ensuring small but valid quantities are properly recognized.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” - UoM: gram - Create an internal picking with 0.01g of P1 - Validate the picking - Create a return and try to validate it Problem: A UserError is triggered: “Please specify at least one non-zero quantity.” When creating a return, we check if the quantity is not zero using the “float_is_zero” function, but we mistakenly use rounding as precision_digits. opw-3862142
This fix ensures that when an administrator logs in for the first time without demo data, the default working calendar automatically uses the admin's timezone instead of defaulting to UTC. This provides a better out-of-box experience by aligning the system calendar with the user's location from the start.
Original PR description
Steps to reproduce: ------------------- 1. Install the resource module without demo data (or install any module which depends on it, again without demo data). 2. Login with the administrator user for the first time. 3. The default resource calendar (e.g. "Standard 40 hours/week") timezone will be set to 'UTC' by default while it should be set to the timezone of the administrator. Fix: ------------------- When there is no demo data, no resource_calendar_id is linked to the admin. In this case, we need to retrieve the record of the default working calendar and set its timezone to the one of the admin user on the first login. This is a follow-up of this fix: https://github.com/odoo/odoo/pull/84258 task-3793313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157583
This fix ensures that plain text email templates display properly in Apple Mail by preserving padding around the email content. Previously, padding was lost during email conversion because of how the email layout was structured. The solution wraps the email content in a way that Apple Mail recognizes, ensuring emails don't appear cramped in the corner while maintaining compatibility with other email clients.
Original PR description
Most e-mail clients apply some padding around their e-mails, like mass_mailing does in its editor. So for the plain text email template, we mostly don't want to transfer that padding, but for Apple…
Most e-mail clients apply some padding around their e-mails, like mass_mailing does in its editor. So for the plain text email template, we mostly don't want to transfer that padding, but for Apple Mail we do want some padding lest the e-mail be crammed in a corner. The editor's padding was lost in conversion because the padding was applied to a table with `border-collapse: collapse` so it was not applied (see [mdn]). Since we can't change that property (or layouts will be broken), our remaining option is to wrap the layout table's contents in a `div` and apply the padding to it instead. Since we only want this for Apple Mail, we apply it in a nested media query, which Apple Mail is currently the only client to support. This is the only known way to target Apple Mail specifically but since e-mail clients tend to be remarkably slow at adopting new technologies, this should be safe for a while. [mdn]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-collapse task-3062027 Co-authored-by: David Monjoie <dmo@odoo.com> Forward-Port-Of: odoo/odoo#105661
This fix resolves an error that occurred when users tried to re-enable the blog page's top banner option after adding custom content blocks. The fix ensures that the banner option works correctly regardless of what other content has been added to the page, improving the user experience when customizing the blog layout.
Original PR description
Before this commit an error appeared if a block had been set at the top of the /blog page and the user wished to re-enable the 'Top banner - Name / Latest Post' option. This commit resolves the issue by giving higher priority to the activated view. Steps to reproduce the fixed bug: - Go on /blog page - Disable the customize option "Top banner - Name / Latest Post" - Enter in edit mode - Add a snippet to the top (in the oe_structure) - Save the page - Enable the customize option "Top banner - Name / Latest Post" => An error happens. task-2774944 Forward-Port-Of: odoo/odoo#162519 Forward-Port-Of: odoo/odoo#92022
This fix corrects how discounted prices are displayed on product pages and search results in the online store. Previously, when price comparison settings were disabled, no strikethrough price was shown even when products had discounts. Now the system correctly displays the original list price as a strikethrough, making it clearer to customers what the original price was before the discount.
Original PR description
Previously, if a product had `price < list_price` and `price < compare_list_price`, but `website_sale.group_product_price_comparison` unset, no strikethrough price was shown. However, in that case, we should show `list_price` as the strikethrough price. Previously, in the search dropdown, `compare_list_price` was only shown as the strikethrough price if `price < list_price` (which is unrelated). This change make it consistent with the product page. opw-3845926 Forward-Port-Of: odoo/odoo#161473
This fix ensures that the manufacturing picking type option for creating component lots is now properly recognized and applied. Previously, this setting was being ignored because the system wasn't always reading the correct production order context. Users will now see the appropriate serial number and lot generation buttons based on their picking type configuration.
Original PR description
The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. 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 update prevents confusing error messages from appearing to users when they collaborate on editing documents in real-time. The errors were harmless technical issues that didn't affect the actual collaboration, but were being displayed to users. Now these errors are quietly logged instead, providing a cleaner user experience.
Original PR description
__Current behavior before commit:__ Sometimes the following tracebacks are popping up when an RTC connection is being established between two users trying to edit the same document. ```log…
__Current behavior before commit:__ Sometimes the following tracebacks are popping up when an RTC connection is being established between two users trying to edit the same document. ```log InvalidStateError: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Called in wrong signalingState: stable ``` ```log InvalidStateError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Called in wrong signalingState: stable ``` __Description of the fix:__ These errors are not blocking and don't impact the successful ensuing RTC connection. Thus, we can just catch the error and log it in the console instead of showing it to the user. __Steps to reproduce the issue (in 17):__ - Go to a knowledge article - Open a new tab and open the same article - On this new tab, quit the article and come back multiple times Eventually a traceback will appear on one of the tab. Note that this error seems to occur very randomly. It is similar to the one dealt by [this commit][1] and it is probably due to a similar cause i.e. a browser bug when the RTC connection is under stress. It is however possible to trigger it in a more consistent way by calling [_createClient][2] repeatedly. opw-3778272 [1]: https://github.com/odoo/odoo/pull/158861/commits/0eca324 [2]: https://github.com/odoo/odoo/blob/a1afcc8/addons/web_editor/static/src/js/wysiwyg/PeerToPeer.js#L374 Forward-Port-Of: odoo/odoo#161518
Internal users can now successfully download calendar invitation files (.ics) that were previously blocked by access restrictions. This fix ensures that when employees are invited to calendar events, they can properly access and download the invitation details from their notifications without encountering errors.
Original PR description
Access rights on ir.attachment depend on the record it is linked to. steps to reproduce: - log as admin - create a calendar event and invite marc demo - log as marc demo - check discuss notifications and try to download "invite.ics" before this commit: - file can not be downloaded from the webclient (access error appear in logs) after this commit: - file can be downloaded from the webclient opw-3754798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162502 Forward-Port-Of: odoo/odoo#160811
This fix improves how Odoo handles inventory updates for products that are tracked by lot or serial numbers. Previously, the system could incorrectly prioritize empty inventory records over records with actual quantities, leading to inaccurate stock levels. The fix ensures that when updating inventory, the system correctly updates existing stock quantities instead of creating or updating empty records.
Original PR description
In case a quant for a product tracked by lot/sn exists but without any lot/sn set and have some quantity, `_action_done()` should update it instead of a quant with the correct lot but without any quantity 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 Forward-Port-Of: odoo/odoo#160698 Forward-Port-Of: odoo/odoo#159935
This fix resolves language translation problems in the chatbot test page when users interact with a chatbot in a different language than their account settings. Chatbot responses for multiple-choice questions and email validation were incorrectly displaying in the user's language instead of the selected chatbot language, creating a confusing experience for multilingual support teams.
Original PR description
This PR fixes two translation issues when launching a chat bot with a different language than the user's: - Wrong translation for `question_selection` answers - Wrong translation for the…
This PR fixes two translation issues when launching a chat bot with a different language than the user's: - Wrong translation for `question_selection` answers - Wrong translation for the `question_email` answers 1. The answers to a `question_selection` could be mistranslated because the `post_welcome_steps` method overwrites the context's language when calling `message_post`. As a result, the `discuss.channel/new_message` notification would have the wrong answers format. Steps to reproduce the issue: - Go to the test chat bot page - Switch the website language to the one that is not used by the user. - Check the return result of `post_welcome_steps`: answers are in the correct language. - Check the corresponding `discuss.channel/new_message` notification received through the websocket: the language is the one of the user. 2. The chat bot language is not specified when calling the `validate_email` route so the lang is the one of the user by default. Steps to reproduce the issue: - Go to the chatbot test page - Activate another language than the one of the user - Select "I have a pricing question" with no operator available - Enter an invalid email - The answer is in the user's language while it should not opw-3862125
This fix resolves an issue where reversed payments created during late invoicing were not properly matched with invoices, causing incorrect aged receivables to appear for customers. When an order is invoiced after the session closes, the payment is now correctly reconciled, ensuring accurate financial records and customer account status.
Original PR description
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for the aged receivable report you should see some entries under the partner you selected. - You can also go to the partner form and see that he has some due invoices. opw-3678298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156527
This fix resolves an issue where the system was unable to properly identify and reuse similar attachments due to a logic error in the search mechanism. The fix restores the correct parameter handling that was accidentally broken in a previous update, allowing the system to efficiently find matching attachments and avoid unnecessary duplication.
Original PR description
While searching for a similar attachment, as the fallback url pattern is the same as the url pattern, the condition is never satisfied. With this commit, the ignore_params parameter is used to find a similar attachment. This was broken in a previous refactoring, `ignore_params=True` was added at the wrong place breaking this mechanism. We also don't have to recompute the url in this case. If we didn't ignore the version, the url_pattern should be the exact url. A test was adapted to test this fix.
This fix addresses an issue where newly added records in embedded lists within form views were not visible to users. The problem occurred because some lists had an invalid "editable" setting that prevented the system from temporarily expanding the page to display new records. The fix ensures these lists now behave correctly, matching the behavior of properly configured lists.
Original PR description
A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not list…
A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not list inside form views. When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added to be dusplayed on the current page, like it would be in editable="bottom" lists, so the user doesn't see the record he just added. The issue can be observed in the stock move form view for instance. This commit is only good for stable versions: we add a fallback on "bottom" s.t. if the editable attribute is set, it's always either "top" or "bottom". In master, we'll probably rethink the API. opw~3860903 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 update prevents incorrect inventory quantity updates for kit products (products made from component parts). The fix ensures the system properly checks whether a product is a kit, even when users don't have access to bill of materials information or when kits exist in different company divisions. This prevents data inconsistencies in inventory management.
Original PR description
using sudo().is_kits to account for user not having access to the bom module and boms in different companies Forward-Port-Of: odoo/odoo#161124
This update corrects an incorrect partner ID reference in the expense module's test file. The fix ensures that tests use the correct partner information, improving test reliability and accuracy for the HR Expense feature.
Fixed an issue where duplicating tasks in projects would incorrectly reset their status to "In Progress" regardless of their original status. Now when you duplicate a task, it retains its original status (such as "Approved"), making task management more predictable and reducing manual corrections needed after duplication.
Original PR description
Current Behavior: Tasks with or without dependent tasks and a state not in closed states have their state changed to `01_in_progress` when duplicated. previous PR that changed this logic: #139249 Purpose of this PR: To retain the state of the original task when duplicated. Steps to Reproduce in Runbot: 1) Enable Task Dependencies in Settings 2) Create a Project with Task A 3) Set state of Task A to 'Approved' 4) Duplicate Task A > Task A will now have a state of 'In Progress' Note: This PR does not remove the changes of duplicating projects. opw-3836251 Forward-Port-Of: odoo/odoo#161778
This update fixes an issue where user avatars appeared stretched or distorted when multiple people were editing content together. The fix ensures that avatars maintain their proper square shape regardless of the original image format uploaded by users, improving the visual appearance of the collaborative editing interface.
Original PR description
task-3877841 ------------------ This PR fixes an issue occurring in the `web_editor` when multiple users edit some content. Prior to this commit, the user avatar was not using any aspect-ratio rule, resulting in a stretch avatar if the uploaded image wasn't square. This commit fixes this issue by adding the `o_object_fit_cover` class to the image, ensuring a correct ratio no matter the format of the uploaded image. | 16.0 | 16.0-fix-editor-avatar-ratio-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/4de8281f-3469-4e29-b0fa-286f31483d5e"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/eeea593a-090c-4c97-bc07-4d89bbdfa67f"> | Forward-Port-Of: odoo/odoo#162743
This update fixes a technical error in the accounting chart template system that was preventing fiscal position adjustments from being processed correctly. The fix resolves a bug introduced in a previous update that was causing the system to crash when handling certain accounting configurations.
Original PR description
PR odoo/odoo#157918 has a bug on commit 8bd8d4a3eaf. We cannot do `int(x) in Command` as it's TypeError.