Daily updates from Odoo
Navigate
Branch
Thursday, June 13, 2024
68 changes
18 changes
Enhancements to existing features
Age Group and Manufacturer attributes created through product barcode lookup are now visible to users. This makes product data easier to review and use in related product workflows.
Original PR description
- We have given visibility to Age Group and Manufecturer attributes created in product_barcodelookup. Related: https://github.com/odoo/enterprise/pull/63740/ task- 3965079
Resolved issues and error corrections
The point of sale now loads much faster for businesses with large product catalogs and many pricelists. This reduces waiting time when opening the POS, improving store readiness and staff productivity.
Original PR description
Before this commit, loading the POS took a long time when there were more than 1000 products and pricelists. The reason was that the `computeProductPricelistCache` function had a time complexity of O(n^2 * m) due to nested loops over products and pricelist items, and several calls to the raw function which is O(n) itself. This commit optimizes the `computeProductPricelistCache` function by performing a single loop over pricelist items and another over products. This change improves the loading speed from 10 minutes to 10 seconds with 1000 products and pricelist items. opw-3978067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now only retries failed partner creation when the issue is a connection problem. This prevents an incorrect tax ID error from being repeatedly reused, so staff can correct the tax ID and continue without being blocked by the earlier failed attempt.
Original PR description
When trying to create a partner with a wrong tax id, the create would fail. But with the new data_service, the create would be repeated to try to create the record again. Steps to reproduce:…
When trying to create a partner with a wrong tax id, the create would fail. But with the new data_service, the create would be repeated to try to create the record again. Steps to reproduce: ------------------- * Open PoS session and create a partner from PoS, you can select belgium as country and BE40301926 as tax id * You will get an error saying the tax id is wrong * Now try to put a correct tax id like BE403019261 > Observation: You still get the error Why the fix: ------------ When trying to create the record we end up here https://github.com/odoo/odoo/blob/28b7d698be8255f933ba5314e44e7059746fc234/addons/point_of_sale/static/src/app/models/data_service.js#L161-L164 because the server returns an error. And later on we will try to redo all the failed actions in `async syncData()`. But it will fail again as the values are still wrong. To fix this we check that the error is not an RPCError before adding it to the queue. opw-3943486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refund bills without a bill date no longer crash when users add products from the catalog. This keeps the purchasing and billing workflow usable when the date is intentionally left blank.
Original PR description
This traceback occurs when the user created a refund bill with no invoice date and tries to add a product through the catalog. To reproduce this issue:- 1) Install `purchase` 2) Create a new product…
This traceback occurs when the user created a refund bill with no invoice date and tries to add a product through the catalog. To reproduce this issue:- 1) Install `purchase` 2) Create a new product and add a `vendor` with a `start` and `end` date in the `purchase page` of the product. 3) Now create a `refund bill` for the above-created vendor from the invoice 4) Don't give the `bill date` and try to add a product from `Catalog` 5) A traceback occurs. Error:- ``` TypeError: '>' not supported between instances of 'datetime.date' and 'bool' ``` As you can see `invoice_date` is not required when creating a refund bill. But here the `invoice_date` is used when selecting a product through catalog. https://github.com/odoo/odoo/blob/c8985212fb4c937b814aaf7fe2ddca992b01735c/addons/account/models/account_move.py#L2168-L2172 So the `invoice_date` value will be `False`. But here only the `None` case is handled for the date in the `_select_seller` method https://github.com/odoo/odoo/blob/c8985212fb4c937b814aaf7fe2ddca992b01735c/addons/product/models/product_product.py#L646-L647 which leads to the above traceback when a comparison is made between bool and DateTime. https://github.com/odoo/odoo/blob/c8985212fb4c937b814aaf7fe2ddca992b01735c/addons/product/models/product_product.py#L659-L662 After applying this commit will resolve this issue by handling the False case also. sentry-5475144539
This fixes an issue in Point of Sale where tax details could be calculated using the wrong reference, causing incorrect or missing tax information. The change helps ensure sales tax data is recorded and displayed reliably during POS transactions.
Original PR description
Before this commit, taxValues.taxId was used as the key for taxDetails, which was undefined because it doesn't have a taxId property. The correct property to use is 'id'. This misuse was leading to several problems. opw-3969647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The favorite marker on product forms now correctly follows read-only rules, preventing users from changing it when the record should not be editable. This helps keep product information consistent and avoids unintended updates in restricted views.
Original PR description
added readonly behaviour to the boolean_favorite widget opw-3933386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue this PR addresses: Paragraphs are not admitted in list items in the editor. But the way they were sanitized away was broken. After commit [1] contiguous paragraphs in a list item were converted to their own new list item with oe-nested class to remove the bullet point (eg, `<li><p>a</p><p>b</p></li>` became `<li>a</li><li class=oe-nested>b</li>`), which broke some snippet using paragraphs nested within list item. This commit convert those p tags with attributes
Original PR description
Description of the issue this PR addresses: Paragraphs are not admitted in list items in the editor. But the way they were sanitized away was broken. After commit [1] contiguous paragraphs in a list item were converted to their own new list item with oe-nested class to remove the bullet point (eg, `<li><p>a</p><p>b</p></li>` became `<li>a</li><li class=oe-nested>b</li>`), which broke some snippet using paragraphs nested within list item. This commit convert those p tags with attributes to span tags and use `<br>` tags to separate those spans and unwraps those without attributes. task-3932057 [1]: https://github.com/odoo/odoo/commit/3f9938823189935a013846db9c9a96b5d8bd15d0 Forward-Port-Of: odoo/odoo#168959 Forward-Port-Of: odoo/odoo#166433
Mollie has now started supporting Twint as a payment method. task-3859061 Forward-Port-Of: odoo/odoo#168021
Original PR description
Mollie has now started supporting Twint as a payment method. task-3859061 Forward-Port-Of: odoo/odoo#168021
After this commit: https://github.com/odoo/odoo/commit/88782d3a76fb3941b9ed7d998ec0610aa26ff611#diff-5e2dc39b3b508222892a48d869e4c958557e1881f6d54d7590831f9132ac68a9R289-R291 this error is raised when you have a manual created payment method: ``` RPC_ERROR Odoo Server Error Traceback (most recent call last): File "/opt/odoo/custom/src/odoo/odoo/api.py", line 909, in get return field_cache[record._ids[0]] KeyError: <NewId 0x7f703fa9ec70> During handling of the above exception,
Original PR description
After this commit: https://github.com/odoo/odoo/commit/88782d3a76fb3941b9ed7d998ec0610aa26ff611#diff-5e2dc39b3b508222892a48d869e4c958557e1881f6d54d7590831f9132ac68a9R289-R291 this error is raised…
After this commit:
https://github.com/odoo/odoo/commit/88782d3a76fb3941b9ed7d998ec0610aa26ff611#diff-5e2dc39b3b508222892a48d869e4c958557e1881f6d54d7590831f9132ac68a9R289-R291
this error is raised when you have a manual created payment method:
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 909, in get
return field_cache[record._ids[0]]
KeyError: <NewId 0x7f703fa9ec70>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1083, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 912, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'account.journal(<NewId 0x7f703fa9ec70>,).available_payment_method_ids'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_http.py", line 242, in _dispatch
result = request.dispatch()
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 702, in dispatch
result = self._call_function(**self.params)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 368, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 357, in checked_call
result = self.endpoint(*a, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 925, in __call__
return self.method(*args, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 546, in response_wrap
response = f(*args, **kw)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1324, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1316, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 471, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 456, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 6527, in onchange
todo = [
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 6530, in <listcomp>
if name not in done and snapshot0.has_changed(name)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 6340, in has_changed
len(self[name]) != len(record[name])
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5936, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 2620, in __get__
return super().__get__(records, owner)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1132, in __get__
self.compute_value(recs)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1295, in compute_value
records._compute_field_value(self)
File "/opt/odoo/auto/addons/mail/models/mail_thread.py", line 411, in _compute_field_value
return super()._compute_field_value(field)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 4277, in _compute_field_value
fields.determine(field.compute, self)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 88, in determine
return needle(*args)
File "/opt/odoo/auto/addons/account/models/account_journal.py", line 312, in _compute_available_payment_method_ids
if manage_acquirers and method_information_mapping[[line.payment_method_id.id](http://line.payment_method_id.id/)]['mode'] == 'electronic':
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 658, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
KeyError: 16
```
This PR adds the same condition used here:
https://github.com/odoo/odoo/blob/000579b7aa3cb640a642ae62162f651cce621790/addons/account/models/account_journal.py#L523
@Tecnativa TT49364
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#168460Problem --------- Currently, if an email containing a lot of images and documents reaches the mail alias, one invoice will be created for each attachment (image, PDF, XML, etc.) in the mail. This can pollute databases as, nowadays, many emails possess rogue images with link to Facebook, Twitter, branding, etc. Objective --------- Do not create an attachment for images in the mails from a mail alias. Solution --------- Filter out the binary file data that have not been yet extracted;
Original PR description
Problem --------- Currently, if an email containing a lot of images and documents reaches the mail alias, one invoice will be created for each attachment (image, PDF, XML, etc.) in the mail. This can pollute databases as, nowadays, many emails possess rogue images with link to Facebook, Twitter, branding, etc. Objective --------- Do not create an attachment for images in the mails from a mail alias. Solution --------- Filter out the binary file data that have not been yet extracted; this ensures that only rogue images are filtered out. The other file types will create new invoices like before. epr-63997 task-3973973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168305
### Steps to reproduce: - Install **POS** app. - Go to **POS** > **Products** > **Discount & Loyalty** - Create a New program with: - **Program Type:** Loyalty Cards - Conditional rules: - **Minimum Quantity:** 2 - **Grant:** 1 Loyalty Points per unit paid - Rewards: - **Reward Type:** Discount - **Discount:** 100 % one Cheapest Product - **In exchange of:** 2 Loyalty Points - Start a new POS session - Select a Customer - A
Original PR description
### Steps to reproduce: - Install **POS** app. - Go to **POS** > **Products** > **Discount & Loyalty** - Create a New program with: - **Program Type:** Loyalty Cards - Conditional rules: - **Minimum…
### Steps to reproduce:
- Install **POS** app.
- Go to **POS** > **Products** > **Discount & Loyalty**
- Create a New program with:
- **Program Type:** Loyalty Cards
- Conditional rules:
- **Minimum Quantity:** 2
- **Grant:** 1 Loyalty Points per unit paid
- Rewards:
- **Reward Type:** Discount
- **Discount:** 100 % one Cheapest Product
- **In exchange of:** 2 Loyalty Points
- Start a new POS session
- Select a Customer
- Add two different products.
- Notice the Loyalty Points of **+2** shown. This is _Correct_
- Click on the **Reward** button
- Notice how the Loyalty Points are now **+3** which is obviously _wrong_ given we only have two products. Basically it's as if the reward line (100% discount) is taken into consideration as the cheapest product.
### Investigation:
- Inside `_updatePrograms`, `pointsForPrograms()` are calculated.
- we sum the lines quantities regardless of whether it's a reward line or not https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L906
- By doing so, the reward lines are taken into consideration and the rule is triggerd by skipping this if clause https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L917-L921
opw-3855323
Forward-Port-Of: odoo/odoo#166099
Forward-Port-Of: odoo/odoo#161503Previously, when the attempting to decode a pdf or xml file as EDI attachment, if an xml or pdf file was malformed, we would log a warning (for pdf) or error (for xml). There are tests in which we post messages to the chatter with an XML file with embedded PDF which is actually a generated report. These tests don't actually generate a valid PDF because wkhtmltopdf isn't available in those tests, but these tests also do not particularly care that the PDF is valid. Similarly, there are tests th
Original PR description
Previously, when the attempting to decode a pdf or xml file as EDI attachment, if an xml or pdf file was malformed, we would log a warning (for pdf) or error (for xml). There are tests in which we…
Previously, when the attempting to decode a pdf or xml file as EDI attachment, if an xml or pdf file was malformed, we would log a warning (for pdf) or error (for xml). There are tests in which we post messages to the chatter with an XML file with embedded PDF which is actually a generated report. These tests don't actually generate a valid PDF because wkhtmltopdf isn't available in those tests, but these tests also do not particularly care that the PDF is valid. Similarly, there are tests that post messages with xml attachments that don't contain valid xml but they also do not care that the xml in valid in those flows. The linked enterprise PR adds an override of _message_post that will attempt to decode posted attachments so that it can take some action based on their contents. While this works perfectly fine and doesn't break any behaviour, as the decoding methods will simply return an empty list when the attachments are malformed, because they log warnings or errors, it causes tests/runbot to fail. The information that an invalid xml or pdf was uploaded is not particularly useful or urgent information for the server admin, and users already get a notification when uploading a malformed file. As such, this commit changes these warning/exception logs to simple info logs. This means this information remains available but isn't given disporoportionate importance in the logs, and doesn't cause tests that work perfecly fine to fail. task-3731034 Forward-Port-Of: odoo/odoo#166459
Current behavior: When doing multiple orders with invoices, then generating the sale details report of the session. The total amount for the invoices would be incorrect. It would be the value of the last invoice Steps to reproduce: - Open PoS session - Make at least 2 orders and invoice them - Close the session - Go in Order > Session, select the session you just closed - Click on the little gear, and generate the sale details report - Go to the invoices part of the report, the Total d
Original PR description
Current behavior: When doing multiple orders with invoices, then generating the sale details report of the session. The total amount for the invoices would be incorrect. It would be the value of the last invoice Steps to reproduce: - Open PoS session - Make at least 2 orders and invoice them - Close the session - Go in Order > Session, select the session you just closed - Click on the little gear, and generate the sale details report - Go to the invoices part of the report, the Total doesn't match the total of all the lines. It's the same value as the last line opw-3930210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168484
since 9338ac01745156abff2bf7606c2679f7c623bb81, we were erroneously giving all the templates whose price was computed to the taxes computation logic, when we should have been giving one template at a time (as we were looping on the templates here). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168888
Original PR description
since 9338ac01745156abff2bf7606c2679f7c623bb81, we were erroneously giving all the templates whose price was computed to the taxes computation logic, when we should have been giving one template at a time (as we were looping on the templates here). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168888
Before this commit, the mode was sometimes ambiguous in certain cases After this commit, if we forget to provide the mode, we will always consider the shipping mode as the default. Forward-Port-Of: odoo/odoo#168910
Original PR description
Before this commit, the mode was sometimes ambiguous in certain cases After this commit, if we forget to provide the mode, we will always consider the shipping mode as the default. Forward-Port-Of: odoo/odoo#168910
BEFORE (runbot 30/05/2024): https://github.com/odoo/odoo/assets/56789189/81f717b0-29c2-4ae5-8fc0-89b8c6fbf6b4 AFTER: https://github.com/odoo/odoo/assets/56789189/acd9777c-bb46-4aff-a7a9-4f389768fc55 STEP TO REPRODUCE: -Create a payment 15 days after invoice date with one payment term line only -The preview of payment term now should be display on the right bottom corner but it doesn't until we create a second line for it FIX by correct computation of 'example_invalid' will now bec
Original PR description
BEFORE (runbot 30/05/2024): https://github.com/odoo/odoo/assets/56789189/81f717b0-29c2-4ae5-8fc0-89b8c6fbf6b4 AFTER: https://github.com/odoo/odoo/assets/56789189/acd9777c-bb46-4aff-a7a9-4f389768fc55 STEP TO REPRODUCE: -Create a payment 15 days after invoice date with one payment term line only -The preview of payment term now should be display on the right bottom corner but it doesn't until we create a second line for it FIX by correct computation of 'example_invalid' will now become True if none lines found 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#167289
* In standard: enable tracking on partner name * In l10n_de: enable tracking on SteuerNr. * Constraint on account : "You can not change the code/name of an account if it contains hashed entries." * enable audit trail by default when loading a new German CoA taskid: 3950840 Forward-Port-Of: odoo/odoo#167973
Original PR description
* In standard: enable tracking on partner name * In l10n_de: enable tracking on SteuerNr. * Constraint on account : "You can not change the code/name of an account if it contains hashed entries." * enable audit trail by default when loading a new German CoA taskid: 3950840 Forward-Port-Of: odoo/odoo#167973
Improve runtime of `stock.forecasted_product_product._get_report_lines` by reducing total query count, as well as some other minor optimizations. Reduce query count of `_get_report_lines` by: 1.) Introducing and utilizing two new `stock.move` methods, `_rollup_move_dests_fetch` and `_rollup_move_origs_fetch`. (More details below) 2.) Share _prefetch_ids between linked moves. By grouping their prefetching together we will ensure that fewer unnessesary queries will be made. Without doing this
Original PR description
Improve runtime of `stock.forecasted_product_product._get_report_lines` by reducing total query count, as well as some other minor optimizations. Reduce query count of `_get_report_lines` by: 1.)…
Improve runtime of `stock.forecasted_product_product._get_report_lines` by reducing total query count, as well as some other minor optimizations. Reduce query count of `_get_report_lines` by: 1.) Introducing and utilizing two new `stock.move` methods, `_rollup_move_dests_fetch` and `_rollup_move_origs_fetch`. (More details below) 2.) Share _prefetch_ids between linked moves. By grouping their prefetching together we will ensure that fewer unnessesary queries will be made. Without doing this, then for N linked moves there would be at least N queries for each linked move during all the calls to `_get_out_move_reserved_data`. With prefetching we are at least making N/1000 queries, which is much better. Ultimately, it would be most optimal to use `.read` to make only one query up front - but this would likely require a total rework of much of the code in `stock.forecasted_product_product` (as well as modules which inherit from this). Prefetching is much simpler for now, and the gains are good enough to warrant doing it. 3.) Call `fetch` to get the `state` and `quantity` fields from all sibling moves. These could instead be added into the consolidated prefetch_ids. Maybe that is more preferable, but I think `fetch` here is OK because we only need those two fields from the sibling moves. Other minor optimizations include: 1.) Use sets instead of recordsets where it would make sense to do so. Because, when the `in` operator is used, it is more efficient to use set's `in` (O(1)) vs recordset's `in` (O(N)). 2.) Use `._ids` instead of `.ids` where we can get away with it. In places where we are have freshly searched recordsets, there is no possibility for any NewIds to be present. So it should be safe to use `._ids` here, which avoids some extra constant time work that `.ids` would impose. `_rollup_move_x_fetch` (x is dests or origs): These methods are intended to be used to reduce the total number of queries made in situations where you have N moves and you need to call `_rollup_move_x` on all of them. If you do this, for each move you call rollup on, you'd make O(len(P)) queries where P is the longest "path" formed in the tree of moves. Since you do this N times, you'd end up overall with O(N*len(P)) queries. If you call `_rollup_move_x_fetch` on a recordset containing all N moves, it loads all of the moves into the cache that would have to be loaded if you call `_rollup_move_x` on all of them individually. The number of queries `_rollup_move_x_fetch` makes for N records is only O(len(P)), because it is able to traverse the move tree in a breadth first manner for all nodes, loading as many as is possible at each step. Since len(P) is likely to be small for any given database (citation needed), you could effectively consider it constant O(1). Even in the worst case, where all the moves only form a single long path, len(P) will be at most N. Once you then call `_rollup_move_x` on each individual move, because all the moves are already loaded into the cache it will make 0 queries. This leaves us with the following conclusion: `_rollup_move_x` alone is ~O(N) queries, and `_rollup_move_x` with `_rollup_move_x_fetch` beforehand is ~O(1) queries. In the worst case described where len(P)=N, it will degrade to O(N), which would not be any different than before. Benchmarks: In the customer's database locally, (after re-adding `components_availability` and `components_availability_state` to their view, which was removed previously as a work-around): Log line stats for loading the manufacturing order list view: | | # queries | SQL time | Odoo time | total time | |-------------------------|--------------------|------------------|-----------------|-------------------| | before commit | 149128 | 23.736 s | 46.842 s | 70.578 s | | after commit | 144 | 0.914 s | 11.335 s | 12.249 s | | | | | | | | % improvement | ~915x fewer | ~26x faster | ~4x faster | ~5.7x faster | Before and after commit pretty much all of the Odoo time of the request is spent in `_get_report_lines`, so I don't think it's necessary to provide benchmarks seperately for this function. Help Ticket # to see also which exhibit this issue: 3818495 3918816 3920584 3935316 opw-3769280 Forward-Port-Of: odoo/odoo#167806
35 changes
Enhancements to existing features
When users insert a pivot table or list into an existing spreadsheet, the sheet is automatically renamed after that pivot or list, including its identifier. This makes spreadsheets easier to navigate and helps users quickly recognize where each data source is located.
Original PR description
With this revision, when a pivot is inserted in an existing spreadsheet, the name of the sheet in which this pivot is inserted is the name of this pivot (with its formulaId) Task: 3953748
Appointment upfront payment setup now limits selectable service products to those without special tracking requirements. This prevents staff from choosing event- or booth-related services that cannot be processed correctly in appointment sales orders.
Original PR description
Before this commit for appointment upfront payment user was able to select a product with service type but in service type some tracking type like event and booth has constraint on sale order line it require event and event ticket and because that user can't use that type of products This commit only allow to select service_tracking with `no` type for appointments. task-3959899
SAF-T accounting files now keep the official JournalID as the journal code and TransactionID as the entry name, instead of using generated codes or descriptions. This improves alignment with Danish SAF-T requirements and makes imported and exported accounting data easier to trace and reconcile.
Original PR description
For saft files, changed journal code to be the JournalID (instead of having auto-generated incremental journal codes). Also, changed move name to be TransactionID instead of description. The tests in the l10n_dk_saft_import were adjusted accordingly. These changes were needed for both SAF-T import and export according to the Danish SAF-T technical description. task-3599029
The Gantt views in Attendance and Payroll now open on the most relevant current period instead of showing extra future periods. This makes schedules and work entries easier to review by focusing users on today in Attendance and the current month in Payroll.
Original PR description
Following the gantt view rework, you see directly 3 periods of time on your selection, 3 months, 3 days, 3 years, ... But, in attendance and payroll apps, there is no use of that. The current changes address this. In attendance, the start and stop dates are now set to today instead of having the start date as today and the stop date 2 days after. In payroll, the start date is now set to the start of the current month and the end date is now set to the end of the current month instead of having the start date as the start of the current month and the end date as the end of the month that comes after the current month by 2. targets: 17.3 task-3950880
Payslips that were previously shown as "Rejected" will now be labeled "Canceled". This makes the payroll status clearer for users and better reflects that the payslip is no longer active.
Original PR description
The state label of the payslip is changed to 'Canceled' to make it more clear that the payslip is rejected. task-3858697
This update makes translated messages easier to adapt across languages by using clearer placeholders. It also ensures displayed text is properly escaped, reducing the risk of incorrect or unsafe rendering in accounting and localization screens.
Original PR description
- Name translated string parameters to make it possible to move them around in translations and make the translators' job a bit nicer - Make sure all rendered strings go through Markup or html_escape In general, if a named parameter isn't useful to translators then it won't be added here (e.g. strings that already provide enough context with one parameter) task-3884350 **Community PR:** odoo/odoo#165186
Miscellaneous journals can now receive documents through email aliases, matching the existing behavior for sales and purchase journals. Belgian SODA files can also be processed from emailed documents, making payroll-related accounting entries easier to create automatically.
Original PR description
Allow to define email aliases on Misc journals (same as is already the case on Sale & Purchase journals). Create edi_decoder for soda to allow creation of SODA entries via alias. Task: 3829571 Community PR: https://github.com/odoo/odoo/pull/161085
Field service planners can now see customer address and phone details directly in planning popovers. This helps teams assess nearby visits, plan routes more efficiently, and contact customers without opening each task individually.
Original PR description
**Prior to this commit**, the Gantt view popover lacked information about customer location and their phone number. When planning an intervention, especially if already in the area, the only option was to check each planned task individually. **With this commit**, we enhance the Gantt view popover by including address and phone number details. This improvement allows someone in the area to quickly check the information of every customer, facilitating efficient journey planning, including route details and locations. Additionally, users can directly contact customers. task-3617833
The Approvals app now makes automation rules easier to access by adding them directly under the Configuration menu. It also provides ready-to-use triggers such as actions when requests are archived or unarchived, helping teams adapt approval flows with less setup effort.
Original PR description
In the scope of approvals, Automations are something that should be really put in front cause the power of the app is to adapt to each flow that's not already defined in Odoo. So, the menu to add a new one should be more visible. Also, having a good set of predefined triggers is a necessity. 1. Thus, a menuitem is added in the approvals app `Approvals app->Configuration->Automated Actions` to ease the access of automation rules. Also, some predefined triggers are added such as `on archived` and `on unarchived` to ease their access and usage. task-3872042
Manufacturing planners can now adjust the time range shown in the Master Production Schedule directly from the planning view, instead of changing global MRP settings. The update also adds a yearly range, lets administrators define how many columns appear per range, and improves default XLS/CSV exports so users get useful fields automatically.
Original PR description
This pr adds the possibility to change directly the time range used in the MPS gantt planning and default export fields. Previously, it was only possible to change the time range in the settings of MRP, which was not convenient. The use can now change it directly in the view. It will not impact the settings and refreshing the page will reset the range chosen in the settings. Added the "Year" range. There is also the possibility to determinate the number of columns to display for each range in the MRP settings. In addition, the export to xls/csv did not contain any fields by default. It was due to the view not inheriting from the `ListController`. The solution found is to create a template, to pass the id to the dialog thanks to the context, and then loading that template as the default one. Task-3288653
The Knowledge app was updated to keep the custom favorite dialog working after related platform changes. This is a small compatibility improvement that helps preserve the expected favorite setup experience for users.
Original PR description
This commit changes CustomFavoriteItem xpath to target CustomFavoriteDialog instead following changes made in https://github.com/odoo/odoo/pull/145019. Task ID: 3609385
The spreadsheet integration was aligned with the latest spreadsheet engine behavior, including faster pivot updates. Some older list and pivot side panels were removed or adjusted to keep the experience simpler and consistent with the updated spreadsheet tools.
Manual reconciliation now lets users choose either an account or a partner when preparing entries. This gives accounting teams more flexibility while preventing conflicting selections by allowing only one choice at a time.
Original PR description
Before this commit : The user was only able to select an Account. After this commit : The user is now able to select an Account or a Partner, but not both. task-3857495
Resolved issues and error corrections
This update removes an outdated field service reporting search setup that is no longer needed after related platform changes. It helps keep the module aligned with the latest shared project functionality and reduces unnecessary maintenance.
Original PR description
This PR removes an inherited search view that is no longer necessary thanks to the changes in the community PR. Task-3978479 Community: https://github.com/odoo/odoo/pull/169116
This fixes an internal dependency issue in payroll by moving bank account verification to the payroll accounting area where it belongs. It helps keep payroll imports and related payment reporting aligned with the correct app structure, reducing installation or maintenance issues.
Original PR description
iban base is an addon related to `account`, the verification method is moved to `hr_payroll_account` so that imports can correspond to the manifest.
Code cleanup and technical improvements
This update adds validation to guided test steps so incorrectly structured steps stop immediately with a clear error. This helps teams catch test setup mistakes earlier, improving reliability across modules that use guided tours.
Original PR description
In this commit, we add a check of the composition of a tour step (the keys and values of the object). Using an unauthorized key or a value that has the wrong type returns an error and ends the tour. task~3974087 https://github.com/odoo/odoo/pull/168837
Miscellaneous changes
[ADD] account_accountant_check_printing: Add check number to bank rec desired behavior: If Checks are activated in the Accounting settings, add a new column in the Bank Reconciliation widget for payment_id.check_number, in optional=hide Reason: the Check Number is a very useful information to display in the Bank Reconciliation. solution: create new module dependent on accounting and account_check_printing modules and add the desired column and method there. Task-3869134 Forward-Por
Original PR description
[ADD] account_accountant_check_printing: Add check number to bank rec desired behavior: If Checks are activated in the Accounting settings, add a new column in the Bank Reconciliation widget for payment_id.check_number, in optional=hide Reason: the Check Number is a very useful information to display in the Bank Reconciliation. solution: create new module dependent on accounting and account_check_printing modules and add the desired column and method there. Task-3869134 Forward-Port-Of: odoo/enterprise#60849
The helper setScale is no longer async and triggers a change in the gantt model and a gantt renderer rendering after some milliseconds (see debounce in GanttRendererControls). If we do not wait that rendering to select a new time range via the date pickers, those date pickers can close too early and make the test helper crash. To fix that problem, we use the helper ganttControlsChanges that run all timers and wait for a suitable number of animation frames. Runbot issue: 67941 Forward-Port-O
Original PR description
The helper setScale is no longer async and triggers a change in the gantt model and a gantt renderer rendering after some milliseconds (see debounce in GanttRendererControls). If we do not wait that rendering to select a new time range via the date pickers, those date pickers can close too early and make the test helper crash. To fix that problem, we use the helper ganttControlsChanges that run all timers and wait for a suitable number of animation frames. Runbot issue: 67941 Forward-Port-Of: odoo/enterprise#64541
opw-3958044 opw-3948546 Forward-Port-Of: odoo/enterprise#64494 Forward-Port-Of: odoo/enterprise#64069
Original PR description
opw-3958044 opw-3948546 Forward-Port-Of: odoo/enterprise#64494 Forward-Port-Of: odoo/enterprise#64069
Problem: When the user creates a new quotation from a CRM opportunity, the quotation does not compute to the partner's usage value and always default to "General Usage". The default prevents the compute from getting called. Purpose: The compute method "_compute_l10n_mx_edi_usage" should be called when a new quotation is created from the crm opportunity. Steps to Reproduce on Runbot17: 1. Install Sales, l10n_mx, l10n_mx_edi, CRM, Contacts 2. Set a value for field "Usage" (l10n_mx_edi_usag
Original PR description
Problem: When the user creates a new quotation from a CRM opportunity, the quotation does not compute to the partner's usage value and always default to "General Usage". The default prevents the compute from getting called. Purpose: The compute method "_compute_l10n_mx_edi_usage" should be called when a new quotation is created from the crm opportunity. Steps to Reproduce on Runbot17: 1. Install Sales, l10n_mx, l10n_mx_edi, CRM, Contacts 2. Set a value for field "Usage" (l10n_mx_edi_usage) on a partner whose country is Mexico in Contacts 3. Create a CRM opportunity with the partner above 4. Create a new quotation from the opportunity and observe that the "Usage" value is not the same as defined on the partner opw-3934009 Forward-Port-Of: odoo/enterprise#64520 Forward-Port-Of: odoo/enterprise#63766
The test `test_action_reload_ai_data` added by commit f85e392 introduced a new undeterministic failure when the test is run at around midnight. This is the exact same issue that occurred in another of these tests and that was fixed by commit a4fbd4c. This commit solves the problem in a more generic way, by freezing the date so that the `create_date` and the default `invoice_date_due` always match. It should prevent the issue from re-appearing in future new tests. Forward-Port-Of: odoo/ent
Original PR description
The test `test_action_reload_ai_data` added by commit f85e392 introduced a new undeterministic failure when the test is run at around midnight. This is the exact same issue that occurred in another of these tests and that was fixed by commit a4fbd4c. This commit solves the problem in a more generic way, by freezing the date so that the `create_date` and the default `invoice_date_due` always match. It should prevent the issue from re-appearing in future new tests. Forward-Port-Of: odoo/enterprise#64361 Forward-Port-Of: odoo/enterprise#64130
This PR fixes two issues that are closely related, so I'm handling them in the same PR. ### Skip forbidden country check if no XSD present In https://github.com/odoo/odoo/pull/115720 downloading of XSD's for validation was made optional and related checks were skipped if the relevant XSD was not present. That's currently not done when generating a XAF report in the Dutch localization. The XSD contains the list of valid countries allowed in the report. If there is no XSD, no country is
Original PR description
This PR fixes two issues that are closely related, so I'm handling them in the same PR. ### Skip forbidden country check if no XSD present In https://github.com/odoo/odoo/pull/115720 downloading of…
This PR fixes two issues that are closely related, so I'm handling them in the same PR. ### Skip forbidden country check if no XSD present In https://github.com/odoo/odoo/pull/115720 downloading of XSD's for validation was made optional and related checks were skipped if the relevant XSD was not present. That's currently not done when generating a XAF report in the Dutch localization. The XSD contains the list of valid countries allowed in the report. If there is no XSD, no country is allowed. This can result in the user being presented with an error that partners in the Netherlands are not allowed. This fix skips the country check if the XSD is not present. The downside of that is not having this validation by default, since the XSD is not downloaded by default. An alternative would be to hardcode the list. opw-3957513 ### Missing prefix when checking for XSD When generating a XAF report, allowed country codes for partners are loaded from an XSD. By default this XSD is not present. If it's manually downloaded through the settings, it still didn't work because the name of the attachment searched for does not include the module prefix while the name of the downloaded attachment does. This fix includes the prefix in the search. opw-3957513 Forward-Port-Of: odoo/enterprise#64348
When installing the l10n_be_us_consolidation_demo module, there is a traceback and invoice data is not installed. ### Steps to reproduce: - Create a new DB with nothing installed and demo data not active - Install l10n_be_us_consolidation_demo - 'Activate the developer mode' in settings page - 'Load Demo Data' in settings page and confirm - Check logs and see traceback ### Cause: The account.move is created with the default company and the account.move.line if forced to be created wi
Original PR description
When installing the l10n_be_us_consolidation_demo module, there is a traceback and invoice data is not installed. ### Steps to reproduce: - Create a new DB with nothing installed and demo data not active - Install l10n_be_us_consolidation_demo - 'Activate the developer mode' in settings page - 'Load Demo Data' in settings page and confirm - Check logs and see traceback ### Cause: The account.move is created with the default company and the account.move.line if forced to be created with an account from the company "l10n_be.demo_company_be". In the end the move and its lines does not have the same company, so the record creation fails in check_company(). ### Solution: Specify the company of the account.move in the record to be the same as the lines. opw-3952634 Forward-Port-Of: odoo/enterprise#64366 Forward-Port-Of: odoo/enterprise#63903
To reproduce: ============= - install Project and Documents - create a project - give the user the project admin rights and **User** rights for the Documents module - try to rename a project -> access error Problem: ======== when Document is installed, every project has a related folder in the Documents. When renaming a project, the folder name should be updated as well. As the user has no rights to write on Documents, the renaming fails. Solution: ========= set the folder name as
Original PR description
To reproduce: ============= - install Project and Documents - create a project - give the user the project admin rights and **User** rights for the Documents module - try to rename a project -> access error Problem: ======== when Document is installed, every project has a related folder in the Documents. When renaming a project, the folder name should be updated as well. As the user has no rights to write on Documents, the renaming fails. Solution: ========= set the folder name as `sudo` to avoid access errors opw-3928018 Forward-Port-Of: odoo/enterprise#64415 Forward-Port-Of: odoo/enterprise#63787
Fixed the bug where customized image names containing a dot (.) were not correctly reformed in the generator. The issue caused a mismatch between the image names in the scraper folder and the names searched for by the generator. Forward-Port-Of: odoo/enterprise#64423
Original PR description
Fixed the bug where customized image names containing a dot (.) were not correctly reformed in the generator. The issue caused a mismatch between the image names in the scraper folder and the names searched for by the generator. Forward-Port-Of: odoo/enterprise#64423
Open Accounting Dashboard On "Customer Invoices" card, hit 3 dots> Payment Matching Select any invoice, hit reconcile button, fill Account and Tax Click 'Reconcile & Open' Open the created write off entry Issue: Tax line has been created but the base line tax field is empty. This will create an inconsistency in tax reports opw-3893394 Forward-Port-Of: odoo/enterprise#62631
Original PR description
Open Accounting Dashboard On "Customer Invoices" card, hit 3 dots> Payment Matching Select any invoice, hit reconcile button, fill Account and Tax Click 'Reconcile & Open' Open the created write off entry Issue: Tax line has been created but the base line tax field is empty. This will create an inconsistency in tax reports opw-3893394 Forward-Port-Of: odoo/enterprise#62631
This [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a) introduced a change in the way the `partner_write_date` is formatted. It changed the separator from `T` to ` `, which was wrong and leads to failed XSD validation. opw-3944774 Forward-Port-Of: odoo/enterprise#64330
Original PR description
This [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a) introduced a change in the way the `partner_write_date` is formatted. It changed the separator from `T` to ` `, which was wrong and leads to failed XSD validation. opw-3944774 Forward-Port-Of: odoo/enterprise#64330
Employees should not be able to delete leaves in the future when there's a payslip generated and paid for that period. Task-3776411 Forward-Port-Of: odoo/enterprise#64279 Forward-Port-Of: odoo/enterprise#64231
Original PR description
Employees should not be able to delete leaves in the future when there's a payslip generated and paid for that period. Task-3776411 Forward-Port-Of: odoo/enterprise#64279 Forward-Port-Of: odoo/enterprise#64231
This commit adds the new rule for the AHL computation where a deduction is applied as 15 percent of the AHL amount capped at 9ksh. Note the l10n_ke_employees_salary_ahl_amount is the same except the sequence its just reordered task-3911725 Forward-Port-Of: odoo/enterprise#62886
Original PR description
This commit adds the new rule for the AHL computation where a deduction is applied as 15 percent of the AHL amount capped at 9ksh. Note the l10n_ke_employees_salary_ahl_amount is the same except the sequence its just reordered task-3911725 Forward-Port-Of: odoo/enterprise#62886
## Issue: When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary configurator does not appear. ## Steps To Reproduce: - on the runbot change the company to "my Belgian company". - In Laurie Poiret's employee profile, on the "personal information" tab, change the value for children to 2 and set 1 as disabled. - Go to Laurie Poiret's contract (stat button) and generate
Original PR description
## Issue: When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary…
## Issue: When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary configurator does not appear. ## Steps To Reproduce: - on the runbot change the company to "my Belgian company". - In Laurie Poiret's employee profile, on the "personal information" tab, change the value for children to 2 and set 1 as disabled. - Go to Laurie Poiret's contract (stat button) and generate an offer. - From the offer, navigate to the salary configurator. - In the salary configurator, proceed until you reach the family status section. - Notice that the "Disabled children" Toggle does not appear unless you change the value of the children input. ## Solution: - The `onchangeChildren` method is being invoked in the `start` method without an `event` argument (`event` is `undefined`). This results in `event.currentTarget` being `undefined`, causing the `childCount` variable to be `NaN` and `disabledChildrenNumber` to get disabled at the end of the method. - to fix the problem, we added a check for `event` argument in the event handler, if it is not present, we fallback to getting the children input value using JQuery and it solves the issue. **opw-3925640** Forward-Port-Of: odoo/enterprise#64347 Forward-Port-Of: odoo/enterprise#63535
Problem --------- Currently, if an email containing a lot of images and documents reaches the mail alias, one invoice will be created for each attachment (image, PDF, XML, etc.) in the mail. This can pollute databases as, nowadays, many emails possess rogue images with link to Facebook, Twitter, branding, etc. Objective --------- Do not create an attachment for images in the mails from a mail alias. Solution --------- Filter out the binary file data that have not been yet extracted;
Original PR description
Problem --------- Currently, if an email containing a lot of images and documents reaches the mail alias, one invoice will be created for each attachment (image, PDF, XML, etc.) in the mail. This can pollute databases as, nowadays, many emails possess rogue images with link to Facebook, Twitter, branding, etc. Objective --------- Do not create an attachment for images in the mails from a mail alias. Solution --------- Filter out the binary file data that have not been yet extracted; this ensures that only rogue images are filtered out. The other file types will create new invoices like before. opr-168305 task-3973973 Forward-Port-Of: odoo/enterprise#63997
When call activity gets deleted or added, the related component has to be re-rendered so that most uptodate information is shown, otherwise this might lead to crash if those activities are accessed. To mitigate the issue, component re-rendering is invoked when call activity gets added or removed from the queue. The activity removal happens when `delete_call_activity` function is invoked directly, which crafts domain, to search the activies that are outdated. Steps to reproduce: - on
Original PR description
When call activity gets deleted or added, the related component has to be re-rendered so that most uptodate information is shown, otherwise this might lead to crash if those activities are accessed. To mitigate the issue, component re-rendering is invoked when call activity gets added or removed from the queue. The activity removal happens when `delete_call_activity` function is invoked directly, which crafts domain, to search the activies that are outdated. Steps to reproduce: - on crm lead schedule call activity and make sure that activity is old - book activity and save it - add it to Call Queue - remove it from Call Queue - try to access it/click on it Forward-Port-Of: odoo/enterprise#64403 Forward-Port-Of: odoo/enterprise#64325
The chilean law requires the date to be on top of the receipt. This is now the case. Community PR: odoo/odoo#168270 Forward-Port-Of: odoo/enterprise#64222 Forward-Port-Of: odoo/enterprise#63966
Original PR description
The chilean law requires the date to be on top of the receipt. This is now the case. Community PR: odoo/odoo#168270 Forward-Port-Of: odoo/enterprise#64222 Forward-Port-Of: odoo/enterprise#63966
**Before this PR:** When you have a `Create ticket` step in your ChatBot script steps, but you don't have an `Email` step prior to that. Then it will break the flow of ChatBot, as an email is required to create a helpdesk ticket. **After this PR:** It will raise a `ValidationError` if it fails to validate the steps while configuring the chatbot script steps. **task**-[3547675](https://www.odoo.com/web#id=3547675&menu_id=6478&cids=2&action=4043&model=project.task&view_type=form) For
Original PR description
**Before this PR:** When you have a `Create ticket` step in your ChatBot script steps, but you don't have an `Email` step prior to that. Then it will break the flow of ChatBot, as an email is required to create a helpdesk ticket. **After this PR:** It will raise a `ValidationError` if it fails to validate the steps while configuring the chatbot script steps. **task**-[3547675](https://www.odoo.com/web#id=3547675&menu_id=6478&cids=2&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64440 Forward-Port-Of: odoo/enterprise#56802
Anyone that has access to the partner form can currently unset the 281.50 tag on any partner, later causing accounting errors. This commit forbids unsetting this tag by users who do not have 'Bookkeeper' (or 'Accountant', implied from 'Bookkeeper') access group. task-3955109 Forward-Port-Of: odoo/enterprise#63784
Original PR description
Anyone that has access to the partner form can currently unset the 281.50 tag on any partner, later causing accounting errors. This commit forbids unsetting this tag by users who do not have 'Bookkeeper' (or 'Accountant', implied from 'Bookkeeper') access group. task-3955109 Forward-Port-Of: odoo/enterprise#63784
15 changes
New functionality added to Odoo
A new feature has been added to display check numbers in the Bank Reconciliation widget when check printing is enabled in Accounting settings. This makes it easier for accounting teams to verify and reconcile bank transactions by showing the check number alongside payment information, improving the efficiency of the bank reconciliation process.
Original PR description
[ADD] account_accountant_check_printing: Add check number to bank rec desired behavior: If Checks are activated in the Accounting settings, add a new column in the Bank Reconciliation widget for payment_id.check_number, in optional=hide Reason: the Check Number is a very useful information to display in the Bank Reconciliation. solution: create new module dependent on accounting and account_check_printing modules and add the desired column and method there. Task-3869134
Resolved issues and error corrections
A bug in the Sendcloud delivery module was causing error messages to fail when validating shipments. The issue has been fixed by correcting the error message formatting, and the messages have been improved to be clearer and more helpful to users.
Original PR description
Prior to this commit, validating a picking that triggers this error message would raise a "TypeError: not enough arguments for format string" because the extra '()' caused all three %s to be considered as one argument. After this commit, everything works as expected. Additionally, I have reformulated the error messages to be clearer and better structured. OPW-3945812
This fix prevents employee costs from being recalculated and overwritten when viewing work order details or cost reports. Previously, accessing cost information would update the stored employee cost with current rates, causing historical cost data to be lost and inaccurate cost analysis reports. Now employee costs are properly locked in when work orders are completed.
Original PR description
Currently, the `employee_cost` of a `mrp.workcenter.productivity` is recomputed each time we try to access its `total_cost`. This means that if you change the cost of the employee related to it some time after a MO was completed, if you end up accessing the `total_cost` field (like by opening the Overview), it will overwrite the previous `employee_cost`, and will alter the Cost Analysis report as well. Forward-Port-Of: odoo/enterprise#64090 Forward-Port-Of: odoo/enterprise#45609
This fix resolves an issue where Mexican invoices (CFDI) were failing validation with a "date and time out of range" error when signed between 11 PM and 1 AM in certain timezones. The problem occurred because the system was comparing invoice dates using the user's timezone instead of the partner's timezone. This update ensures invoices are validated correctly regardless of when they're signed or what timezone the user is in.
Original PR description
In UTC+1 timezone (i.e. Runbot) try to validate an invoice between 23:00 and 1:00 Validation will fail with error 'Fecha y hora fuera de rango'. This occurs because after fc49984 we compare invoice date with fields.Date.context_today(self) which uses the user timezone, while we need to use the partner timezone. Fix also the current timezone test when run on runbot before 4am. opw-3920259
This update fixes a problem where automated tests for invoice extraction were failing unpredictably when run around midnight. The fix ensures test dates are consistent and stable, making the testing process more reliable and preventing similar issues in future updates.
Original PR description
The test `test_action_reload_ai_data` added by commit f85e392 introduced a new undeterministic failure when the test is run at around midnight. This is the exact same issue that occurred in another of these tests and that was fixed by commit a4fbd4c. This commit solves the problem in a more generic way, by freezing the date so that the `create_date` and the default `invoice_date_due` always match. It should prevent the issue from re-appearing in future new tests. Forward-Port-Of: odoo/enterprise#64361 Forward-Port-Of: odoo/enterprise#64130
Portal users were seeing the 'Planned Date' field displayed twice when viewing tasks with date ranges. This fix removes the duplicate field from the Field Service module, allowing the parent Project module to handle the display. This provides a cleaner, less confusing experience for portal users viewing their assigned tasks.
Original PR description
Problem: When a portal user views a Task they are connected to, if `planned_date_begin` is set (using a date range on the Task rather that just `date_deadline`), 'Planned Date' will appear twice on Portal View. Purpose: We already have 'Planned Date'/'Deadline' shown with `project_enterprise.portal_my_task`, and this edited view comes from `industry_fsm`, which depends on `project_enterprise` anyways. Removing from `industry_fsm` lets the parent module take care of these fields. Steps to Reproduce: 1. Create a SO with Service Product that creates Project/Task, assign portal user as Customer 2. Share Read-only with Portal user from Project 3. On Task, set Deadline start and end. 4. Login as portal User, navigate Projects -> SO -> Task 5. See duplicated 'Planned Date' line opw-3978845
The order status page was not displaying translations correctly because the system wasn't aware that this page needed translation support. This fix ensures that customers see the order status page in their preferred language instead of the default language.
Original PR description
Problem --- On the order status page, the terms translations are ignored. This happens because it is a 'website=True' routed page, and modules which create website pages with translations need to let the http routing know about them by overloading `_get_translations_modules_name` Note: the page will typically be translated into the browser's preferred language and not the odoo user's. opw-3949394
Fixed an issue where timesheet overtime tests would fail if the HR Contract module wasn't installed. The fix allows tests to run independently by marking test employees as freelancers, eliminating the need for contract data to determine overtime status. This improves system flexibility and test reliability.
Original PR description
Before this commit, the test fails when `hr_contract` module is not installed because the test tries to create a contract for an employee. This commit makes sure the test works without `hr_contract` by saying the employee is a freelancer to avoid using contract to get his working schedule to know if he did an overtime or not in Timesheets app. X-original-commit: 1e58628c63c4951dfb66ec1aa3a7eeae0a7b78d4
This fix resolves two issues preventing users from generating Dutch XAF financial reports. The system was incorrectly blocking all countries when validation files were missing or not properly recognized. Users will now be able to generate these reports without encountering false country restriction errors.
Original PR description
This PR fixes two issues that are closely related, so I'm handling them in the same PR. ### Skip forbidden country check if no XSD present In https://github.com/odoo/odoo/pull/115720 downloading of…
This PR fixes two issues that are closely related, so I'm handling them in the same PR. ### Skip forbidden country check if no XSD present In https://github.com/odoo/odoo/pull/115720 downloading of XSD's for validation was made optional and related checks were skipped if the relevant XSD was not present. That's currently not done when generating a XAF report in the Dutch localization. The XSD contains the list of valid countries allowed in the report. If there is no XSD, no country is allowed. This can result in the user being presented with an error that partners in the Netherlands are not allowed. This fix skips the country check if the XSD is not present. The downside of that is not having this validation by default, since the XSD is not downloaded by default. An alternative would be to hardcode the list. opw-3957513 ### Missing prefix when checking for XSD When generating a XAF report, allowed country codes for partners are loaded from an XSD. By default this XSD is not present. If it's manually downloaded through the settings, it still didn't work because the name of the attachment searched for does not include the module prefix while the name of the downloaded attachment does. This fix includes the prefix in the search. opw-3957513 Forward-Port-Of: odoo/enterprise#64348
This update fixes a critical issue where IoT device communication errors on Windows systems were not being properly caught and reported to users. The system now wraps all device driver calls with error protection to detect, log, and display error messages clearly, ensuring consistent behavior across Windows and other operating systems.
Original PR description
On Windows OS if a ctypes method causes a segmentation fault, it leads to an OSError instead of a crash like it does on a raspberry pi. Related Python ctypes documentation link: https://docs.python.org/3/library/ctypes.html#calling-functions  This PR wraps every ctypes C/C++ method call with a try/except OSError to properly detect, log and display an error message to the user. task-3950652 Forward-Port-Of: odoo/enterprise#64124
A recent change incorrectly modified how dates are formatted in Dutch tax reports (XAF files), causing validation failures. This fix restores the correct date format to ensure tax reports can be properly submitted and validated by authorities.
Original PR description
This [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a) introduced a change in the way the `partner_write_date` is formatted. It changed the separator from `T` to ` `, which was wrong and leads to failed XSD validation. opw-3944774 Forward-Port-Of: odoo/enterprise#64330
This fix resolves an issue where tax information was incomplete when using the payment reconciliation feature in Accounting. When users reconciled invoices with a tax amount, the tax line was created but the base line's tax field remained empty, causing inconsistencies in tax reports. This update ensures tax data is properly populated across all related lines.
Original PR description
Open Accounting Dashboard On "Customer Invoices" card, hit 3 dots> Payment Matching Select any invoice, hit reconcile button, fill Account and Tax Click 'Reconcile & Open' Open the created write off entry Issue: Tax line has been created but the base line tax field is empty. This will create an inconsistency in tax reports opw-3893394 Forward-Port-Of: odoo/enterprise#62631
This fix resolves a crash that occurred when performing cash in/out operations in the Point of Sale system for Chilean companies. The error happened because the system was trying to access company information that wasn't available during these cash operations. Users can now complete cash in/out transactions without encountering errors.
Original PR description
A traceback occurs when this specific call to `getReceiptHeaderData` is made without order. ``` Error: TypeError: Cannot read properties of undefined (reading 'l10n_cl_sii_regional_office') ``` To reproduce the error: - With a CL company setup - Open POS session - Click Cash In/Out - Select an amount - Confirm Ticket [link](https://www.odoo.com/web#model=project.task&id=3917776) opw-3917776
This fix resolves an error that occurred when uploading XML files to generate invoices in the Mexican EDI module. The system was attempting to access tax group information that didn't exist, causing the invoice generation to fail. The fix adds a safety check to handle cases where tax group data is missing, allowing invoices to be created successfully even when certain tax configurations have been removed.
Original PR description
Currently, an error occurs when uploading an XML file to generate an invoice. Step to produce: - Install the 'l10n_mx_edi' module. - Go to Accounting / Configuration / Accounting / Taxes, And delete…
Currently, an error occurs when uploading an XML file to generate an invoice. Step to produce: - Install the 'l10n_mx_edi' module. - Go to Accounting / Configuration / Accounting / Taxes, And delete all 'Exento' taxes. - Go to Accounting / Configuration / Accounting / Tax Groups, And delete all 'Exento' Tax Group. - Navigate to Accounting / Customers / Invoices, And upload an XML file to generate an invoice, - Ensure that the XML file contains the "TipoFactor" with a value of "Exento". (use this XML file [1]). AttributeError: 'NoneType' object has no attribute 'id' An error occurs when attempting to generate an invoice by uploading an XML file because system tries to retrieve an ID from the external_id of a tax group at [2] which is not available. link [1]: https://github.com/odoo/enterprise/blob/1e3dfa7c6a57c251d77801c316818b5a9fae6cc5/l10n_mx_edi/tests/test_files/test_bill_import_extento.xml#L1 link [2]: https://github.com/odoo/enterprise/blob/1e3dfa7c6a57c251d77801c316818b5a9fae6cc5/l10n_mx_edi/models/account_move.py#L2381 To resolve the issue, Add a condition to ensure that an external_id of a tax group is available. sentry-5312222893 Forward-Port-Of: odoo/enterprise#62257
This fix resolves a critical error that prevented Odoo from starting when using maintenance features together with manufacturing and repair modules. A required field was missing from the maintenance view configuration, causing the system to fail during initialization. The fix adds the missing field reference so the system can start without errors.
Original PR description
**`recurring_maintenance` is not present in view** Impacted versions: - 17.0 Steps to reproduce: 1. create a module which depends on "hr_maintenance", "repair" and "mrp" modules. 2. Initialize the database. Current behavior: Following error is thrown: `Field 'recurring_maintenance' used in modifier 'invisible' (maintenance_for == 'equipment' or not recurring_maintenance or not block_workcenter) must be present in view but is missing.` Expected behavior: Being able to start Odoo without error.