Thursday, March 7, 2024
24 changes · 17.0
Enhancements to existing features
When a workcenter is unblocked in the manufacturing system, the application no longer triggers an unnecessary page reload. This improves the user experience, especially for shop floor operations and other connected applications that depend on smooth, uninterrupted workflows.
Original PR description
Unblocking a workcenter incurs a reload which is bad in terms of user experience for other applications like shop floor. And since the reload is no longer needed at any other part, it is removed now. task-3629043 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the India localization module by adding comprehensive test cases for invoices and partner details, and reorganizing the code for better maintainability. The GST treatment field now properly updates when invoices are reset to draft status, and tax-related code has been separated into its own file for easier navigation and maintenance.
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
This update enables Odoo to automatically migrate existing email configuration settings when the Mail module is installed. Previously, when upgrading to version 17, email domain configurations had to be manually re-entered. Now, if these settings were configured before installing the Mail module, they will be automatically transferred to the new system, making the installation process smoother and reducing manual setup work.
Original PR description
When adding alias domain in v17 support of configuration parameter was dropped. We moved from singleton configuration to multi domains using real models. This means most of mail support lies in mail while part of it was in base beforehand. In some cases we want to let people do some basic configuration using base module then install mail which could migrate this ICP based configuration into new models. This is notably the case with odoo.sh where mail is not always automatically installed. With this change existing ICP are now used to bootstrap alias domain table at mail module initialization. Task-3789584
This update adds automated tests for the screencast recording feature to ensure it works reliably across different ffmpeg versions. A recent change had broken the ffmpeg integration, and these new tests will help catch similar issues in the future and verify compatibility during software distribution builds.
Original PR description
Screencast are not always enable and a recent change broke the ffmpeg call. This call was already broken in some ffmpeg versions. This test will help to ensure this feature continues to work, and will also test it in different ffmpeg versions during distro builds. Forward-Port-Of: odoo/odoo#155951 Forward-Port-Of: odoo/odoo#151815
This update enables users to select two additional document types (80 and 83) when creating invoices in Argentina with the AFIP Online Invoice system. These document types are now available for selection in the invoice journal, expanding the options for different types of fiscal documents that businesses need to issue.
Original PR description
This pull request replaces https://github.com/odoo/odoo/pull/156598 Description of the issue/feature this PR addresses: It is necessary to be able to select document types "80 INFORME DIARIO DE…
This pull request replaces https://github.com/odoo/odoo/pull/156598 Description of the issue/feature this PR addresses: It is necessary to be able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on field "AFIP POS System". Current behavior before PR: User is not able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on the field "AFIP POS System". Desired behavior after PR is merged: User is able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on the field "AFIP POS System". Task Adhoc side: 34790 Task latam: 1167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156695
The product search feature in the Point of Sale system has been optimized to handle large databases more efficiently. By reducing how frequently the search function runs while users type, the system now responds faster and uses fewer resources, improving the overall checkout experience.
Original PR description
Before this commit, searching for a product in the product screen was problematic when dealing with large databases. The search function was triggered too frequently, leading to performance issues. With this commit, I have increased the debounce time for the product search. This reduces the frequency of search operations when user is typing. opw-3788796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Block button in the work center interface now correctly shows or hides based on the current blocking state. Previously, the button would always show "Block" even when the work center was already blocked. Now users can properly block a work center or unblock it directly from the shop floor view, improving the user experience and preventing confusion.
Original PR description
`Block` button appears only if the work center state is not blocked, and vice versa task-3629043  
This update fixes how progress bars are calculated in the HR attendance and contract scheduling views. Previously, the progress calculations didn't properly account for individual employee contracts, which could lead to inaccurate progress tracking. This fix ensures that progress bars now correctly reflect each employee's contract details.
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971
This update fixes two issues with multi-line text fields in digital signature documents. Long text entries were overflowing their boundaries, and text alignment settings were not being applied to the final PDF. The fix ensures text displays correctly within its designated area and respects the user's alignment preferences when generating signature documents.
Original PR description
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Changes: 1. remove the fixed textarea font-size property and allow it to be set dynamically based on the zoom factor 2. apply text alignment on the multiline field Task: 3696347
This fix corrects an issue in the payroll accounting system where SEPA payments were being incorrectly classified as NURG (non-SEPA) payments. The change ensures that SEPA bank transfers for employee salaries are properly identified and processed through the correct payment channel, improving payment accuracy and compliance.
Original PR description
…of SEPA
Amazon has started anonymizing buyer information in order data, which was causing synchronization errors. This fix allows orders to sync successfully even when buyer details are missing, ensuring your Amazon sales orders continue to be imported into Odoo without interruption.
Original PR description
After some time, Amazon anonymized the buyer information and don't send it anymore in the calls. This shouldn't raise an error due to the missing data, but synchronize the order nonetheless. opw-3761649 Forward-Port-Of: odoo/enterprise#58099 Forward-Port-Of: odoo/enterprise#57999
Fixed a bug in the Partner Ledger report that caused the system to crash when displaying reconciled accounting entries without a partner. The issue occurred when a miscellaneous entry without a partner was reconciled with an invoice from a specific partner. The fix ensures the report correctly handles these indirect linked entries by using unique identifiers, preventing duplicate data conflicts.
Original PR description
The owl key used was the id of the journal item, it is not unique in some cases of indirect linked aml (amls which don't have the partner of the report section but are reconciled with an aml which have this partner). An indirect aml can have multiple partial reconciliations with different amls from the same partner. Also the way odoo shows indirect aml in "Unknown partner" section is to duplicate all info shown except debit/credit/balance from origin aml (so this include aml.id). To support those cases, we now use a markup with the id of partial reconcile to produce unique keys. When the aml is not an indirect aml, this markup is set to 0. Steps to reproduce: 1/ Create an invoice with partner 2/ Create a MISC entry without partner for the same amount 3/ Reconcile both 4/ Go to partner ledger for the right period + unfold all => Traceback opw-3700478 Forward-Port-Of: odoo/enterprise#57105
A variable name error in the POS preparation display module has been corrected. The system was referencing an incorrect field name (pos_categ_id) which has been fixed to use the correct field name (pos_categ_ids). This ensures the POS system properly retrieves product category information for order preparation displays.
Original PR description
Before this commit, the variable name was wrong in the pos_order.py file in the pos_preparation_display module. We use product_id.pos_categ_id Now its fixed by using the correct name product_id.pos_categ_ids
Fixed a bug where clicking the home navigation arrow in the Documents app would cause an error. The issue occurred when users clicked directly on the arrow icon to return to the home view. The fix disables pointer events on the arrow's underlying graphic elements so clicks are properly handled by the button instead.
Original PR description
Issue: - Open the Documents App. - Select any PDF and click splitPDF from the inspector. - Now from the top-left, try to toggle back to home by clicking precisely on the arrow. - We get a traceback.…
Issue: - Open the Documents App. - Select any PDF and click splitPDF from the inspector. - Now from the top-left, try to toggle back to home by clicking precisely on the arrow. - We get a traceback. Reason: - link to the LOC from where the issue arises: https://github.com/odoo/enterprise/blob/705bed9b2c63227c36f42045903f490a5d287f1f/documents/static/src/owl/components/pdf_manager/pdf_manager.js#L1275 - The `ev.target` returns an `<svg>` element (the toggle arrow) when clicked directly on it. - When clicked on the bottom right end of the toggle arrow, it returns the `<rect>/<g>` element. - Since neither the `<svg>/<rect>/<g>` element have a `click()` method, clicking directly on them results in a traceback. Fix: - We use the bootstrap class `pe-none` to disable the pointer-events inside the `<svg>` element. After this commit: - We successfully land on the HOME, when clicking on the arrow. The traceback no longer occurs after this fix. Task-3764120 Forward-Port-Of: odoo/enterprise#57514
This fix corrects how shipping dates are converted when creating delivery orders from Point of Sale transactions. Previously, when customers selected a "Ship Later" date in the POS system, the scheduled delivery date in the warehouse was showing one day earlier than intended. This update ensures the correct date is used when transferring order information to the fulfillment system.
Original PR description
Since `shipping_date` is a field `Date` but `date_planned` is a field `datetime`, before this commit, the `date_planned` in picking was one day less. complementary to https://github.com/odoo/odoo/commit/fe9e230b500af316e6f80af453a4073d9dff24b7 - Enable `Allow Ship Later` into a pos config - Create a new order and set a `Ship Later Date`  - Go to backend and navigate to picking and Scheduled Date is 02/27 instead of 02/28  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 accounting module's error notification widget was displaying outdated error messages that didn't refresh when the underlying data changed. Users had to manually refresh the page to see the correct status. This fix ensures error messages update automatically whenever the data changes, providing users with accurate, real-time feedback without requiring a page refresh.
Original PR description
The widget for actionable errors does not update when the errors it displays are updated due to, for example, a recomputation of the field. This results in irrelevant errors being displayed in the view, when a particular configuration is correct. The correct errors (or an absence of any errors) will not be displayed until the view is refreshed. This commit adapts the component, such that the record data is accessed directly from the template. This means that the recordObserver, and the method it uses can be removed (as they were redundant) task-id: None
This update corrects how progress bars are calculated in the HR module to properly account for employee contracts. Previously, the progress bar computations didn't consider contract information, which could lead to inaccurate progress tracking. This fix ensures that progress bars now accurately reflect contract-aware data across HR, contract, attendance, and Gantt chart features.
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971
This fix prevents users from duplicating Call-to-Action (CTA) buttons in website headers, which was causing problems because duplicated buttons couldn't be removed individually. Users can still add buttons by dragging and dropping button snippets, which remain fully removable and manageable.
Original PR description
Steps to reproduce [17.0]: - Go to website (in "Edit" mode) > Click on the "Contact Us" button. - Duplicate the CTA button ("Button options" > "Duplicate icon"). - There is no way to only remove the…
Steps to reproduce [17.0]:
- Go to website (in "Edit" mode) > Click on the "Contact Us" button.
- Duplicate the CTA button ("Button options" > "Duplicate icon").
- There is no way to only remove the duplicated button, and the "Header" >
"Show/Hide Button" option will disable the whole CTA container.
After the website headers redesign in [1], a new feature was added to
allow users to select the elements they want to display in the header
(social links, call to action...). The CTA section was also marked as
'oe_unremovable' which disabled the option to remove it in the editor.
When a CTA button is duplicted, the clone will also be unremovable which
makes it impossible to remove.
The goal of this commit is to prevent the duplication of CTA buttons.
It's always possible to add buttons by drag & dropping "Button" snippets
which are also removable.
Remark: Also after [1], two header navbars were added in the DOM (for
the desktop view and mobile). Which means that the CTA field is also
duplicated and every change on the CTA buttons in Desktop will be
reflected in the mobile version.
[1]: https://github.com/odoo/odoo/pull/119650
opw-3706902This update fixes an issue where customers received a "Payment is canceled due to inactivity" error when attempting multiple payments in succession. The fix ensures that timeout settings from previous payment attempts are properly cleared before starting a new payment, preventing conflicts and allowing customers to complete their transactions smoothly.
Original PR description
Before this commit ================== In certain scenarios, when a new subsequent payment was initiated after the initial payment was completed, an error message appeared stating, **Payment is canceled due to inactivity** Issue ===== Failing to remove the previous inactivity timeout before establishing a new one led to the aforementioned error. With this commit ================ Explicitly clear previous timeouts before setting a new one to prevent potential conflicts and ensure a clean timeout environment.
Fixed an issue in Spanish Point of Sale where split payments were automatically assigning a default customer instead of prompting the user to select one. Now when using split payment methods, users will be asked to choose a customer, ensuring proper invoice assignment and compliance with Spanish invoicing requirements.
Original PR description
Current behavior: When in a spanish PoS, every order needs to be invoiced. If no customer is specified, there is a default customer selected. But if the payment method is split, the default customer should not be selected. And the user should be asked for a customer. Steps to reproduce: - Install the l10n_es_pos module - Go to PoS and create a new order - Select a product and go to payment - Select split payment (Customer Account) - The default customer is selected, but you should be asked for a customer Note: To fix this we use the same behavior as in the base PoS, where the user is asked for a customer if the payment method is split. If no user is selected after being asked for a customer, the default customer is selected. If a user is selected, the user is sent back to the payment screen, as it's done in the base PoS. opw-3736293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when paid orders are loaded in the Point of Sale system, their tracking numbers remain consistent with what's recorded in the backend. Previously, the system was incorrectly updating the session ID to the current session, causing a mismatch. This resolves the discrepancy so order records are now accurate across the system.
Original PR description
Before this commit, when loading paid orders, the tracking number would differ from the backend. This discrepancy was due to the fact that the `pos_session_id` was being changed to the current session. opw-3788982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix addresses an issue where EMV QR codes were being incorrectly selected for unsupported countries on invoices. The system now properly validates that a country supports EMV QR codes before using them, preventing invalid QR code generation and ensuring currency validation is performed correctly.
Original PR description
The account_qr_code_emv module has an issue at the moment where it will only return errors in _get_error_messages_for_qr for the country the qr code is intended for. This makes sense since you want…
The account_qr_code_emv module has an issue at the moment where it will only return errors in
_get_error_messages_for_qr for the country the qr
code is intended for.
This makes sense since you want to check all countries in later versions where we have multiple of them.
But it causes an issue with the standard implementation where if you are using a country that is not supported by an EMV QR, _get_error_messages_for_qr will just return None.
This means that:
- The default QR CODE selection on the invoice that
depends on that may select EMV QR for unrelated
countries.
- If it gets selected, this method will not check
that the currency is correct for said countries.
To fix this issue, we will simply return an error
message in the common module, which will serve as a fallback once all the EMV QR methods have been checked.
Task id # 3758668
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156840
Forward-Port-Of: odoo/odoo#154957This fix corrects an issue where inventory transfers between warehouses were incorrectly marked as "Reserved from stock" in the forecast report, even when they should be linked to replenishment transfers. The problem occurred when a product had both a Make-to-Order route and a replenishment route between warehouses. Now the forecast report accurately reflects the actual warehouse location of reserved inventory.
Original PR description
Commit c05815ae6b8bd will go through a chain a move to set the last one as "reserved from stock" if the first one is reserved even if the cahin is not completed yet. The issue is if the chain is…
Commit c05815ae6b8bd will go through a chain a move to set the last one as "reserved from stock" if the first one is reserved even if the cahin is not completed yet. The issue is if the chain is inter warehouses, a move out in a warehouse can be marked as "reserved" while the stock being reserved is actually the one of another warehouse. ### To reproduce 1. Create 2 warehouses 2. Create a stock rule (pull) and a route between the 2 stock location of those product create a product having the route MTO and the new replenish route create a delivery in the second warehouse. 3. A transfer from the two warehouse should be created and linked to the delivery Open the forecast report for the warehouse that deliver the product -> the delivery is marked as "Reserved from stock" instead of being linked to the replenish transfer. 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#152922 Forward-Port-Of: odoo/odoo#152322
This fix ensures that completed Point of Sale orders are properly counted in product sales totals, even when they haven't been invoiced yet. Previously, when a POS session was closed without invoicing the orders, those sales would not appear in the product's sales count displayed in the Sales dashboard.
Original PR description
Current behavior: Orders from a closed pos that were not invoiced are not taken into account in the sales count (can be seen in the "Sales" smart button) Steps to reproduce: - Create a new product P1 - Sell this product in the PoS without invoicing it - Close the PoS session - Go to the "Sales" smart button of the product P1 - You will see that the sales count is not incremented opw-3726153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156320