Daily updates from Odoo
Thursday, October 17, 2024
22 changes · master
Enhancements to existing features
The manufacturing maintenance app now explicitly relies on the stock maintenance component. This helps ensure the right supporting features are installed together, reducing setup issues and improving reliability.
Resolved issues and error corrections
This update simplifies how the system checks and opens files inside zipped documents such as spreadsheets and Mexican e-invoicing downloads. It avoids relying on internal software details, making these tests and related file handling more reliable over time.
Original PR description
Checking the filelist size before checking for existence based on `NamedToInfo` is unnecessarily convoluted, we can just compare the list of expected filenames to the `namelist()`. And using entry positions to open them is pretty much insane, just address the files by name, that's both clearer and more reliable. *Technically* for xlsx files we should probably go through `[Content_Types].xml` to retrieve the actual path to the shared strings file, but accessing that file directly is already an improvement I think.
Code cleanup and technical improvements
This update reduces unnecessary stored duplicate data in manufacturing and quality workflows now that the system can still report, group, and sort on those fields directly. The change helps simplify maintenance and may reduce database overhead without changing day-to-day user functionality.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, we can groupby/aggregate/sort on non-store related field. Remove store=True of some related fields (tradeoff is taken in account) for every logistics modules. https://github.com/odoo/odoo/pull/153463 https://github.com/odoo/upgrade/pull/5793
Miscellaneous changes
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762 Forward-Port-Of: odoo/enterprise#70335
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475 Forward-Port-Of: odoo/enterprise#71634
Original PR description
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475 Forward-Port-Of: odoo/enterprise#71634
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the num
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none Forward-Port-Of: odoo/enterprise#72138 Forward-Port-Of: odoo/enterprise#71423
In this commit, Remove the duplicate check for next_invoice_date Forward-Port-Of: odoo/enterprise#71310
Original PR description
In this commit, Remove the duplicate check for next_invoice_date Forward-Port-Of: odoo/enterprise#71310
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Original PR description
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535 Forward-Port-Of: odoo/enterprise#71891
Original PR description
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535 Forward-Port-Of: odoo/enterprise#71891
In this pr we refactor the methods that rely on `jquery` in favor of `fetch`. Forward-Port-Of: odoo/enterprise#70771
Original PR description
In this pr we refactor the methods that rely on `jquery` in favor of `fetch`. Forward-Port-Of: odoo/enterprise#70771
Currently, you view subscription quotations in the portal with a Brazilian company. ### Steps to reproduce * install `l10n_br_sales` * switch to a Brazilian company * attempt to "Preview" the subscription quotation You should be met with the following traceback: ``` AttributeError: 'NoneType' object has no attribute 'decimal_places' Template: l10n_br_sales.document_tax_totals_brazil Path: /t/tr[2]/td[2]/strong Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options=
Original PR description
Currently, you view subscription quotations in the portal with a Brazilian company.
### Steps to reproduce
* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to "Preview" the subscription quotation
You should be met with the following traceback:
```
AttributeError: 'NoneType' object has no attribute 'decimal_places'
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[2]/td[2]/strong
Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options="{"widget": "monetary", "display_currency": currency}"/>
```
opw-4247492
Forward-Port-Of: odoo/enterprise#72092After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189 Forward-Port-Of: odoo/enterprise#71997
Original PR description
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189 Forward-Port-Of: odoo/enterprise#71997
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the
Original PR description
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the user is printing the page or previewing it for print. Steps to reproduce the issue: 1. Go to the Knowledge app. 2. Open an article 3. Press `Ctrl` + `p` to print the article. => The print rules are not loaded and the page appears blank. TO BE: The print rules should be loaded. task-4191390 Forward-Port-Of: odoo/enterprise#70243
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist
Original PR description
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist on the same date; the actual issue is that the product is not available. opw-4085496 Forward-Port-Of: odoo/enterprise#69783
Similarly to odoo/odoo@f02bcfadcbb66fb237a5af3a10a35e36355b8b2e we no longer use the binary field which encodes the data to base64 because we were decoding it right after, which is useless work. We now directly read the raw data from the binary field underlying attachment Time spent in `_get_spreadsheet_snapshot` when opening a spreadsheet with a 16.7Mb snapshot: before: 189ms after: 101ms Forward-Port-Of: odoo/enterprise#71971
Original PR description
Similarly to odoo/odoo@f02bcfadcbb66fb237a5af3a10a35e36355b8b2e we no longer use the binary field which encodes the data to base64 because we were decoding it right after, which is useless work. We now directly read the raw data from the binary field underlying attachment Time spent in `_get_spreadsheet_snapshot` when opening a spreadsheet with a 16.7Mb snapshot: before: 189ms after: 101ms Forward-Port-Of: odoo/enterprise#71971
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company') By removing the countries field from the manifest, the modules now auto-install as expected, and the test
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.
Forward-Port-Of: odoo/enterprise#72132Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company. Forward-Port-Of: odoo/enterprise#72069
Original PR description
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company. Forward-Port-Of: odoo/enterprise#72069
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71936 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71936 Forward-Port-Of: odoo/enterprise#71802
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
Original PR description
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847