Saturday, November 25, 2023
41 changes · 17.0
New functionality added to Odoo
Odoo POS now supports Viva Wallet as a new in-person payment option. This lets businesses accept payments through a smartphone-based provider, expanding payment flexibility at checkout.
Original PR description
Add Viva Wallet to the POS. A new payment method that allows payment in person via Smartphone 2991908 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
The Point of Sale IoT build is updated to use Debian Bookworm with Python 3.11, replacing the older Debian Bullseye base that could not support the required Python version. This helps keep IoT/posbox deployments compatible with current Odoo requirements and better prepared for ongoing maintenance.
Original PR description
From odoo 16.4 we need run odoo with python >= 3.10 However Debian Bullseye can't run python > 3.9.2 from apt manager Now we use Debian Bookworm with python 3.11 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
Resolved issues and error corrections
This fixes a crash in the Accounting invoice analysis pivot report when users collapse a column group and then expand it by month. The report now uses the correct date grouping, so business users can analyze invoices by month without interruption.
Original PR description
Accounting > Reporting > Invoice Analysis Open Pivot View Collapse column group, expand by Date>Month StopInteration traceback will raise line: column = self._read_group_postprocess_aggregate(spec, next(column_iterator)) The error is caused by a missing interval attribute on the group by pivot view default search. This will make the view call `read_group` with a wrong groupby list ['invoice_date', 'invoice_date:month'], that will cause the error raise opw-3603433 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
Miscellaneous changes
The unit prices should always be positives in the Peppol Bis 3 xml, otherwise, a validator will raise "[BR-27]-The Item net price (BT-146) shall NOT be negative.". Add a constraint in the code to ensure this. task-3607341 Forward-Port-Of: odoo/odoo#143531 Forward-Port-Of: odoo/odoo#143161
Original PR description
The unit prices should always be positives in the Peppol Bis 3 xml, otherwise, a validator will raise "[BR-27]-The Item net price (BT-146) shall NOT be negative.". Add a constraint in the code to ensure this. task-3607341 Forward-Port-Of: odoo/odoo#143531 Forward-Port-Of: odoo/odoo#143161
Fixes an issue where module loading errors could make the web test suite appear blank instead of showing the problem. This helps teams diagnose test failures faster and keeps automated quality checks clearer.
Original PR description
Since the module loader rewrite, it now reports errors directly in the DOM. The error alert also has the class "modal" so that in case a tour comes accross a page with module loading errors, it will only look for elements inside it and fail. But in the QUnit test suite, modals are invisible by default, causing the page to be blank in those cases. This commit adds a css rule to make sure that this error alert is shown, and updates the code that was previously used to report these errors in the qunit suite to instead simply check for errors reported by the module loader.
The spreadsheet component was updated to a newer version with fixes that make copying, pasting, formula handling, and row removal more reliable. It also includes performance improvements for calculations and lookups, helping large spreadsheets feel faster and reducing user-facing errors.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7346d0af9 [REL] 17.0.4 https://github.com/odoo/o-spreadsheet/commit/661e290f4 [FIX] sheet: remove zombie code…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7346d0af9 [REL] 17.0.4 https://github.com/odoo/o-spreadsheet/commit/661e290f4 [FIX] sheet: remove zombie code https://github.com/odoo/o-spreadsheet/commit/7362fc105 [FIX] sheet: remove rows faster https://github.com/odoo/o-spreadsheet/commit/dcaa1ab0c [FIX] tokenizer: faster current char lookup https://github.com/odoo/o-spreadsheet/commit/0448b26f5 [FIX] tokenize: replace special chars faster https://github.com/odoo/o-spreadsheet/commit/88a57c6be [FIX] icons: use correct comment syntax in xml files https://github.com/odoo/o-spreadsheet/commit/cf8194df2 [FIX] clipboard: fix array formula copy https://github.com/odoo/o-spreadsheet/commit/ca24d7e8c [FIX] evaluation: faster range matrix https://github.com/odoo/o-spreadsheet/commit/a13ff80b3 [FIX] clipboard: traceback on paste from copy after deleting that sheet https://github.com/odoo/o-spreadsheet/commit/eaa0dca12 [FIX] evaluation: cache range references values Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/cdeb716c3 [REF] evaluation: group compilation parameters https://github.com/odoo/o-spreadsheet/commit/943a7e7f8 [FIX] lookup: cache string normalization Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/0330db03c [FIX] cells,borders: cancel useless commands Task: 3603259 https://github.com/odoo/o-spreadsheet/commit/38d77fe89 [FIX] cells: faster getter to get cell Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/15bdafc80 [FIX] model: don't flatten command result
This fix prevents mail conversations from repeatedly loading older messages when a chat is reopened or unfolded. It also ensures inbox previews show the true latest message, improving reliability for users navigating recent and older conversations.
Original PR description
The issue is that "load older" was called every time the thread was made visible, in particular after chat window unfold. The load more button will naturally be visible when first loading a thread, it only makes sense to check its final visibility and not intermediate steps. But there was a bug where the loading mechanism was relying on the initial "load older" to fetch messages, because the messaging menu preview was incorrectly setting the thread as already loaded, when it just fetched the last message. Moreover, the "last message" displayed in the preview was not correctly computed, and it could end up being the last "currently fetched" message and not the last of all messages (when jumping in the past), and it could also be a non-persistent message. runbot-35533
Downloading a preview of an invoice that has not yet been confirmed no longer triggers an error. The system now only allows PDF download handling when the invoice is posted, improving reliability for users working with draft invoices.
Original PR description
Steps to reproduce: ------------------- - create an invoice without confirm it; - go to the preview and download it; Issue: ------ A traceback appears. Cause: ------ We try to get `ids` field of a non "record" object (not the root cause). The root cause is that we don't create an attachment if the invoice is not posted. And to post an invoice, we must add line before confirm it. Solution: --------- Make sure you are in the case of an invoice that is `posted` to download a pdf. sentry-4612532780
This update helps Belgian users choose the correct Peppol identification code by showing a warning that Belgium should use 0208. It also ensures only customer invoices, credit notes, and receipts are marked as Peppol ready, making batch sending more reliable and reducing accidental selections.
Original PR description
## [FIX] account_peppol: add a warning for Belgium Users need a helpful message for selecting the right EAS and Endpoint numbers. In Belgium it should always be 0208 according to BOSA, so we can display a warning message advising them to select that code for Belgian partners. ## [FIX] account_peppol: fix peppol ready We should only mark account moves as "Peppol ready" if it's a customer invoice/customer credit note. These are also the only types of account moves we should display when a user wants to filter by "peppol ready" as this means they want to easily select all and send them via peppol in batch. This commit limits "Peppol Ready" to `out_invoice`, `out_refund`, `out_receipt`. task-3603416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents event website pages from showing an error when a visitor's browser does not support service workers. It keeps the experience stable for affected visitors instead of displaying a technical crash dialog.
Original PR description
PR [1] removed the legacy error handler that swallowed promise rejection errors with anything else than an error (namely, the "legacyRejectPromiseHandler"). As a consequence, promise rejections done as "control flow" now lead to error dialogs being displayed. In particular, it happened on the website (with website_event_track installed), if the browser doesn't support service workers. This commit simply leaves the promise pending if the feature is unavailable. [1] https://github.com/odoo/odoo/pull/137702 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
Fixed an issue where changes to a bank journal payment method could be lost when another payment method was removed at the same time. This helps accounting users avoid rework and keeps payment configuration changes reliable.
Original PR description
When users edit a outbound/inbound payment method line of their bank journal and in the same time remove another payment method line, the edited line changes for their initial state (without the…
When users edit a outbound/inbound payment method line of their bank journal and in the same time remove another payment method line, the edited line changes for their initial state (without the change). It was caused by a complicated way to know which payment method line are available for this journal. This non stored compute field is recompute for each change made on the inbound/outbound payment method line. It means that the function deal with origin record instead of record itself. During the search for this fix, we found out that everything work fine if we remove the column_invisible on this computed field. In that case, we had not so many calls to the compute function to get the values. It's obviously not a solution and that's why after some investigations, we decide to use the _origin id when we get the outbound/inbound_payment_method_line in the _compute_available_payment_method_ids function. Thanks to @h4818 for his help during the process. opw-3597536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures datetime range fields correctly understand when they are required. It prevents unnecessary extra date inputs from appearing and avoids validation issues in debug mode, improving form reliability for users.
Original PR description
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the…
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the datetime picker would fail, as it expects to receive a boolean for the `range` prop. This was caused by the fact that required was the raw attribute (a string) instead of the boolean and ended up being propagated to the `range` prop - outside of debug mode, the value for required did not cause a crash but any value for required that was not empty would be interpreted as truthy, causing the field to always be display itself as though it is required. In non-range mode, this is invisible, but in range mode, it would always show the second datetime input and the arrow between the beginning and end date, even with required being 0/False, or a python expression that may evaluate to false This commit fixes that by instead reading the value for required from the dynamic infos provided to `extractProps`, which will always be a boolean and contain the value of the evaluated expression when appropriate.
This update fixes a technical issue in the Planning module where an outdated translation function was replaced with the current standard. This ensures the module continues to work properly with the latest system updates and maintains compatibility with the current codebase.
Original PR description
In this commit we fix _lt with _t. Let's see more informations on https://github.com/odoo/odoo/pull/124157
Fixed a visual bug in the timesheet timer where selecting a project or task caused unwanted extra height to appear on mobile devices. The issue was caused by an oversized arrow button (1.3em) that was pushing content down. The fix reduces the button size through a new stylesheet to maintain consistent layout when making selections.
Original PR description
**Steps:** - Open timesheet - Switch to mobile view - Start the timer - Select a Project / Task from dropdown - (Appears in all the views) **Issue:** - When a project/task is selected, extra height appears beneath it **Cause:** - The extra height is caused due to the arrow button which has a size of 1.3em **Fix:** - Making a new scss file for this instead of changing in base files and adding style to reduce the size of the button. **Task:** 3387850 Forward-Port-Of: odoo/enterprise#43428
This fix ensures that the WhatsApp category appears in the mobile version of the Discuss app's bottom navigation bar, matching the desktop experience. Previously, users could see WhatsApp conversations on desktop but the category was missing from mobile navigation, making it harder to access WhatsApp messages on phones and tablets.
Original PR description
WhatsApp category was shown in Discuss app sidebar in desktop, but was not visible in the bottom navbar in mobile. Part of Task-3525542 opw-3580979
This update corrects how fuel type information is stored and displayed for company vehicles in the Belgian payroll system. The fix ensures that fuel type selections are handled properly without storing unnecessary data in the database, maintaining compliance with system policies while preserving the ability to show fuel types for new vehicles.
Original PR description
https://github.com/odoo/enterprise/pull/47717 fixed the display of the fuel type for a new car, as it was not being shown. However, the change from that PR was not respecting stable policy. This commit fixes this by changing the selection values from a static list to a lambda function that returns that list This makes the selection values not be stored in the database. Forward-Port-Of: odoo/enterprise#51297
A display issue in the field service portal task view has been corrected where the "Time & Material" section was appearing in the wrong location. The fix updates the underlying code to ensure this section displays in the correct position above the Timesheets section, improving the user experience when viewing task details.
Original PR description
In field service's portal task view, a display error would occur with the "Time & Material" section ; it would get displayed next to the "Timesheets" section which is wrong, as it should be displayed on top of it. The issue is that with the rework of portal's front in 17.0, the xpath expression that supposedly selects the "Timesheets" section now selects the "Timesheets" navigation menu, and makes the "Time & Material" section display right on top of it. To fix this, the xpath expression was changed to select the right element. task-3609165
This fix resolves an import error that occurred when Odoo Enterprise was installed as a package. A missing initialization file was preventing the bank statement import module from loading correctly. This ensures the bank statement import functionality works reliably in packaged installations.
Original PR description
When enterprise is installed as a package, importing this odoo.addons.account_avatax will raise an ImportError due to this missing file. @moduon MT-1075 Forward-Port-Of: odoo/enterprise#48669
This fix corrects how Odoo generates SEPA payment files to comply with banking standards. The ChrgBr (Charge Bearer) tag is now placed at the payment level instead of the transaction level, following official SEPA specifications. This resolves issues where some banks were rejecting payment files due to incorrect formatting.
Original PR description
In the SEPA specification: "It is recommended that this element [ChrgBr] be specified at ‘Payment Information’ level." In odoo the ChrgBr was set at transaction level leading to some bank refusing the SEPA file. To follow the specification recommendation, ChrgBr is moved at the payment level. opw-3479639 Forward-Port-Of: odoo/enterprise#51376
This fix resolves an error that occurred when printing invoices in the Accounting module with Documents enabled. The issue happened because documents were being created multiple times concurrently, causing a validation error. The fix ensures documents are created immediately when attachments are created, rather than when they're loaded in the chat, preventing duplicate creation attempts.
Original PR description
Steps to reproduce: - Install Accounting and Documents - Go to Documents settings - Activate "Accounting" option (Workspace: Finance) and add a journal to synchronize (Journal: Customer Invoices -…
Steps to reproduce: - Install Accounting and Documents - Go to Documents settings - Activate "Accounting" option (Workspace: Finance) and add a journal to synchronize (Journal: Customer Invoices - Workspace: Finance) - Go to Accounting and create an invoice - Click on Print button and select "Invoices" => The following Validation Error can be raised: "The operation cannot be completed: This attachment is already a document" (This issue depends on the speed of the platform and doesn't always happen) Cause: When printing the invoice, an attachment is created, but no document is created in Documents immediately (as configured in Documents settings). Once the attachment created, it is loaded in the chatter and several calls are made to "register_as_main_attachment" method of the attachment. This method is triggering a write on the related record (i.e. the invoice), which tries to create a document (in Documents) from the attachment. When trying to create the document, it first checks if a document already exists for that attachment. But in some cases, there can be 2 concurrent calls where the first one has not finished creating the document when the second one checks if a document already exists. It then tries to create a second document for the attachment and triggers the SQL unique constraint. Solution: The creation of the document should not depend on the loading of the attachment in the chatter. It should be created when the attachment is created. So, when the first attachment of an account move is created, the related document will also be created. opw-3464593 Forward-Port-Of: odoo/enterprise#51114
This update reverts a previous change to how reported dates and hours are calculated in planning templates. The previous fix was causing unintended behavior changes in the stable version. A more comprehensive solution will be developed separately to properly handle shift template generation when users save shifts as templates.
Original PR description
This reverts commit 145fdbc because the fix alters the behavior in planning template which is not really allowed in stable. A another fix will be done to correctly compute the shift template generated when the user saves a shift as template. Forward-Port-Of: #50933
This fix ensures that spreadsheet record names are properly displayed as text strings when users access shared spreadsheets. Previously, in certain cases where a record didn't have a defined name, the system would return an empty value instead of a text string, causing display issues in the spreadsheet interface. This update corrects how the system retrieves and formats record names to ensure consistent, reliable display for all users.
Original PR description
When fetching the record data from the server via `join_spreadsheet_session`, we rely on the field `display_name` while expecting it to be a string. This will however not be the case since [1] (i.e. if `_rec_name=""` then `display_name=False`). The client components are expecting a string, we therefore fix `join_spreadsheet_session` accordingly. [1] https://github.com/odoo/odoo-security/commit/c68fb4a494acc38b97678ed2a1fe18dbf8f3fa9d Task: 3562167 Forward-Port-Of: odoo/enterprise#51296
This fix resolves a display problem in the timesheet grid where long task titles would expand across the entire screen, making it impossible to see the timesheet data. The solution adds a maximum width constraint to task titles so they properly truncate with ellipsis, allowing users to view both the task name and timesheet information simultaneously.
Original PR description
This commit fix a UI issue due to unset max-width on the o_grid_row_title.
HOW TO REPRODUCE:
- Go in project
- Create a task with a very long name
- Go in timesheet
- Record a tisheet line linked to the created task
ISSUE:
- The title takes all the screen and we cannot see the timesheets.
FIX:
- Put a maximun width for the row titles in order to trigger the
text-truncate
taskid:3539337
Forward-Port-Of: odoo/enterprise#51390Fixed an error handling issue in the Shiprocket delivery integration where the system was not properly managing error responses from the shipping provider. This fix ensures that when the Shiprocket API returns an invalid payload response, the system now correctly handles and reports the error instead of failing silently, improving reliability of shipping operations.
Original PR description
When `payload` response is false, need to handle error. opw-3604932 Forward-Port-Of: odoo/enterprise#51261
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all values of X to flush them", which means that a dirty field (pending update) has lost its value from cache. The issue is related to recursive computed fields. Before deleting a record, method `unlink()` invokes `modified()`, which determines all the fields that depend on the record to be deleted,
Original PR description
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all…
The following situation happened with module `industry_fsm`, when trying to delete a cancelled sales order corresponding to a task. When doing so, the server crashes with error "Could not find all values of X to flush them", which means that a dirty field (pending update) has lost its value from cache. The issue is related to recursive computed fields. Before deleting a record, method `unlink()` invokes `modified()`, which determines all the fields that depend on the record to be deleted, and marks them to recompute. Those fields should be recomputed after the record is deleted, and not before. We found out that the recursive call to `modified()` made for recursive fields can force the recomputation of the recursive field itself before the record is deleted, which causes `unlink()` to crash. The fix consists in marking the fields for recomputation at the very end of method `modified()`, after all the fields to recompute have been determined. This ensures that the processing of recursive fields always uses the current value of the field instead of its recomputed value. Forward-Port-Of: odoo/odoo#143267 Forward-Port-Of: odoo/odoo#142712
Since odoo/odoo@b3a2fb51bc48b83, it is not possible to use partial points rewards. However this commit only fixes the behavior for loyalty cards, where it should be applied to many other program types. Forward-Port-Of: odoo/odoo#143334
Original PR description
Since odoo/odoo@b3a2fb51bc48b83, it is not possible to use partial points rewards. However this commit only fixes the behavior for loyalty cards, where it should be applied to many other program types. Forward-Port-Of: odoo/odoo#143334
*product_configurator, comparison, stock Before this commit, the option "Prevent Sale of Zero Price Product" would still allow some free products to be added to the cart (accessory, optional and alternative products). This commit makes sure no free product can be added to cart if this option is activated. task-2983615 Forward-Port-Of: odoo/odoo#143563 Forward-Port-Of: odoo/odoo#137298
Original PR description
*product_configurator, comparison, stock Before this commit, the option "Prevent Sale of Zero Price Product" would still allow some free products to be added to the cart (accessory, optional and alternative products). This commit makes sure no free product can be added to cart if this option is activated. task-2983615 Forward-Port-Of: odoo/odoo#143563 Forward-Port-Of: odoo/odoo#137298
During upgrade, it try to create picking type if not exist like pos type and everytime will create new sequence too for that picking type. during the creation of picking type there is python constraints that raised if same sequence name with same company exist. so to avoid that will check before creating new sequence if already same company sequence exist then update the sequence name with id. Description of the issue/feature this PR addresses: Current behavior before PR: Desired beha
Original PR description
During upgrade, it try to create picking type if not exist like pos type and everytime will create new sequence too for that picking type. during the creation of picking type there is python constraints that raised if same sequence name with same company exist. so to avoid that will check before creating new sequence if already same company sequence exist then update the sequence name with id. 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#139277
Issue: ====== When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same. Steps to reproduce the issue: ============================= - Create a loyalty program with the following options: type: pormotions rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product: select anyone reward: type : free product , quantity rewarded : 1, product : select any other product - Go to we
Original PR description
Issue: ====== When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same. Steps to reproduce the issue: ============================= - Create a loyalty program with the following options: type: pormotions rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product: select anyone reward: type : free product , quantity rewarded : 1, product : select any other product - Go to website and add the product from the rule to cart - Go to cart and claim reward - Go back to shop and add the product from the reward to cart - Go to cart - The cart stays the same Issue: ====== When searching for the `line` it doesn't consider if the line is a reward or not. Solution: ========= We filter the reward lines if `line_id=False` opw-3550585 Forward-Port-Of: odoo/odoo#143464 Forward-Port-Of: odoo/odoo#142827
All the stock widgets are exported except for StockReschedulingPopover. Export it so that it can be used elsewhere. Additionally, fix the name of the class to correct a typo. Forward-Port-Of: odoo/odoo#135971
Original PR description
All the stock widgets are exported except for StockReschedulingPopover. Export it so that it can be used elsewhere. Additionally, fix the name of the class to correct a typo. Forward-Port-Of: odoo/odoo#135971
## [FIX] account_peppol: shorten cron interval Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks as if something went wrong. ## [FIX] account_peppol: disable peppol for certain edi formats If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden. This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard. Sinc
Original PR description
## [FIX] account_peppol: shorten cron interval Update participant status every 6 hours instead of once a day. Once a day is too slow for users and it looks as if something went wrong. ## [FIX] account_peppol: disable peppol for certain edi formats If the format set on a partner does not work for our peppol implementation, `enable_peppol` should be `False` and the checkbox should be hidden. This commit checks invalid partners when computing `enable_peppol` on account_move_send wizard. Since we hide the checkbox in this case, we don't need to show the peppol warning when opening send&print to such partners. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142166
Issue: ====== When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct. Steps to reproduce the issue: ============================= - Create a product with a not pos_groupable uom (kg for example) - Create a sale order with that prouct and add a not integer quantity - Go to pos and settle the order - You will have 4 lines added each with quantity = 1 Origin of t
Original PR description
Issue: ====== When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct. Steps to reproduce the issue: ============================= - Create a product with a not pos_groupable uom (kg for example) - Create a sale order with that prouct and add a not integer quantity - Go to pos and settle the order - You will have 4 lines added each with quantity = 1 Origin of the issue: ==================== The quantity was hardcoded = 1 Solution: ========= I addeed order lines equal to the integer part of quantity and one last order line that have the rest quantity. opw-3579225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143390 Forward-Port-Of: odoo/odoo#141233
The additional lines originating from the product configurator are sometimes not well handled by the framework. With this additional steps in the test, we ensure the line remains after selecting it without editing anything, a case that was broken several times already. Forward-Port-Of: odoo/odoo#143484 Forward-Port-Of: odoo/odoo#143374
Original PR description
The additional lines originating from the product configurator are sometimes not well handled by the framework. With this additional steps in the test, we ensure the line remains after selecting it without editing anything, a case that was broken several times already. Forward-Port-Of: odoo/odoo#143484 Forward-Port-Of: odoo/odoo#143374
**Description of the issue/feature this PR addresses:** Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each line. This commit prevent also serialisation failure on ecommerce. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143335 Forward-Port-Of: odoo/odoo#141649
Original PR description
**Description of the issue/feature this PR addresses:** Before this commit when you unlink a sale.order.line the field carrier_id of sale.order is set False for each line. This commit prevent also serialisation failure on ecommerce. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143335 Forward-Port-Of: odoo/odoo#141649
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks. * In "Accounting/Vendors/Own Checks" it is needed to: 1) Remove the filter "Checks on hand". 2) Remove from "Group By" the group "Third party check Current Journal". * In "Accounting/Customers/Third Party Checks" it is needed to: 1) Add the filter "Checks on hand". 2) Ad
Original PR description
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party…
Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks. * In "Accounting/Vendors/Own Checks" it is needed to: 1) Remove the filter "Checks on hand". 2) Remove from "Group By" the group "Third party check Current Journal". * In "Accounting/Customers/Third Party Checks" it is needed to: 1) Add the filter "Checks on hand". 2) Add in "Group By" the group "Third party check Current Journal". 3) Remove the filter "No Bank Matching". 4) Rename filter "Third party check Current Journal" to "Current Journal". - When a payment is created is needed show the updated search view "Accounting/Customers/Third Party Checks" when searching more checks if "Existing Third Party Checks" payment method is selected.  - Change spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view from "Actual Diario de Cheques de Terceros" to "Diario de Pago". **Current behavior before PR:** * In "Accounting/Vendors/Own Checks" in the search view: Exists the filter "Checks on hand" and exists the group "Third party check Current Journal" in the "Group by". * In "Accounting/Customers/Third Party Checks" in the search view: Don`t exist the filter "Checks on hand". Don`t exist the group "Third party check Current Journal" in the "Group by". Exists the filter "No Bank Matching". There is a filter named "Third party check Current Journal". * When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected then is showing the same search view as "Accounting/Customers/Third Party Checks". * Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Actual Diario de Cheques de Terceros". **Desired behavior after PR is merged:** * In "Accounting/Vendors/Own Checks" in the search view: Not exists the filter "Checks on hand" and not exists the group "Third party check Current Journal" in the "Group by". * In "Accounting/Customers/Third Party Checks" in the search view: Exists the filter "Checks on hand". Exists the group "Third party check Current Journal" (renamed to "Original Journal") in the "Group by". Not exists the filter "No Bank Matching". There is not existing a filter named "Third party check Current Journal". * When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected them is showing the updated search view as "Accounting/Customers/Third Party Checks". * Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Diario de Pago". Video: https://drive.google.com/file/d/1H1ng4mPsN0sf1NwW_JMOmZrhe8TrrBlk/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#132770
Description of the issue/feature this PR addresses: It was not possible to obtain suggestions by entering a GST in the Tax ID field when creating a contact. Current behavior before PR: When a GST number is entered in the Tax ID field of the contact creation form, nothing happens. Desired behavior after PR is merged: Suggestions can now be accessed by entering a GST number in the Tax ID field of the contact form. Also, add the option of allowing completion even with an 'insufficient cr
Original PR description
Description of the issue/feature this PR addresses: It was not possible to obtain suggestions by entering a GST in the Tax ID field when creating a contact. Current behavior before PR: When a GST number is entered in the Tax ID field of the contact creation form, nothing happens. Desired behavior after PR is merged: Suggestions can now be accessed by entering a GST number in the Tax ID field of the contact form. Also, add the option of allowing completion even with an 'insufficient credit' error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143370
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database, which triggers a sanitize check, which fetches the original value, etc etc. Even if the functional bug only appears in 16.0 and above, the root cause is also present in 15.0 so this commit targets 15.0 steps to reproduce (in 16 or next versions): - Change Marc Demos's access rights Website = Res
Original PR description
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database,…
During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database, which triggers a sanitize check, which fetches the original value, etc etc.
Even if the functional bug only appears in 16.0 and above, the root cause is also present in 15.0 so this commit targets 15.0
steps to reproduce (in 16 or next versions):
- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error
before this commit:
Error (infinite loop) during onchange
```
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
record[parent_name]._update_cache({name: record[name]})
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
value = field.convert_to_cache(value, self, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
value = self.convert_to_cache(record._origin[self.name], record)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
...
```
after this commit:
no error
opw-3575865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#143268
Forward-Port-Of: odoo/odoo#142045There's currently no way to move a dashboard from a section to another You have to start again from a blank dashboard in the other group. Task: 3592986 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#142893
Original PR description
There's currently no way to move a dashboard from a section to another You have to start again from a blank dashboard in the other group. Task: 3592986 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#142893
The language was added at dccc8f39d0 but we need a flag to display in the language switcher. (even if [Flags are not languages](https://www.flagsarenotlanguages.com)) (open to suggestions for a better flag) Forward-Port-Of: odoo/odoo#142499
Original PR description
The language was added at dccc8f39d0 but we need a flag to display in the language switcher. (even if [Flags are not languages](https://www.flagsarenotlanguages.com)) (open to suggestions for a better flag) Forward-Port-Of: odoo/odoo#142499
When performing a manual stock revaluation, the value difference is distributed equally among the available stock. This method breaks down however in case of a devaluation where some items in stock are already valued less than the unit cost difference: this results in a negative value. This commit will prevent such devaluations by raising a `UserError` whenever the remaining value of a stock.valuation.layer becomes negative. Additionally, after a revaluation, the `standard_price` field will n
Original PR description
When performing a manual stock revaluation, the value difference is distributed equally among the available stock. This method breaks down however in case of a devaluation where some items in stock are already valued less than the unit cost difference: this results in a negative value. This commit will prevent such devaluations by raising a `UserError` whenever the remaining value of a stock.valuation.layer becomes negative. Additionally, after a revaluation, the `standard_price` field will now also be updated for fifo valued products. opw-3340298 Forward-Port-Of: odoo/odoo#136934 Forward-Port-Of: odoo/odoo#126157
- Open a record with the chatter (a task for instance); - Zoom your browser until the chatter is inline with the task (as it is the case on mobile) - Write a big message. Before this commit, the composer takes all the allowed place on the screen, and we cannot see or scroll-down to the older messages. Now, the behavior is the same as is done in mobile, the composer stays sticky, but it will not take all the allowed place, and leave place to see and scroll-down the older messages. opw-
Original PR description
- Open a record with the chatter (a task for instance); - Zoom your browser until the chatter is inline with the task (as it is the case on mobile) - Write a big message. Before this commit, the composer takes all the allowed place on the screen, and we cannot see or scroll-down to the older messages. Now, the behavior is the same as is done in mobile, the composer stays sticky, but it will not take all the allowed place, and leave place to see and scroll-down the older messages. opw-3593032 Forward-Port-Of: odoo/odoo#143295