Daily updates from Odoo
Wednesday, March 27, 2024
33 changes · 17.0
Enhancements to existing features
This update significantly improves the speed of the Point of Sale system when processing numpad button presses, especially for businesses with large product catalogs. By implementing a smart caching system, the system now responds almost instantly instead of taking 15+ seconds, making the checkout experience much faster and more responsive for cashiers.
Original PR description
Description of the issue/feature this PR addresses: This commit addresses slow performance of the JS `OrderLine.findAttribute` method when `attributes_by_ptal_id` is exceedingly large. Before this…
Description of the issue/feature this PR addresses: This commit addresses slow performance of the JS `OrderLine.findAttribute` method when `attributes_by_ptal_id` is exceedingly large. Before this commit, `findAttribute` would loop over all the values of `this.pos.attributes_by_ptal_id`, and filter out only the attributes that have at least one of the passed in ptal IDs (from the `values` parameter) within the attribute's "values" list. It would also modify the attribute to include a `"valuesForOrderLine"` key mapping to a list of all of the found ptal IDs from that attribute's values. This method becomes slow when `this.pos.attributes_by_ptal_id` is very large. Since it needs to loop over every single attribute. This commit provides a workaround to this slowness, by caching the search for valid attributes that this method performs in a lookup table. First, we construct the lookup table in `_processData` method of the `PosStore` class. `_add_ptal_ids_by_ptav_id` does this, by looping over all the values of all the attributes, mapping the ptav ID of the attribute to all the ptal IDs we find. Now, inside `findAttribute`, we will instead loop over each of the passed in `values`. For each value, we will retrieve the all the cached ptal IDs from `this.pos.ptal_ids_by_ptav_id` for the given value. Now that we have the ptal IDs, we can get all the corresponding attributes from `this.pos.attributes_by_ptal_id`. For each of those attributes, we can do the same modification from the original method by adding the `"valuesForOrderLine"` key/value. Finally we return all the modified attributes. This new method has a nested for loop, which may seem like a problem. But I believe that both the things being looped over (`values` and `this.pos.ptal_ids_by_ptav_id[value]`) should be very small compared to the potential size of `this.pos.attributes_by_ptal_id`. (43,000 in this customer's DB) `findAttributes` is called many times whenever the POS's numpad buttons are pressed, so this commit has the overall effect of drastically reducing the input latency for a numpad press. However, I do believe that this is a workaround, and the real problem is that the entire `attributes_by_ptal_id` is always passed to the POS, regardless of what products are actually being ordered. `attributes_by_ptal_id` should instead be incrementally fetched as products are ordered (if this is possible). Benchmarks (in customer DB): Before commit, each keypad press took around 1-3 seconds per Order Line present in the POS. For 11 products this was ~15 second latency. After commit, each keypad press is almost instant. The `ptal_ids_by_ptav_id` lookup table will consume additional memory, in this customer's DB I've estimated it to be about 0.3MB more memory. Taking memory snapshots in profiler shows no significant different between versions, however this is inconsistent. Will attach profiler results to PR. Current behavior before PR: Poor performance of `OrderLine.findAttribute` Desired behavior after PR is merged: Fast performance of `OrderLine.findAttribute` for a memory tradeoff. opw-3788840
This improvement removes unnecessary attribute parameters from product URLs when a product has no variants. Previously, product URLs would display with empty attribute markers (e.g., /shop/product-1#attr=), which looked unprofessional. Now, simple products without variants will have clean, straightforward URLs (e.g., /shop/product-1), improving the appearance and user experience of your eCommerce store.
Original PR description
Description of the issue/feature this PR addresses: Avoid ugly URL if no variant on your eCommerce. Current behavior before PR: Product URL are like /shop/product-1#attr= Desired behavior after PR is merged: Product URL are like /shop/product-1 when no attributes --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures that when reserving serial numbers for rental orders with inventory pickings enabled, the system now verifies that the selected serial numbers are actually available before assigning them. Previously, Odoo would assign any chosen serial number without checking availability, which could cause inventory conflicts and fulfillment issues.
Original PR description
When reserving a serial number on a rental order with pickings activated, Odoo will assign whatever serial number is chosen without checking if there's a quantity available. With this fix, it will check if the chosen serial are available before assigning them.
Fixed an issue where users couldn't validate batch transfer operations when some products required lot/serial tracking but weren't being transferred. The system now allows users to complete the transfer for untracked products and automatically creates a backorder for the tracked items that need lot information, improving workflow efficiency in warehouse operations.
Original PR description
In Settings>Inventory>Operations enable "Batch Transfers" Create a [NonTrackedProd] product: - Product Type: Storable Product - Tracking: No tracking Create a [TrackedProd] product: - Product Type: Storable Product - Tracking: By Lots Make two POs with: - Prod [NonTrackedProd] qty 1 - Prod [TrackedProd] qty 1 Open Barcode Scanning app Select "Batch Transfers" Create a new batch with the incoming transfers from the POs Set only the [NonTrackedProd] lines as done and validate Issue: Error will block validation "You need to supply a Lot/Serial number for products" The system should let the user validate the operation and create a backorder instead of blocking the user opw-3777701
This update improves the speed of calculating available restaurant table booking slots in the front-end by reducing the scheduling window from 60 days to 14 days. This change helps the system process slot availability faster when dealing with large numbers of people, while a more comprehensive performance improvement is being developed.
Original PR description
Purpose ======= Speed up the time taken to compute the available slots for resources in the front-end. Specifications ============== While waiting for a slot computation improvement, reducing the time taken to compute the available slots for large number of people. Changing the table booking max schedule days from 60 to 14. related: https://github.com/odoo/enterprise/pull/59101 Task-3826475
This fix resolves an issue where the Dutch XAF export file was missing account declarations for accounts that had opening balances but no transactions during the reporting period. This caused validation errors when customers submitted the file to tax authorities. The fix ensures all accounts with opening balances are properly declared in the export file.
Original PR description
Before this commit: The generated XAF file while exporting the general ledger is missing the declaration of the accounts with no lines for the given time period but which have an opening balance. The file contains the information regarding an opening balance for an account that is never declared in the file. This leads to an error for some customers when they send the file to the agency. After this commit: All the accounts with an opening balance but no line for the time period are declared in the appropriate section of the XAF file. opw-3567617 opw-3624000 Forward-Port-Of: odoo/enterprise#59482 Forward-Port-Of: odoo/enterprise#53532
This pull request contains multiple bug fixes and improvements across various Odoo modules including approvals, accounting, digital signatures, manufacturing, and point of sale systems. Key fixes address data integrity issues with attachment deletion, compliance with Mexican tax requirements, payment processing errors, and user experience improvements in appointment booking and test reliability.
This fix resolves a crash that occurred when the system tried to round financial values that were empty or missing. The update improves how the system handles percentage values and other numeric fields in accounting reports, ensuring they display correctly without unexpected rounding errors. This is particularly important for reports in regions like Chile where currency decimal settings were causing incorrect percentage displays.
Original PR description
When an expression had no figure type, the condition "expression.figure_type != 'string'" was true and so we tried to round the value. But when the value is None, the code will crash. Now if the expression has no figure type we get the column type of the expression, but it can happen that an expression is not link to a column. If that's the case we don't round the expression. task: 3776104 Forward-Port-Of: odoo/enterprise#59314 Forward-Port-Of: odoo/enterprise#57913
This fix resolves a system error that occurred when requesting feedback from employees who don't have associated user accounts in the HR Appraisal application. Users can now successfully send feedback requests to any employee without encountering a crash, improving the workflow for performance appraisals.
Original PR description
STEP TO REPRODUCE:
==================
* Go on Appraisal application
* Select an appraisal
* Click on "ask feedback" button
* Add in recipients field an employee without user linked to him
task: 3818033
Forward-Port-Of: odoo/enterprise#59464
Forward-Port-Of: odoo/enterprise#59125This fix resolves an issue where invalid VAT numbers were blocking clients from generating Belgian tax reports. When the system encounters a VAT number with formatting issues (spaces, dots, etc.), it will now keep the original number instead of failing. This allows businesses to proceed with their reporting even when VAT numbers need manual correction.
Original PR description
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
The Knowledge app's article emoji was displaying too small and appearing behind the top navigation bar on mobile devices. This fix adjusts the emoji size and positioning to display correctly across all devices, improving the mobile user experience.
Original PR description
Currently, the article emoji is too small and appears under the topbar of the Knowledge editor on mobile devices. This commit fixes these two issues and simplifies the CSS to ensure that the emoji is correctly placed on all devices. task-3784013 Forward-Port-Of: odoo/enterprise#54522
This fix corrects the placement of budget information in project update documents. Previously, budget details were appearing in the wrong section (under activities instead of in the profitability section). The issue has been resolved by adjusting how the system organizes and displays this information.
Original PR description
- 17.0 Steps to reproduce: - Open Project app and click on overflow menu of a project - Select project updates option - Try and create a new update document Issue: - The budget details text is just coming under activities which should be in profitability section. Cause: - Unset priorities of the inherited XML to cause files load before on another changing the orientation of display order and same Xpath for two inherited files. Solution: - Changing Xpath of one inherited view to accommodate for the order of display Task-3678808 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 fix prevents completion notification emails from being sent when an eLearning course has no published slides. Previously, when all course content was deleted, attendees would incorrectly receive course completion emails. The fix adds a check to ensure courses must have at least one slide before completion emails are triggered.
Original PR description
### [[FIX] website_slides: Stop sending completion mail on all slides removal](https://github.com/odoo/odoo/pull/153178/commits/f74fdbe8bb9a20d82caad5b78ec3292c34124fad) Construct deciding on…
### [[FIX] website_slides: Stop sending completion mail on all slides removal](https://github.com/odoo/odoo/pull/153178/commits/f74fdbe8bb9a20d82caad5b78ec3292c34124fad) Construct deciding on whetheres an attendee should receive 'complete' mail, contains a condition which checks if the attendee has: number_completed_slides >= number of all slides This however falls into a corner case when there is no slides at all and computation gets triggered (which got introduced with commit [1] ). ### [This Commit Change] This commit introduces an additional check on the total number of slides in a channel. Consequently, records without any slides in the related channel will no longer send completion mail notification. ### [Reproduce] - Install website_slides - Create a new eLearning course with some content but do not publish it. - Add attendees. - Delete all the content. - BUG: emails about finishing the course got sent (Settings/Technical/Emails) ### [Why this commit modifies existing test] The test introduced with commit [2] checks if a specific template is used in email generation, requiring email generation to occur as a prerequisite. Originally (before [This Commit Change]), it relied on the default behavior that considered an attendee a completer even without any published slides, thus triggering an email. However, after this commit, with a course containing zero published slides, completion cannot occur, and thus, no emails are sent. For this reason slight alteration of the test setup is required allowing for the emails to get sent and in effect the test to perform its role. ### [References] [1] https://github.com/odoo/odoo/commit/3efa80847c4631febefc770b79bb786953a05b36 [2] https://github.com/odoo/odoo/commit/9a0231d5c3fa25f4ec63303cfc7eb8e2bc8ff9e1 opw-3703987
Fixed a bug in the point of sale coin and bill counter where empty fields were displaying "NAN" instead of calculating correctly. Now when users clear a quantity field, the system treats it as zero and properly calculates the total amount, improving the checkout experience.
Original PR description
Before this commit: =================== In coins/bills pop pup, if user adds some coin and removes quantity from any of the fields (blank space) then it's showing `NAN` and not calculating the other inputted value which is completely annoying. After this commit: ================== If user removes quantity from any of the fields (blank space) then the input will count `0` in the backend and calculate accordingly. task - 3728728
This update fixes how property fields display and function on mobile devices. The property editor now opens in fullscreen mode with a back button for easy navigation, the edit button is always visible for touch interaction, and the popup is sized appropriately to stay within the screen boundaries. These changes make managing properties on mobile devices much more user-friendly.
Original PR description
Fix the property mobile display: - Set the popup in fullscreen. - The draggable feature is disabled. - Replacing the move up/move down property arrows in the popup by a back arrow so that the fullscreen popup can be closed. - Removing the min-width on the property popover to prevent the popup from going out of the screen. - Edit button is now always visible as hovering on it is not possible on mobile. Task-3635554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes two issues in the module management system: users can now activate modules directly from the form view, and the upgrade button now works correctly without errors. These fixes improve the user experience when managing and updating modules in the system.
Original PR description
Before this commit ================== Unable to activate the industry from the form view in the industry section. Additionally, the button in the form for upgrading would be called the button_immediate_upgrade method, resulting in errors. After this commit ================= Activation of the industry from the form view in the industry section is now possible. Furthermore, the issue with upgrading the industry from the form view has been resolved. task-3775729
This update removes an old URL pattern from the forum system that was causing unnecessary redirects. Previously, forum links using the /question/ path would redirect to the standard forum post URL, creating redundant steps. This fix eliminates that outdated redirect path, making the forum navigation cleaner and more efficient.
Original PR description
Avoid redirect to forum/<name>/question/<post> that will rediret in all case to /forum/<name>/<post>.
This fix prevents empty popups from appearing on your website when using conditional visibility settings on popup content. Previously, popups could display as empty boxes if all their content was hidden based on visibility rules. Now, if all content inside a popup is hidden, the entire popup will remain hidden from visitors, providing a better user experience.
Original PR description
When using the "Conditional Visibility" option for blocks that are inside a popup, you can end up with an empty popup. This was has been a limitation of the Conditional Visibility option for a while, but there is a real use case for wanting to only show a popup under certain circumstances. Adapting the option to take into account Popup seemed not stable enough as a lot of code is responsible for showing and hiding content that can be invisible, in edit mode. Therefore, a simpler solution was found. If the all children of the .oe_structure of a popup are in conditional visibility and are all hidden, then the popup will remain hidden. This change is done starting saas-16.3 as this is the version the OPW was opened with. opw-3734501 Forward-Port-Of: odoo/odoo#157783 Forward-Port-Of: odoo/odoo#157518
This fix resolves an issue where eLearning courses with member-only visibility could not be duplicated. The problem occurred because the enrollment policy was not being copied during duplication, causing the system to apply the default "open" enrollment setting, which conflicts with member-only visibility requirements. The fix ensures the enrollment policy is properly copied when duplicating courses.
Original PR description
In order to be able to copy the courses that have the visibility set to 'member'/'Course attendees' we need to be able to copy the enroll of the course, since this visibility requires that we have enroll set to invite and If we are unable to copy it will always be open which is the default opw-3749209 Forward-Port-Of: odoo/odoo#155843
This fix resolves an intermittent error that occurred in Firefox when quickly clicking and moving away from the "Discard" button while editing website pages. The issue was caused by Firefox triggering mouse events on text elements in an unexpected way, which other browsers don't do. The fix ensures the editor handles these events properly so users won't encounter the error anymore.
Original PR description
This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't...
Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below).
Steps to reproduce:
- open website
- go into edit mode
- actually edit the page
- add a snippet to the page
- click on the "Discard" button and move very fast out of it => the error `el.matches is not a function` is "sometimes" raised (if you got the right timing)
References:
- https://w3c.github.io/uievents/#event-type-mouseenter
- https://bugzilla.mozilla.org/show_bug.cgi?id=185889
- https://bugzilla.mozilla.org/show_bug.cgi?id=42717
- https://bugzilla.mozilla.org/show_bug.cgi?id=103055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an issue where invoicing cash orders in a new Point of Sale session would fail with an accounting error when cash rounding was enabled. The problem occurred specifically when cash rounding was configured only for cash payments. This fix ensures that cash orders can be properly invoiced without accounting imbalances.
Original PR description
Before this commit, attempting to invoice an order paid by cash in a new session, with cash rounding enabled only for cash payments in the PoS config, would result in an unbalanced entries error. opw-3813932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158781
This fix resolves a technical error that occurred when users created a new product ribbon without selecting a background color in the eCommerce module. The system was attempting to process an empty value incorrectly, causing the operation to fail. With this fix, users can now successfully create ribbons without background colors.
Original PR description
When the user creates a new ribbon without a background color, a traceback will appear. Steps to reproduce the error: - Install "website_sale" - Go to Website > eCommerce > Products - Pick a product…
When the user creates a new ribbon without a background color,
a traceback will appear.
Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close
Traceback:
```
TypeError: argument of type 'bool' is not iterable
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 74, in web_save
self = self.create(vals)
File "<decorator-gen-471>", line 2, in create
File "odoo/api.py", line 420, in _model_create_multi
return create(self, [arg])
File "addons/website_sale/models/product_ribbon.py", line 24, in create
if 'bg_color' in vals and not '!important' in vals['bg_color']:
```
https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24 Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.
sentry-5077714703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#158561This fix resolves an issue where the POS system could only recognize gift cards with a hardcoded barcode prefix (044), preventing the sale of gift cards with alternative prefixes defined in the barcode configuration. The system now correctly reads the gift card prefix settings from the barcode nomenclature configuration, allowing businesses to use their custom-defined prefixes for gift card barcodes.
Original PR description
The barcode nomenclature allows to define custom prefix for gift cards. e.g. the default nomenclature in demo data allows both 043 or 044 as prefix for rule of type coupon. Therefore the hardcoded string with 044 doesn't allow to sell a gift card whose barcode does not start with this. Instead of hardcoding the value, fetch it from the configuration and the nomenclature that is defined in the settings. OPW-3499787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error that occurred when users tried to add opportunities or leads to a contact record using Studio customization. The fix ensures the system properly handles contact relationships, allowing users to successfully add and manage linked opportunities without encountering errors.
Original PR description
## Issue: - When adding opportunity/lead to a contact using Studio and attempt to add a line, we encounter the following error:"TypeError: 'NewId' object is not iterable." ## Steps To Reproduce: - In…
## Issue:
- When adding opportunity/lead to a contact using Studio and attempt to add a line, we encounter the following error:"TypeError: 'NewId' object is not iterable."
## Steps To Reproduce:
- In a contact form open Studio and add a O2M field Customer (Lead/Opportunity)
- Try to add a line
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
## Solution:
- The issue arises in the search domain of `return_if_relevant` , exactly in ("partner_id", "child_of", lead.partner_id.commercial_partner_id.id) where the type of `lead.partner_id.commercial_partner_id.id` is NewId since the partner is being edited to add a task. This action triggers the `parse` and `to_ids` methods with a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids property refer to the record's origin ids. to resolve this, replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA recent update to the survey test suite caused an issue where multiple surveys were being created with duplicate session codes. This fix ensures that each survey receives a unique session code as required by the system. This resolves test failures and maintains data integrity in the survey module.
Original PR description
In c983f8a5 we updated the `test_survey_invite_action` test to create surveys in batch instead of one by one. This is problematic because `session_code` (given by utility method) must be unique for all surveys. Task-3829536
This update fixes a bug in the Point of Sale system where repeated errors would cause the application to crash. When an error occurred multiple times, the system would try to access order information that no longer existed, resulting in a failure. The fix ensures the system properly handles multiple error attempts and maintains stable synchronization with the server.
Original PR description
Description of the issue/feature this PR addresses: We get an undefined `reactiveOrder` when an error occurs multiple times, since on the first iteration of try-catch, order gets removed - not to be found the next iteration. Current behavior before PR: Cannot read properties of undefined. Desired behavior after PR is merged: Don't need to read properties of undefined. Also a bit of an fixup on `set_synch` call in catch block - should be connected if there is no additional orders to send and error when there is. If this change is undesired or out of this PR bounds, let me know. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where search filter defaults were not being properly applied when the search interface was initialized or updated. Users will now see the correct default filters displayed in their search results, ensuring a more consistent and predictable experience when using the search functionality.
Original PR description
Before that commit, the search defaults were removed from the WithSearch prop context by the WithSearch (search model). Fix that problem brings another one (that we also fix): The search defaults are not filtered when the WithSearch is started with a search model state or updated by its parent. Forward-Port-Of: odoo/odoo#159391 Forward-Port-Of: odoo/odoo#158833
Fixed a timing issue where enabling the room creation option on event pages would reload the page before the changes were actually saved. Users will now see their changes properly applied when they enable this feature in edit mode. This fix also addresses similar potential issues in the website sales module.
Original PR description
*: website_sale This is a follow-up of [1], which missed some occurrence of the same issue that it fixed. E.g. - Add a delay to the "write" of the event model - Go to /event/<event_id>/community - Enter edit mode - Click on the page - Enable the room creation option => The page reloads but nothing seems to have been done... it is actually *being* done: the page reloaded too soon. Note: this commit also marks some other occurrences which are not buggy but might be in the future if not properly changed. To be adapted in the master forward-port. [1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345 Forward-Port-Of: odoo/odoo#159316
This fix allows sales orders created in a branch company to access and use fiscal positions that belong to the parent company. Previously, when working with a branch company, users could not select fiscal positions defined at the parent company level, limiting flexibility in multi-company setups. This change enables better fiscal position management across company hierarchies.
Original PR description
Currently, on sale orders, you cannot access parent's fiscal positions from a branch. ### Steps to reproduce * install `sale_management` * set up a company hierarchy. Let's say we have two companies P and C such that C is a branch of P. * let's say that P has a fiscal position F * switch to company C * attempt to set fiscal position F on a sale order You will see that F does not appear on the list. opw-3773335 Forward-Port-Of: odoo/odoo#159042
The certificate used for testing Spanish tax authority (AEAT) integration has expired and is no longer valid. This fix removes the failing daily test while maintaining test coverage through alternative regional certificates (Bizkaia and Gipuzkoa) that use the same technical flow. This prevents continuous test failures without impacting the actual functionality.
Original PR description
Our certificate for aeat seems to not be valid anymore. We don't have a replacement currently. The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), where the certificate is still accepted. We remove this test that fail every day. Linked to Runbot error 25907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157278
This update fixes a test failure in the accounting module that occurred when a test ran across midnight. The test was creating a financial transaction at 23:59:59 and then running a wizard the next day at 00:00:01, causing the wizard to use the wrong date. The fix ensures the test runs consistently regardless of what time of day it executes.
Original PR description
If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, the test will fail because the wizard takes today as the date at creation. We just add a freeze_time (for this test only, as the other tests in the class don't have the issue). Linked to runbot error 60478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157981
This update fixes an issue where the notification system in Odoo could fail on databases with heavy activity because message payloads exceeded PostgreSQL's 8KB limit. The fix automatically splits large messages into smaller chunks to ensure they process correctly. A new configuration option is also added for users running custom PostgreSQL setups.
Original PR description
## Description On a database with heavy activity, it is possible for the payload size we pass for the `NOTIFY` query on the bus to be larger than what PostgreSQL allows by default, 8000 B. This limit…
## Description On a database with heavy activity, it is possible for the payload size we pass for the `NOTIFY` query on the bus to be larger than what PostgreSQL allows by default, 8000 B. This limit is defined as [src1](https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L158-L166) and is used to compare the size of the payload before processing [src2](https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L654-L657) ## Fix - Binary split the payload into multiple chunks if it's exceeding the above-mentioned limit. The unit of splitting is a channel, so if the content of one channel itself is larger than said limit, it is not handled, but shouldn't occur under normal circumstances. - Introduce also a new ENV variable `ODOO_NOTIFY_PAYLOAD_MAX_LENGTH` to allow tweaking of the limit if they are running a handrolled custom PostgreSQL cluster. ## Reference opw-3650618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159253 Forward-Port-Of: odoo/odoo#154463
This fix resolves a problem where website menu items weren't properly highlighting as active when navigating between product pages. The issue occurred because the menu cache wasn't being cleared correctly when menus were updated. This fix ensures that when customers click on different product links in the menu, the correct menu item is highlighted as active.
Original PR description
[This commit] fixed an issue with the menu cache. Unfortunately, during the forward port, we missed updating the cache key according to what has been done in [this other commit]. This commit updates…
[This commit] fixed an issue with the menu cache. Unfortunately, during the forward port, we missed updating the cache key according to what has been done in [this other commit]. This commit updates the cache key and improves the test. Steps to reproduce the bug fixed by this commit: - Render a website without a record URL in the menu (to fill the cache) - Edit the website's menu - Add a link to a product page (e.g., customizable-desk) - Add a link to another product (e.g., chair-floor-protection) - Save the menu - Click on the menu link to go to customizable-desk => At this point, the active menu element is correct - Click on the menu link to go to chair-floor-protection => The active menu element does not update This issue does not occur if there is a record like URL in the menu before the first render. [This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68 [this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35 opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/odoo#159429