Tuesday, October 22, 2024
50 changes · saas-17.2
Miscellaneous changes
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#71860
Original PR description
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#71860
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72534
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. Forward-Port-Of: odoo/enterprise#72481
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. Forward-Port-Of: odoo/enterprise#72481
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.
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 Forward-Port-Of: odoo/enterprise#69085
### 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
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#72030 Forward-Port-Of: odoo/enterprise#70277
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#72030 Forward-Port-Of: odoo/enterprise#70277
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
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. Forward-Port-Of: odoo/enterprise#71857
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
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 Forward-Port-Of: odoo/enterprise#72351
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 Forward-Port-Of: odoo/enterprise#72351
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
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 Forward-Port-Of: odoo/enterprise#72020
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
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#72021
When all the customers to print in the report share the same language, we need to print the report in that language. opw-4144771 Forward-Port-Of: odoo/enterprise#71435
Original PR description
When all the customers to print in the report share the same language, we need to print the report in that language. opw-4144771 Forward-Port-Of: odoo/enterprise#71435
*l10n_din5008_account_followup, l10n_din5008_industry_fsm Related to: https://github.com/odoo/odoo/pull/183268 Forward-Port-Of: odoo/enterprise#72136 Forward-Port-Of: odoo/enterprise#71710
Original PR description
*l10n_din5008_account_followup, l10n_din5008_industry_fsm Related to: https://github.com/odoo/odoo/pull/183268 Forward-Port-Of: odoo/enterprise#72136 Forward-Port-Of: odoo/enterprise#71710
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72396
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72396
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#72358 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#72358 Forward-Port-Of: odoo/enterprise#72343
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
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. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#58487
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. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#58487
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