Daily updates from Odoo
Navigate
Branch
Tuesday, October 22, 2024
98 changes
33 changes
Resolved issues and error corrections
Users with Survey and Recruitment access could be led to completed recruitment survey answers that were not visible from the Survey app. This fix removes misleading Survey app links and sharing actions for non-standard survey types so users are guided away from paths where answers cannot be accessed.
Original PR description
Issue ----- An user with Survey and Recruitment rights is not able to see completed answers for recruitment type surveys. Steps ----- [hr_recruitment_survey] 1. With admin, create a "Recruitment"…
Issue ----- An user with Survey and Recruitment rights is not able to see completed answers for recruitment type surveys. Steps ----- [hr_recruitment_survey] 1. With admin, create a "Recruitment" type survey, answer it once. 2. Go to Surveys > Click on "1 Completed" > No answers visible. Go to Recruitment > Interviews > Click on "1 Completed" > No answers visible either. Cause ----- Commit 027a2a66d63225abbfaef425448188007f573ac5 overhauled rights management for surveys and the apps depending on Survey. The view showing the answers to a survey restricts the survey types: https://github.com/odoo/odoo/blob/027a2a66d63225abbfaef425448188007f573ac5/addons/survey/views/survey_user_views.xml#L171 A user with Recruitment rights will therefore not see the answers to a Recruitment survey. Change ----- As a security rule exists to not allow Survey users to access Recruitment survey answers: https://github.com/odoo/odoo/blob/027a2a66d63225abbfaef425448188007f573ac5/addons/survey/security/survey_security.xml#L104 We don't restrict the view to make other survey types work. opw-4089308
Miscellaneous changes
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#157362
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#157362
## Description Following cef5ae8a80988c4e0529c1770b1c1e573490f6e7, the default `batch_size` for generating the mails was changed from `500`->`50`. But one instance seems to have been missed, during the generation of mails in the wizard, which is used by the mass-mailing cron. To address this, we are just changing `self.batch_size` in the wizard from `500`->`50` (the variable may have been overridden in custom code, so we keep the static variable) Backport of ac51f29f91e34cf4794164658a8c27d8
Original PR description
## Description Following cef5ae8a80988c4e0529c1770b1c1e573490f6e7, the default `batch_size` for generating the mails was changed from `500`->`50`. But one instance seems to have been missed, during the generation of mails in the wizard, which is used by the mass-mailing cron. To address this, we are just changing `self.batch_size` in the wizard from `500`->`50` (the variable may have been overridden in custom code, so we keep the static variable) Backport of ac51f29f91e34cf4794164658a8c27d8b7759230 ## Reference opw-4142511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180830
… is not set" This reverts commit fd1da69f8331dbc55be2d164fad381fca1622a67. The l10n_it_document_type belongs to `l10n_it_edi_ndd` module. This module exists to add this stored field that was missing. When the error that this commit tried to fix happens, which is due to the fact that the compute doesn't find a correct matching document, we don't want to block the flow. The user can still set a document type himself through Odoo (if he has the aforementioned module installed) or direct
Original PR description
… is not set" This reverts commit fd1da69f8331dbc55be2d164fad381fca1622a67. The l10n_it_document_type belongs to `l10n_it_edi_ndd` module. This module exists to add this stored field that was missing. When the error that this commit tried to fix happens, which is due to the fact that the compute doesn't find a correct matching document, we don't want to block the flow. The user can still set a document type himself through Odoo (if he has the aforementioned module installed) or directly in the XML. Forward-Port-Of: odoo/odoo#184481
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to Invoicing > Configuration > Settings > Taxes > EU Intra-community Distance Selling > Click on Refresh tax mapping Traceback: ``` ValueError: Expected singleton: res.company(1, 2) File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py",
Original PR description
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to…
When the user selects multiple companies and clicks on Refresh tax mapping,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_eu_oss`` module
- Select multiple companies
- Go to Invoicing > Configuration > Settings > Taxes >
EU Intra-community Distance Selling > Click on Refresh tax mapping
Traceback:
```
ValueError: Expected singleton: res.company(1, 2)
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/l10n_eu_oss/models/res_config_settings.py", line 13, in refresh_eu_tax_mapping
self.env.companies._map_eu_taxes()
File "addons/l10n_eu_oss/models/res_company.py", line 34, in _map_eu_taxes
invoice_repartition_lines, refund_repartition_lines = company._get_repartition_lines_oss()
File "addons/l10n_eu_oss/models/res_company.py", line 105, in _get_repartition_lines_oss
self.ensure_one()
File "odoo/models.py", line 6213, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/bbcef64e3296efa2b985e8d08dfe0573dc62dbb4/addons/l10n_eu_oss/models/res_company.py#L32
Here, ``self`` is used instead of ``company``, When self has multiple companies,
It will lead to the above traceback.
sentry-6002997139
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#184491Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatti
Original PR description
Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatting is applied, but the `.o_default_snippet_text` class remains on the element. 5. Save and re-edit 6. Click on the title -> The text is entirely selected because it's still treated as a default text. This commit ensures the correct behaviour of this feature. task-4147162 Forward-Port-Of: odoo/odoo#183179
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
Original PR description
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
Original PR description
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
With this commit, the tour test_01_ui is fixed for differents tests triggers: community version and no demo data. 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#183578 Forward-Port-Of: odoo/odoo#183503
Original PR description
With this commit, the tour test_01_ui is fixed for differents tests triggers: community version and no demo data. 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#183578 Forward-Port-Of: odoo/odoo#183503
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
Original PR description
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-
Original PR description
As the portal user, change your profile picture to a svg image, then show it via the normal /web/image URL. The downloaded picture lacks a valid content-type header. Related stored attachment fields were served via the method `Stream.from_binary_field` instead of `Stream.from_attachment`, only the latter is capable of copying the attachment mimetype on the stream. --- Also gave a shot at making the `odoo-bin --test-tags webserver:TestHttpStaticWebServer` test green again. Forward-Port-Of: odoo/odoo#183596 Forward-Port-Of: odoo/odoo#177105
Steps to reproduce the issue: - In website edit mode. - Inspect the HTML code of the "Video" snippet in the snippet menu. - The YouTube iframe is loaded even though the "Video" snippet has not been dropped into the page. We need to fix this in stable because a recent update of Chrome [1] is now triggering an error during several tests in edit mode on runbot. This error is due to the fact that we are contacting the YouTube API during the tests, which cannot be done when a test is bein
Original PR description
Steps to reproduce the issue: - In website edit mode. - Inspect the HTML code of the "Video" snippet in the snippet menu. - The YouTube iframe is loaded even though the "Video" snippet has not been dropped into the page. We need to fix this in stable because a recent update of Chrome [1] is now triggering an error during several tests in edit mode on runbot. This error is due to the fact that we are contacting the YouTube API during the tests, which cannot be done when a test is being executed on runbot. Note that this fix is no longer necessary starting from version saas-17.4 because, from this version, the HTML code of the snippets are no longer in the snippet menu. After this commit, snippets containing an iframe will have their iframe loaded only when the drag-and-drop starts. [1]: https://developer.chrome.com/release-notes/125#the_compute_pressure_api runbot-102187 Forward-Port-Of: odoo/odoo#184443
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Se
Original PR description
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Select a company other than the default one. - Create a quotation. - In the description, add an image and save. - Try to crop the image and save again. The operation fails due to the company context issue. opw-4173391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183112
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra`
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra` attributes when displaying the not available message. Solution -------- Add a `t-elif` element to the template, checking if the product has any non-zero price-extra attribute values, if so, don't display the not available message, but also don't display the zero price. opw-4225183 Forward-Port-Of: odoo/odoo#184052
Description of the issue/feature this PR addresses: It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Current behavior before PR: User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Desired behavior after PR is merged: User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Task Adhoc side: 40557 Tas
Original PR description
Description of the issue/feature this PR addresses:
It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Current behavior before PR:
User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Desired behavior after PR is merged:
User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Task Adhoc side: 40557
Task latam: 1254
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176858When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
Original PR description
When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , java
Original PR description
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed…
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , javascript will create it at time 00:00 in the UTC timezone, so for users with negative timezone offset (GMT-x), `formatDate` will print the the date as one day behind. It’s the case for American users for instance. Now, we create the date using `DateTime.fromISO(yyyy-mm-dd)`, it will be created at 00:00 in the local time zone (not the UTC timezone anymore), and printing it with `formatDate` will therefore yield the correct value expected by the user. opw-4116982 Forward-Port-Of: odoo/odoo#182933
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as i
Original PR description
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391).…
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as it appeared in the production environment. To address this issue, I have added the XML ID of the tax to map the old tax. opw-[4091389](https://www.odoo.com/odoo/project/70/tasks/4091389) upg-[1874716](https://upgrade.odoo.com/web#id=1874716&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) 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#182937
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e5
Original PR description
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e50d9381e1826cd/addons/account/models/account_journal.py#L801 To resolve this issue, Use an ```ids``` instead of an ```id``` to get a multiple records. Sentry-5917175119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182664 Forward-Port-Of: odoo/odoo#182043
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#183993
Original PR description
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#183993
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Original PR description
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
Original PR description
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058
Original PR description
**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058770 Forward-Port-Of: odoo/odoo#179639
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#183971 Forward-Port-Of: odoo/odoo#183268
Original PR description
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#183971 Forward-Port-Of: odoo/odoo#183268
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184584
Original PR description
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184584
Steps --- * install `mrp`, `purchase` * create the following products: * P, storable, route = manucfature, bom: * C storable (qty = 1) * K storable, (qty = 1) kit bom: * C (qty = 1) * set the quantiy on hand for C to 1 * create a purchase order for 20 C * create an MO for 5 P > *Confirm* * in the overview we have 2 component line (each for C), but the 2nd line's status is *To Order* even though we already have a PO. if we look at the d
Original PR description
Steps
---
* install `mrp`, `purchase`
* create the following products:
* P, storable, route = manucfature, bom:
* C storable (qty = 1)
* K storable, (qty = 1) kit bom:
* C (qty = 1)
* set the quantiy on hand for C to 1
* create a purchase order for 20 C
* create an MO for 5 P > *Confirm*
* in the overview we have 2 component line (each for C), but the 2nd
line's status is *To Order* even though we already have a PO.
if we look at the details of the first line, we can see the replenishment
for the second line was wrongly assigned to the first.
Cause
---
When matching replenishments to bom line moves, we check if quantity
from the replenishments is enough for the move, if so we go on to the
next move. But when we do this we do not account for pre-reserved
quantity of partially available moves.
opw-4128775
Forward-Port-Of: odoo/odoo#178261Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. St
Original PR description
Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. Steps to reproduce: - Open any page with the web editor. - Add text with part of it formatted as a link. - Try toggling any style (e.g., bold, italic). - The style is applied but cannot be reverted, and the button state remains off. opw-4213717 Forward-Port-Of: odoo/odoo#181793
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184152
Original PR description
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184152
nodeValue on `input` always return null. To get the previous value of the input cell, the query should be `matrixInput.attributes.value.nodeValue`. That way unchanged cell won't be send to the list of data to be updated. opw: 3987284 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#184294
Original PR description
nodeValue on `input` always return null. To get the previous value of the input cell, the query should be `matrixInput.attributes.value.nodeValue`. That way unchanged cell won't be send to the list of data to be updated. opw: 3987284 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#184294
Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
Original PR description
Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtua
Original PR description
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtual moves with values and mark them as modified. This causes them to eventually get invalidated and they aren't saved once the update (overwrite) resolves. **Fix:** Don't update virtual moves (records without an _origin). opw-4120108 Forward-Port-Of: odoo/odoo#182606
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug onl
Original PR description
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event…
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug only occurred when the Event Registration product price was set to a value different from the price defined in the Event record. While this bug is present in 16.0 onwards, the logic causing the issue has been refactored and will require a separate fix. Steps to reproduce the issue: 1. Create Pricelists for additional currencies (CAD, JPY) with empty rules and enable the “Selectable” checkbox for Ecommerce. 2. Set currency rates to 133.6200 for JPY and 1.338800 for CAD to replicate the conditions when the bug was found. 3. Create an Event. 4. Create an Event Registration Ticket, ensuring the linked Event Registration product price is $1.00 and the price in the event view is set to $30.00. 5. Visit the Event page on the website and attempt to purchase a ticket. Switch between currencies (JPY, CAD) to observe the issue. 6. Using JPY at the conversion rate of 133.6200, the expected converted price for a $30.00 ticket should be ¥4009, but Odoo calculates the price as discounted to ¥3997. 7. With CAD at 1.338800, the correct converted price should be $40.16 CAD, but the price is instead calculated as $40.12 CAD. 8. On 17.4+, the original and correct prices will display as a strikethrough discount. Cause of the issue: The method _get_contextual_discount in product_product.py was comparing a rounded lst_price to an unrounded contextual price, leading to a tiny discrepancy being mistaken as a discount. The bug occurred because the rounding of the lst_price did not match the rounding of the contextual price. While this method is defined in the product module, it only is used by the event_booth and event_booth_sale modules. Solution: The fix ensures that both operands are not rounded before comparison. Now, the _get_contextual_discount method does not round both the lst_price and the contextual price, preventing the calculation of an erroneous discount. opw-4213704 Forward-Port-Of: odoo/odoo#182695
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interac
Original PR description
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 ->…
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interaction will fail which includes: - some payment method callback (Adyen, Vivawallet) - IoT printing requests - chatter messages ... Reasons of the issue: The issue happen as the websocket use a shared workers and certain operation (like here opening self-order), will interupt the current websocket to open a new one on which previously subscribed channel will be missing (explaining why the PoS session won't sync orders). The shared worker decided to interupt the previous websocket and create a new one as the "db" information was missing from the `session_info`, see: https://github.com/odoo/odoo/blob/dfdea9704a13c259cc1d49d6bd3a3fa4d93307b6/addons/bus/static/src/workers/websocket_worker.js#L257 After this commit: PoS orders continue to sync even if the kiosk view is opened on the same browser session opw-4233060 Forward-Port-Of: odoo/odoo#183527
32 changes
Enhancements to existing features
Product pages now skip rental date checks for items that are not rentals, reducing unnecessary validation for shoppers. The update also aligns rental and subscription product page pricing behavior with recent platform changes, helping keep displayed prices consistent.
Original PR description
Variant Mixin logic is only used on ecommerce since the drop of the old product configurator (optional products modal) replaced by the backend one, thus `isWebsite` is always truthy and useless to check Avoid verification of rental dates when the product is not a rental product. Also adapt to community changes with the removal of `price_extra` key from combination info. See also: odoo/odoo#180774
Field service and project task lists in the map side panel can now be reordered when they use a sequence-based order with dates. This helps teams adjust visit routes more easily and improve itinerary planning directly from the map view.
Original PR description
The JS framework introduced the option to reorder records from the map view side panel. This is particularly useful to optimize the itinerary. However, this feature is only available when records are ordered by an integer field, which isn't the case at the moment in project/fsm. As a consequence, we need to order tasks by 'sequence > start date' in the map view of project/fsm. task-4245177
Email templates across several business apps now use smarter default recipient selection, reducing the need for manual setup and lowering the risk of messages going to missing or incorrectly formatted contacts. The update also improves email matching and validation in related flows, making customer and attendee communications more reliable.
Original PR description
Improve default behavior of mail.templates * move to 'use_default_to' being the default value for templates. This means no configuration for 'email_to' / 'partner_to' is necessary as it is going to…
Improve default behavior of mail.templates
* move to 'use_default_to' being the default value for templates. This means
no configuration for 'email_to' / 'partner_to' is necessary as it is
going to use results of '_message_get_default_recipients' which should
find default contact in most cases;
* go through existing templates, and set 'use_default_to' flag explicitly
to True (if functional model and flow targeting customers) or False
(if technical model or flows linked to custom mailing where recipients
are specific to the template);
* improve '_message_get_default_recipients' in order to
* better find linked partner (using '_mail_get_partners');
* better compute default recipients, notably filter out partners without
email;
* allow to prioritize email on partners (e.g. models where email can be
different from linked partner like registrations);
* better check email validity using normalize;
* allow to have default creation values for template based on model, currently
done for calendar attendee and event attendee models. This can be extended
by overriding '_mail_template_default_values';
* provide various fixes in email flows when spotted (e.g. using normalized
emails for comparison and searches, remove outdated code, ...);
See sub commits for more details.
Follows preliminary merge odoo/odoo#184581 and odoo/enterprise#72420
Task-2667099: [mail] Improve default template values
Task-3955092: [event] Improve creating registration templates
Task-4264367: [mass_mailing] Store/Compare normalized emails on traces
Task-4269238: [pos] Cleanup 'marketing' improvements
Prepares Task-4224145: [marketing_automation] Improve test coverage
Prepares Task-4241059: [event] Negative before/after event schedulersThe Indian GSTR reporting spreadsheet functionality is now included directly in the main GSTR reports module. This simplifies deployment and maintenance while keeping the reporting workflow available in one place for users.
Original PR description
In this commit: merging `l10n_in_reports_gstr_spreadsheet` into `l10n_in_reports_gstr` Related - https://github.com/odoo/upgrade/pull/6630 task-4266231
The referral app’s sample reward data and images have been refreshed to reference Odoo instead of external companies. This keeps demonstration content aligned with Odoo branding and avoids showing third-party brand references in demo environments.
Original PR description
The demo data are updated to make reference to odoo and remove external reference to other companies. task-4071950
The Amazon sales integration is easier to set up and manage. Account names are filled in automatically, users can pause or resume account connections, and the setup screens now guide users more clearly when no account exists.
Original PR description
This commit improve UX and usability of Amazon marketplace. - Compute name of account from marketplace so user don't explicitly need to type account name to create an account. - Add Pause and Resume action and button to connect and disconnect account. - Remove Marketplace and Products button from setting and display `Link my Account` when user don't any already existing account. - Improve account form view. - Add custom `New` button in list view instead main one to open quick create dialog instead form view. task-3627857
This update switches many Odoo Enterprise apps to the newer translation system and marks the older approach as deprecated. It helps keep the platform easier to maintain and prepares for future simplification, with little expected day-to-day impact for users.
Original PR description
This commit replaces the use of `core.{_t,_lt}` with its equivalent from `@web/core/l10n/translation`. Calling these functions will now result in a warning.
This paves the way for the unification of `_t` and `_lt` into a single function, and the removal of the legacy `web.translation`.
Community: https://github.com/odoo/odoo/pull/124285The appointment module no longer applies a date-only display option to fields that store both date and time. This prepares the system for stricter checks on unsupported field settings and helps reduce hidden configuration issues.
Original PR description
This commit removes the date widget on datetime fields. The widget is ignored if used on a datetime fields, see the tests : `DatetimeField with date/datetime widget (with day change) does not care about widget` and `DatetimeField with date/datetime widget (without day change) does not care about widget.` This commit is part of a bigger task, that aim to raise an error if a widget is used in an unsupported field type, in this case the widget date, will only support the date type fields. task-id: 4224192
Resolved issues and error corrections
This update corrects several small code issues identified by automated quality checks across accounting, delivery, documents, stock barcode, and data cleaning areas. The changes reduce the risk of hidden bugs and improve maintainability without introducing expected functional changes for users.
The EasyPost delivery setup now shows the correct carrier type options in the selection widget. This helps users configure shipping carriers more reliably and avoids incorrect or missing choices during setup.
Original PR description
This commit fix the supportedTypes of widget `carrier_type_selection`. task-id: 4224192
Features or functions removed from Odoo
The reporting options that automatically added totals below sections have been removed to simplify report behavior. Reports that still need these total lines will now handle them directly, reducing shared complexity and making each report's layout more explicit.
Original PR description
This commit will remove the total below section setting and ignore_totals_below_section options. This change is done because, it brings useless complexity to reports. If the totals line are needed, the specific report will have to add the lines by itself task: 4182639
Miscellaneous changes
Steps to reproduce: - have two companies with different main currencies - have currency rates != 1 for the selected main company - open the trial balance with both companies selected => The amounts displayed in Debit and Credit column from the first company are not converted to the main company currency. Reason of the issue: The general ledger custom code rewrite the options 'date_from' to the fiscal year date from, which results in a Null join with the account_currency_tab
Original PR description
Steps to reproduce: - have two companies with different main currencies - have currency rates != 1 for the selected main company - open the trial balance with both companies selected => The amounts displayed in Debit and Credit column from the first company are not converted to the main company currency. Reason of the issue: The general ledger custom code rewrite the options 'date_from' to the fiscal year date from, which results in a Null join with the account_currency_table Forward-Port-Of: odoo/enterprise#72006
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
Original PR description
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be conside
Original PR description
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be considered by that line of the BS. Only affectation must also be considered from within the current fiscal year. Forward-Port-Of: odoo/enterprise#72337 Forward-Port-Of: odoo/enterprise#72021
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644 Forward-Port-Of: odoo/enterprise#72054
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Original PR description
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72362 Forward-Port-Of: odoo/enterprise#71459
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72362 Forward-Port-Of: odoo/enterprise#71459
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72278 Forward-Port-Of: odoo/enterprise#72199
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72278 Forward-Port-Of: odoo/enterprise#72199
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amount
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#72430 Forward-Port-Of: odoo/enterprise#65074
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` wh
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393 Forward-Port-Of: odoo/enterprise#72425 Forward-Port-Of: odoo/enterprise#70800
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#71811 Forward-Port-Of: odoo/enterprise#70369
Original PR description
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#71811 Forward-Port-Of: odoo/enterprise#70369
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Original PR description
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Steps to reproduce the bug: - Create two Storable product: - “P1” -> product category A - “P2” -> product category B - Create a quality point: - picking type: receipt - product category: Cat A & Cat B - Measure: by quantity - Create a second quality point: - picking type: receipt - product category: Cat A - Measure: by quantity - Create a receipt of one unit of P1 and P2 - Confirm Problem: Four quality checks are created instead of three bec
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859
Forward-Port-Of: odoo/enterprise#71709
Forward-Port-Of: odoo/enterprise#71453If a language is set on the customer when doing the followup, the attached Partner Ledger was always generated in the language of the active user. Instead, if a language is set on the customer, we want to use it. Forward-Port-Of: odoo/enterprise#71529
Original PR description
If a language is set on the customer when doing the followup, the attached Partner Ledger was always generated in the language of the active user. Instead, if a language is set on the customer, we want to use it. Forward-Port-Of: odoo/enterprise#71529
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time wit
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#72224 Forward-Port-Of: odoo/enterprise#63002
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72429 Forward-Port-Of: odoo/enterprise#72343
Original PR description
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72429 Forward-Port-Of: odoo/enterprise#72343
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only
Original PR description
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only. Fix --- Add condition to check if the field is non empty before casting. Forward-Port-Of: odoo/enterprise#71295
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Resolve an issue where the compute method `_compute_is_there_shared_cert` was triggered before the record was saved, causing the domain to be incorrectly constructed with `company.id`. Replacing `company.id` with `company._origin.id` to ensure the correct domain is applied by accessing the original record instance. Forward-Port-Of: odoo/enterprise#72084
Original PR description
Resolve an issue where the compute method `_compute_is_there_shared_cert` was triggered before the record was saved, causing the domain to be incorrectly constructed with `company.id`. Replacing `company.id` with `company._origin.id` to ensure the correct domain is applied by accessing the original record instance. Forward-Port-Of: odoo/enterprise#72084
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496 Forward-Port-Of: odoo/enterprise#71726
Original PR description
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496 Forward-Port-Of: odoo/enterprise#71726
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Improve tooling defined in marketing automation, notably * add more verbose errors; * add parameters for trace check, notably to be less strict in case of duplicate-like traces; * improve tool methods generating activities; * assert some keys to be sure we effectively check what is intended; * add some docstrings while passing by; Task-2667099: [mail] Improve default template values Prepares Task-4224145: [marketing_automation] Improve test coverage Forward-Port-Of: odoo/ente
Original PR description
Improve tooling defined in marketing automation, notably * add more verbose errors; * add parameters for trace check, notably to be less strict in case of duplicate-like traces; * improve tool methods generating activities; * assert some keys to be sure we effectively check what is intended; * add some docstrings while passing by; Task-2667099: [mail] Improve default template values Prepares Task-4224145: [marketing_automation] Improve test coverage Forward-Port-Of: odoo/enterprise#72420
16 changes
Enhancements to existing features
Financial reports now show a clearer warning when a custom handler is configured. This makes the message easier for users to understand and reduces confusion caused by overly technical wording.
Original PR description
For usability; the previous message caused a bit of confusion, and was too technical to actually be understandable.
Resolved issues and error corrections
The accounting reports menu now correctly disables the XML and Copy to Documents buttons when users have not selected the full company and branch hierarchy. This prevents actions from being taken on incomplete report scopes, reducing confusion and avoiding incorrect document exports.
Original PR description
After [this refactoring] a regression occurred. Where previously the "XML" and "Copy to Documents" buttons were disabled when we didn't have the whole hierarchy of a company with its branches selected, it is not anymore. This commit fixes that. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501) [this refactoring]: https://github.com/odoo/enterprise/commit/1ea5dc3227913826a205b164c19e4771babc3326
Odoo Studio now shows the newer dynamic placeholder setting for text fields in a clearer way, reducing confusion when configuring forms. This helps users choose the right placeholder behavior without seeing an option that only worked in limited cases.
Original PR description
This commit changes the way we display placeholder options for the CharField when being selected by studio. Previously, it was confusing to edit the dynamic_placeholder option, which needs another option to work properly, and which don't make much sense in most cases. Instead, we choose to support only the recently added placeholder_field option, and to name it Dynamic Placeholder in the sidebar. task-3901821
This update fixes incorrect codes used for Group S work entry types in Belgian payroll. Correct codes help ensure payroll entries are classified properly for reporting and processing.
Original PR description
The groups s codes for work entry types were wrong. this commit adds the right codes for the work entry types. task-4221186
This fixes incorrect debit and credit amounts when viewing accounting reports across companies with different currencies. The report now keeps the correct date context so currency conversion rates are applied properly, improving accuracy for multi-company financial reporting.
Original PR description
Steps to reproduce: - have two companies with different main currencies - have currency rates != 1 for the selected main company - open the trial balance with both companies selected => The amounts displayed in Debit and Credit column from the first company are not converted to the main company currency. Reason of the issue: The general ledger custom code rewrite the options 'date_from' to the fiscal year date from, which results in a Null join with the account_currency_table
Miscellaneous changes
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happe
Original PR description
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly…
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happened because, when resetting the payment to draft in the test, we triggered this compute function on the account.payment https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_payment.py#L18. This compute function did not reassign the batch_payment_id field, but the ORM still considered it modified, and hence recomputed the payment method of the batch via this compute function https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L69 . Then, this field triggered the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L149. The test raised then just when initializing the assertRaises, when the stored payment_method_id field of the batch got recomputed. It is possible to force it by flushing at that point, otherwise, it's not exactly deterministic. The part of the constraint ensuring a draft payment cannot be added to a batch is the problem. The test tries to set one of the payments in the batch back to draft, and if this happens, the batch will end up in a state that is inconsistent with its own constraint. We fix the issue by simply removing it. This check is done again anyway when validating the batch payment. Doing things this way, we ensure the scenario of the test works in every case, whatever crazy recomputations happen in the ORM. Forward-Port-Of: odoo/enterprise#71924
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Original PR description
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next…
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#71921 Forward-Port-Of: odoo/enterprise#70577
Steps to reproduce the bug: - Create two Storable product: - “P1” -> product category A - “P2” -> product category B - Create a quality point: - picking type: receipt - product category: Cat A & Cat B - Measure: by quantity - Create a second quality point: - picking type: receipt - product category: Cat A - Measure: by quantity - Create a receipt of one unit of P1 and P2 - Confirm Problem: Four quality checks are created instead of three bec
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859
Forward-Port-Of: odoo/enterprise#71709
Forward-Port-Of: odoo/enterprise#71453…ifferent trees Add a field at the end of the "left" subgroup and remove the "right" subgroup. ```xml <form> <group> <group> <field name="display_name" /> [ADD A FIELD] </group> [ REMOVE THIS GROUP <group> </group> ] </group> </form> ``` Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between. We were left with the inheriting vi
Original PR description
…ifferent trees
Add a field at the end of the "left" subgroup and remove the "right" subgroup.
```xml
<form>
<group>
<group>
<field name="display_name" />
[ADD A FIELD]
</group>
[ REMOVE THIS GROUP
<group>
</group>
]
</group>
</form>
```
Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml
<xpath expr="[..]/group[2]" position="replace">
<field name="added_field" />
</xpath>
```
After this commit, this flow works and the two operations are independent.
part of task-4207793
Forward-Port-Of: odoo/enterprise#72273
Forward-Port-Of: odoo/enterprise#71289The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amount
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#72389 Forward-Port-Of: odoo/enterprise#65074
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72189 Forward-Port-Of: odoo/enterprise#71459
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72189 Forward-Port-Of: odoo/enterprise#71459
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only
Original PR description
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only. Fix --- Add condition to check if the field is non empty before casting. Forward-Port-Of: odoo/enterprise#71295
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
17 changes
New functionality added to Odoo
This update adds localization support for Lebanon, including a complete chart of accounts, tax definitions, and fiscal positions. This allows businesses operating in Lebanon to accurately manage their financial data within Odoo.
Original PR description
Added base localization package with chart of accounts ,taxes and fiscal positions for Lebanon 🇱🇧 Link to task: [#3927914](https://www.odoo.com/web#model=project.task&id=3927914)
Resolved issues and error corrections
This update fixes a calculation error in the Swiss payroll module (l10n_ch_hr_payroll_elm) related to the calculation of CAF (Additional Pension Fund). The system was previously using gross salary instead of the AVS (Swiss Social Security) salary, which is the correct basis for CAF calculations. This ensures accurate reporting and compliance with Swiss regulations.
Original PR description
CAF is based on the AVS Salary and not the GROSS
This update fixes a display issue in the employee timesheet leaderboard. Previously, the target value wasn't correctly reflected when changing billing time targets. This change ensures that the leaderboard accurately shows the employee's progress against their set billing time target, improving reporting accuracy.
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of the Billing Time Target to 100. - Again open the leaderboard in the timesheet. ### Issue 'x/' is displayed without the new target value. ### Cause Due to the wrong regular expression for the value. ### Solution Correct the regular expression. task-3970348
This update ensures Odoo can continue running on Debian by aligning with a recent change in the PDF library used. Specifically, Odoo has been updated to work with the newer, preferred version of the pypdf library, resolving compatibility issues that were preventing release on Debian. This ensures continued support for key Odoo features.
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian.
This update streamlines the process of booking appointments by standardizing how phone numbers and email addresses are handled. Previously inconsistent usage has been corrected, leading to a more reliable and user-friendly experience for customers. This change improves data accuracy and simplifies the booking flow.
Original PR description
Harmonize 'phone' field, normalize email usage Task-4154838
This fix ensures that when customers upgrade their subscriptions, the discount rates from their original subscription lines are properly preserved and applied to the new upsell lines. Previously, all upsell lines would incorrectly receive the same discount regardless of their original rates. This is especially important for mid-period upgrades where pricing is already adjusted, ensuring customers see accurate pricing that combines both their original discount and any prorated adjustments.
Original PR description
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration. i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount. opw-4081350 Forward-Port-Of: odoo/enterprise#72192
This update corrects how AC and ACC payroll rules handle AVS (pension) policy changes in Swiss payroll processing. The rules now properly verify they're using amounts from the same policy version, and the code has been simplified since all calculations are now centralized in the ACSALARY rule. This ensures accurate payroll calculations when employees switch pension policies.
Original PR description
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule.
The asset modification wizard now automatically updates the residual value when you change the modification date, giving you a more accurate view of your asset's remaining value. The system also intelligently shows or hides gain/loss account information based on whether there's actually a gain or loss to record, making the interface cleaner and less confusing.
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#70277
When users set up a new foreign VAT fiscal position, the system now automatically creates a draft tax closing move. This prevents a locking issue where the tax lock date would be set prematurely, blocking users from adding invoices to the new foreign closing position. This fix ensures smoother tax position setup and prevents workflow interruptions.
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position.
Fixed an issue where XML invoice documents were not being synchronized to the Documents workspace when using Belgian company setup with BIS Billing 3.0. When sending invoices with both PDF and XML attachments, only the PDF was appearing in the workspace. The fix ensures XML files are properly linked during the document creation process.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910
This fix ensures that when customers change product variants on a rental product page, the system properly checks and displays availability information for the selected variant. Previously, availability was not being updated, which could allow customers to attempt renting unavailable items without warning.
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172
This fix resolves a display issue where the Time Spent column was incorrectly hidden in the task list view when both timesheet and document management features are enabled. The fix ensures that only the cell content is hidden for projects without timesheets enabled, rather than hiding the entire cell, which was causing misalignment of other columns in the task list.
Original PR description
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the…
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the controller route if the user goes to the portal list view of tasks via a specific project, that is, in the route `/my/projects/<id of the project selected>`. And so, some unexpected behavior could happen in `/my/tasks` since it will not be expected to have a project variable set in that route. This commit makes sure the variable created in `documents_project` will only be used inside that template and not beeing used in other override of that template in other modules (such as the one in `hr_timesheet`). Steps to reproduce the issue ============================ 1. Install `hr_timesheet` and `documents_project` modules 2. Go to `Project > Configuration > Projects` 3. Disable the timesheets feature on the first project. 4. Go to `/my/tasks` (portal list view of all tasks) Actual Behavior --------------- The cell containing the Time Spent of each task is hidden, causing a wrong alignment for the next cells in the same row. Moreover, the cell will be hidden even for the tasks with the timesheets feature enabled. Expected Behavior ----------------- The content of the cell containing the Time Spent of each task with the timesheets feature disabled should be hidden instead of the cell itself to avoid breaking the alignment of the next cells in the row. task-4259996
This fix prevents users from accidentally clicking the 'Pair' button multiple times when connecting an IoT device. After a valid pairing code is submitted, the button is now disabled to avoid errors that occur when the same code is reused. This improves the user experience by preventing confusing error messages during the device setup process.
Original PR description
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295
This fix resolves an issue where changes to Display URL and Keyboard layout settings on IoT devices were not being saved when editing the device from the IoT box form. The problem occurred because the device form was opening in a dialog box instead of a full page view. The fix ensures the device form opens in full page view so all changes are properly synchronized to the IoT box.
Original PR description
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053
This fix resolves an issue in the Uruguay electronic invoicing system where invoices that were corrected and reposted after errors were being assigned incorrect document numbers. Previously, Odoo would use the next sequential number instead of a generic placeholder, preventing Uruware from assigning the correct official number. Now, when an invoice is reposted after correction, it receives a generic format that allows Uruware to properly assign the official sequence number.
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644
This fix restores the ability for users to reset cancelled invoices back to draft status when working with global invoices in Mexico. Previously, after cancelling a CFDI (Mexican electronic invoice) within a global invoice, the reset option was hidden, preventing users from making corrections. Now users can properly modify these invoices after cancellation.
Original PR description
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications.
This update corrects a test in the SEPA credit transfer module that was attempting to directly modify a protected field. The fix ensures the test follows proper data handling procedures, maintaining the integrity of account number validation in SEPA payment processing.
Original PR description
Direct update sanitized_acc_number is not allowed.