Friday, January 26, 2024
41 changes · saas-17.1
Miscellaneous changes
**Current behavior before PR:** Clicking on invalid link results in a blank and bizarre notification because we are accessing wrong parameter in wysiwyg.js. **Desired behavior after PR is merged:** After correcting parameters clicking on an invalid link triggers a notification displaying an invalid URL message. task-3563345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139301
Original PR description
**Current behavior before PR:** Clicking on invalid link results in a blank and bizarre notification because we are accessing wrong parameter in wysiwyg.js. **Desired behavior after PR is merged:** After correcting parameters clicking on an invalid link triggers a notification displaying an invalid URL message. task-3563345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139301
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go to eShop page of Website X Issue: On the eShop products list page, the price of the product should be "Tax Included"
Original PR description
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go to eShop page of Website X Issue: On the eShop products list page, the price of the product should be "Tax Included" ($115), but it is not. The displayed price is $100. When accessing the product page, the price is correctly displayed with the tax ($115). Cause: When computing the prices, taxes from parent companies are not taken into account. opw-3660156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151223
Adds the tax report, associated tax grids along with new taxes, required in order to generate a tax report as well as a SLS/P report Task id # 3211351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150619
Original PR description
Adds the tax report, associated tax grids along with new taxes, required in order to generate a tax report as well as a SLS/P report Task id # 3211351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150619
Before this PR: We used the .textsize method, which returned the height and width of the icon. However, in the latest version of Pillow, this method was deprecated, resulting in errors in the log. After this PR: We have transitioned to using the textbbox method, which returns the coordinates of the top, left, bottom, and right of the text's bounding box. From these coordinates, we calculate the height and width of the text. task-3502373 Forward-Port-Of: odoo/odoo#140613
Original PR description
Before this PR: We used the .textsize method, which returned the height and width of the icon. However, in the latest version of Pillow, this method was deprecated, resulting in errors in the log. After this PR: We have transitioned to using the textbbox method, which returns the coordinates of the top, left, bottom, and right of the text's bounding box. From these coordinates, we calculate the height and width of the text. task-3502373 Forward-Port-Of: odoo/odoo#140613
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix of manual fields (named x_...) and of base fields (originating from some mixin). Unlink all linked views or object, and try to unlink that model eventually. Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty. After this commit, the deletion works. Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added pa
Original PR description
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix of manual fields (named x_...) and of base fields (originating from some mixin). Unlink all linked views or object, and try to unlink that model eventually. Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty. After this commit, the deletion works. Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added partial support for this and a backport of 7550bcd61e52bc9c3de007d06cf95c91eaec893a which fixed the former PR in 17.0 opw-3558590 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#151238 Forward-Port-Of: odoo/odoo#151020
Dependencies and other manifest attributes are not set for data modules. Note: it's easier to reproduce issue in 17 since we have data module available on runbot. **steps to reproduce (in 17.0):** - install an industry (ex: bar_and_lounge) - uninstall a dependency of that module (ex: mrp) **before this commit:** - bar_and_lounge is not uninstalled if you uninstall mrp **after this commit:** - data model dependencies are handled the same way as 'regular' modules opw-3660052
Original PR description
Dependencies and other manifest attributes are not set for data modules. Note: it's easier to reproduce issue in 17 since we have data module available on runbot. **steps to reproduce (in 17.0):** - install an industry (ex: bar_and_lounge) - uninstall a dependency of that module (ex: mrp) **before this commit:** - bar_and_lounge is not uninstalled if you uninstall mrp **after this commit:** - data model dependencies are handled the same way as 'regular' modules opw-3660052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150926 Forward-Port-Of: odoo/odoo#149574
- Currently, once the SMS code has been created, it's valid forever, which is not very secure. Verification codes should expire after some time and users should have an opportunity to request a new one after some time elapses instead of having to cancel the registration and retry. - We've had several cases where users tried to register while having an active registration somewhere else. In that case, we cannot register them and we have to reach out to the user asking to deregister from the othe
Original PR description
- Currently, once the SMS code has been created, it's valid forever, which is not very secure. Verification codes should expire after some time and users should have an opportunity to request a new one after some time elapses instead of having to cancel the registration and retry. - We've had several cases where users tried to register while having an active registration somewhere else. In that case, we cannot register them and we have to reach out to the user asking to deregister from the other service. It is better to catch that instantly. task-3677877 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150970 Forward-Port-Of: odoo/odoo#149425
Instead of makchanging the type of lists to make an ormcache that works, we'v extracted the function that call the server apps.odoo.com to pass it the payload in json (as it will be sent to the server), and use the payload value as ormcache Forward-Port-Of: odoo/odoo#149015
Original PR description
Instead of makchanging the type of lists to make an ormcache that works, we'v extracted the function that call the server apps.odoo.com to pass it the payload in json (as it will be sent to the server), and use the payload value as ormcache Forward-Port-Of: odoo/odoo#149015
Instead of trying to find the reconciled lines recursively, we can use the `matching_number`, since it now has a distinct value for each subgraph of reconciliation even for partials graphs. The situation in 16 was computing the graph by doing one query per level of depth. In 17, before this commit, only one query was done but computing the graph from each node, leading in a worse time complexity. The result was that for small batches, it was slightly faster in 17 than 16 but considerably slow
Original PR description
Instead of trying to find the reconciled lines recursively, we can use the `matching_number`, since it now has a distinct value for each subgraph of reconciliation even for partials graphs. The situation in 16 was computing the graph by doing one query per level of depth. In 17, before this commit, only one query was done but computing the graph from each node, leading in a worse time complexity. The result was that for small batches, it was slightly faster in 17 than 16 but considerably slower for bigger batches. This commit just makes things go zoom in all cases. Forward-Port-Of: odoo/odoo#149336
The first commit fixes the behavior of the SelectMenu component when an option is being used with an empty string or a null value. Let's suppose we have the following choices: { label: 'Empty', value: '' }, { label: 'Full', value: 'full' } Before this fix, when selecting 'Empty', the value would be selected in the menu, but the toggler would still be empty, as if no value was selected. Now, any value corresponding to a choice value can be selected. A test has been added for each va
Original PR description
The first commit fixes the behavior of the SelectMenu component when an option
is being used with an empty string or a null value.
Let's suppose we have the following choices:
{ label: 'Empty', value: '' },
{ label: 'Full', value: 'full' }
Before this fix, when selecting 'Empty', the value would be selected in the
menu, but the toggler would still be empty, as if no value was selected.
Now, any value corresponding to a choice value can be selected.
A test has been added for each value supported (null and empty strings).
The second commit fixes the style of the SelectMenu since the Milk redesign
Forward-Port-Of: odoo/odoo#151276
Forward-Port-Of: odoo/odoo#150627This commit solves a crash which can happen when a popover points to an element inside an iframe that has been removed from the DOM. In those cases, the element's ownerDocument does not have a defaultView. Forward-Port-Of: odoo/odoo#151134 Forward-Port-Of: odoo/odoo#149174
Original PR description
This commit solves a crash which can happen when a popover points to an element inside an iframe that has been removed from the DOM. In those cases, the element's ownerDocument does not have a defaultView. Forward-Port-Of: odoo/odoo#151134 Forward-Port-Of: odoo/odoo#149174
Since [1] when installing a theme from the Website builder's Themes tab, if that theme used other snippets than the default ones in their configurator pages which were inherited, the import of the theme failed because the primary template was not generated before the import of the data files. This commit relies on each theme calling `_generate_primary_snippet_templates` before declaring templates that require them. In master, the early loading is removed altogether. See the changes in
Original PR description
Since [1] when installing a theme from the Website builder's Themes tab, if that theme used other snippets than the default ones in their configurator pages which were inherited, the import of the theme failed because the primary template was not generated before the import of the data files. This commit relies on each theme calling `_generate_primary_snippet_templates` before declaring templates that require them. In master, the early loading is removed altogether. See the changes in `theme_default` for the approach that was adopted through all themes. Steps to reproduce in master: - Start odoo-bin with `-i website`. - Edit home page. - Go to the "Theme" tab. - Click on "Switch Theme". - Pick "CORPORATE / Buzzy". => Fails because the `website.configurator_s_banner` template is not defined. [1]: https://github.com/odoo/odoo/commit/cfed4e391d11058b1b46417f0b630cdbc4070d7c task-3670496 Forward-Port-Of: odoo/odoo#148443
Steps to reproduce: - open bom - open product `Table` - set the quantity of all subproduct to `0` - Open overview Issue: the table top has 1 in qty Cause: For a bom subproduct, if there is no qty set (0/False), we automatically set the qty defined on the bom opw-3677052 Forward-Port-Of: odoo/odoo#149392
Original PR description
Steps to reproduce: - open bom - open product `Table` - set the quantity of all subproduct to `0` - Open overview Issue: the table top has 1 in qty Cause: For a bom subproduct, if there is no qty set (0/False), we automatically set the qty defined on the bom opw-3677052 Forward-Port-Of: odoo/odoo#149392
## Issue Main attachments on expense sheets was never correctly set, leading to missing attachment previews in the hr.expense.sheet form view, and unnecessary RPC requests to `register_main_attachment`, because the attachment was never set. ## Steps to reproduce - Install Expenses - Create 2 different expenses with different attachments - Create a report from those 2 expenses, save it - Notice there is nothing in the preview for the attachments, but if you zoom in or zoom out the page, t
Original PR description
## Issue Main attachments on expense sheets was never correctly set, leading to missing attachment previews in the hr.expense.sheet form view, and unnecessary RPC requests to…
## Issue Main attachments on expense sheets was never correctly set, leading to missing attachment previews in the hr.expense.sheet form view, and unnecessary RPC requests to `register_main_attachment`, because the attachment was never set. ## Steps to reproduce - Install Expenses - Create 2 different expenses with different attachments - Create a report from those 2 expenses, save it - Notice there is nothing in the preview for the attachments, but if you zoom in or zoom out the page, then you can see it. Also swiping on the list of attachments isn't persistent, once you refresh the page, the main attachment we selected lastly is lost. ## Cause There are 2 main issues: - `hr.expense.sheet` has `message_main_attachment_id`, but it's never set. - When writing an attachment via `register_main_attachment`, we pass only the id of the attachment. Then in the backend, the related record is based on the model of the attachment, but the attachment is linked to `hr.expense`, not `hr.expense.sheet`. Therefor we re-write the same attachment on the record we read the attachment from. And then the frontend will continue to call `register_main_attachment` everytime it tries to find the attachments linked to the sheet, but it's never done. ## Fix - Add a compute to initially set the value of the `message_main_attachment_id` based on the spec "we take the first line that has an attachment and we set it on the sheet" - The `hr.expense.sheet` now maintains a copies of the attachments linked to it's expenses, for proper ACL and functionality of `register_main_attachment`. ## Affected versions 16.0 up to master = saas-17.1 ## Reference task-3572440 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150501 Forward-Port-Of: odoo/odoo#142029
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but th
Original PR description
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf…
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but the POS button "to_invoice" at order checkout was used as a toggle between the types of invoices, instead of a choice to invoice or not. And since the generation of the invoice is strongly coupled with the generation of the pdf, I've added a context key to skip the pdf generation during POS checkout. The user can still "Send & Print" the invoice from the backend. The key is present when we *don't* select the invoice option at checkout (so for boleta invoices), for factura the invoice's pdf is created in sync. ## Affected versions 17.0 up to master ## Reference opw-3610333 Enterprise PR: https://github.com/odoo/enterprise/pull/53655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148159
This fixes names of VAT accounts in Slovak localization package as it uses the same names for sale and purchase accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151107
Original PR description
This fixes names of VAT accounts in Slovak localization package as it uses the same names for sale and purchase accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151107
Versions -------- 15.0+ Steps ----- 1. Go to Purchase; 2. create a Vendor Pricelist; 3. select a Product, a Product Variant & a Unit Price; 4. empty the Product field & save; 5. create a RFQ; 6. add the Product Variant from the Vendor Pricelist. Issue ----- The product's price remains 0. Cause ----- The `seller_ids` field in `product.template` creates one-to-many relation with `product.supplierinfo`'s `product_tmpl_id` field. While it is possible to select a specific produc
Original PR description
Versions -------- 15.0+ Steps ----- 1. Go to Purchase; 2. create a Vendor Pricelist; 3. select a Product, a Product Variant & a Unit Price; 4. empty the Product field & save; 5. create a RFQ; 6. add…
Versions -------- 15.0+ Steps ----- 1. Go to Purchase; 2. create a Vendor Pricelist; 3. select a Product, a Product Variant & a Unit Price; 4. empty the Product field & save; 5. create a RFQ; 6. add the Product Variant from the Vendor Pricelist. Issue ----- The product's price remains 0. Cause ----- The `seller_ids` field in `product.template` creates one-to-many relation with `product.supplierinfo`'s `product_tmpl_id` field. While it is possible to select a specific product variant and have the product field empty, this renders the Vendor Pricelist unavailable for Purchase Orders. Solution -------- Add a `_sanitize_vals` method to `product.supplierinfo` to be used on create/write, which ensures that if there's a `product_id`, the record's `product_tmpl_id` is consistent with it. This allows for record imports to be usable & consistent when only a variant is specified. Also backport a modified `onchange` method added in 5537090f1c688f0e1f9de366f83387277d60612a. Originally it only reset `product_id` if `product_tmpl_id` was changed to a different non-falsy value. Modified, it also resets `product_id` if `product_tmpl_id` is changed to a falsy value, as it would otherwise just re-add the removed value on create/write after this commit. opw-3664524 Forward-Port-Of: odoo/odoo#151045 Forward-Port-Of: odoo/odoo#149618
When importing an xml, impose a minimum length on the VAT to consider the value. Some xml contains VAT = "BE" (without numbers...). In this case, we search on the partners with matching VAT, and end up selecting a random belgium partner. Now, we only search the VAT if len(VAT) > 5. In addition, in a UBL xml where multiple tags can contain a VAT (PartyTaxScheme/CompanyID and PartyLegalEntity/CompanyID), we retain the first value which have the minimum length. opw-3675350 Forward-Port-Of
Original PR description
When importing an xml, impose a minimum length on the VAT to consider the value. Some xml contains VAT = "BE" (without numbers...). In this case, we search on the partners with matching VAT, and end up selecting a random belgium partner. Now, we only search the VAT if len(VAT) > 5. In addition, in a UBL xml where multiple tags can contain a VAT (PartyTaxScheme/CompanyID and PartyLegalEntity/CompanyID), we retain the first value which have the minimum length. opw-3675350 Forward-Port-Of: odoo/odoo#150959 Forward-Port-Of: odoo/odoo#150695
Commit [1] introduced a responsive font size feature was. Following this, in the context of mass mailing, an issue arises when users select a font size from the toolbar dropdown. Specifically, the `_computePxByRem` function converts the `px` value selected by the user to the wrong `rem` value. This is because it relies on the font size of the `html` element of the main window's document rather than that of the iframe's document. Since the iframe's document has a font size of 14px where the main
Original PR description
Commit [1] introduced a responsive font size feature was. Following this, in the context of mass mailing, an issue arises when users select a font size from the toolbar dropdown. Specifically, the…
Commit [1] introduced a responsive font size feature was. Following this, in the context of mass mailing, an issue arises when users select a font size from the toolbar dropdown. Specifically, the `_computePxByRem` function converts the `px` value selected by the user to the wrong `rem` value. This is because it relies on the font size of the `html` element of the main window's document rather than that of the iframe's document. Since the iframe's document has a font size of 14px where the main document has a font size of 16px, the conversion was faulty. Also, the value was cached on the window object, which is common to both documents. So this commit moves that cache to the document so two different values can be stored. [1]: https://github.com/odoo-dev/odoo/commit/ddf25a16c46bfc3628512aba1390a1e345ec719a task-3653543 Co-authored-by: Vishal Padhiyar <visp@odoo.com> Co-authored-by: Dieleman Guillaume <gdi@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147685
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve in less than 10ms apart. In such cases, the first re-evaluation becomes redundant, as a new one is immediately triggered. The issue is worse when more than 6 RPCs are required, as most browsers limit network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily wait after the evalu
Original PR description
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve…
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve in less than 10ms apart. In such cases, the first re-evaluation becomes redundant, as a new one is immediately triggered. The issue is worse when more than 6 RPCs are required, as most browsers limit network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily wait after the evaluation triggered by the first RPC to resolve. For spreadsheets with many many data sources, the accumulation of these pointless evaluations significantly impacts performance. In a real-life scenario with 18 data sources from our production database, the spreadsheet took approximately ~33s to fully load and become reactive. With this commit, the loading time is reduced to ~7s (only one evaluation instead of 18). Note that this testing was conducted locally, with minimal latency, and with a limited amount of data. One consequence of this commit is that cells won't load incrementally as each data source loads. Instead, all cells will display "Loading..." until all data sources are loaded. Given the substantial speed improvement, we consider this trade-off worthwhile. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149767
Steps to reproduce: - Install Accounting, Inventory, Sales and l10n_it_edi - Switch to an Italian company (e.g. IT company) - Create a storable product (e.g. Product X) - Update its available quantity to more than 0 - Create a SO with Product X and confirm it - Deliver the products - Install l10n_it_stock_ddt - From SO, create an invoice and confirm it Issue: When confirming the invoice, a traceback is raised: "TypeError: 'bool' object is not subscriptable" Cause: When installing
Original PR description
Steps to reproduce: - Install Accounting, Inventory, Sales and l10n_it_edi - Switch to an Italian company (e.g. IT company) - Create a storable product (e.g. Product X) - Update its available quantity to more than 0 - Create a SO with Product X and confirm it - Deliver the products - Install l10n_it_stock_ddt - From SO, create an invoice and confirm it Issue: When confirming the invoice, a traceback is raised: "TypeError: 'bool' object is not subscriptable" Cause: When installing "l10n_it_stock_ddt", a new char field "l10n_it_ddt_number" is added to "stock.picking" model, but its value is False for existing pickings. When generating the electronic invoice, "format_alphanumeric" is performed on the field, assuming it has a string value. opw-3661824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151166 Forward-Port-Of: odoo/odoo#149803
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatica
Original PR description
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatically reduce the font size of text in order to fit content within the specified page width. We use this option to help prevent content from overflowing the designated page boundaries. However, it seems that "smart shrink" doesn't take into account the text direction unless it is set on the `body` or `html` tag specifically. opw-3472357 opw-3567655 opw-3520084 opw-3683210 opw-3684178 Enterprise PR: odoo/enterprise#50530 Forward-Port-Of: odoo/odoo#151049 Forward-Port-Of: odoo/odoo#146470
**Current behaviour before commit:** In v16.0 and above clear format button was missing from snippet toolbar. This happens because when `_addToolbar` method is called second time `removeFormat` button can't be found in toolbar as it was appended to `$title`. **Desired behaviour after commit:** Now clear format button is getting appeared in snippet toolbar by using `this._$removeFormatButton` property. task-3638147 --- I confirm I have signed the CLA and read the PR guideline
Original PR description
**Current behaviour before commit:** In v16.0 and above clear format button was missing from snippet toolbar. This happens because when `_addToolbar` method is called second time `removeFormat` button can't be found in toolbar as it was appended to `$title`. **Desired behaviour after commit:** Now clear format button is getting appeared in snippet toolbar by using `this._$removeFormatButton` property. task-3638147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150620 Forward-Port-Of: odoo/odoo#147045
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#151191
Original PR description
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#151191
Kode transaksi is a required field on account moves. This field is either set on the move itself, or is taken from the partner. It NEEDS to be set when invoicing, but customers cannot provide this values by themselves when registering for example. This would cause issues with automatic subscriptions amongst other systems. In order to fix this issue, we will define the code 01 as default value. Note: there is no task linked to this small change --- I confirm I have signed the CLA
Original PR description
Kode transaksi is a required field on account moves. This field is either set on the move itself, or is taken from the partner. It NEEDS to be set when invoicing, but customers cannot provide this values by themselves when registering for example. This would cause issues with automatic subscriptions amongst other systems. In order to fix this issue, we will define the code 01 as default value. Note: there is no task linked to this small change --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151078
This commit adds translation capability to custom snippets. Before this commit, the custom snippet was not translate friendly: 1. Neither when saving a block as custom snippet 2. Neither when dropping a custom snippet into a page. This was a known limitation for years. But now it's time to make it work. Step to reproduce (part 1): - Enable french - Drag & drop Title snippet in a page - Translate the Title - Save the block as custom snippet -> Go in the backend view of this custom sni
Original PR description
This commit adds translation capability to custom snippets. Before this commit, the custom snippet was not translate friendly: 1. Neither when saving a block as custom snippet 2. Neither when dropping a custom snippet into a page. This was a known limitation for years. But now it's time to make it work. Step to reproduce (part 1): - Enable french - Drag & drop Title snippet in a page - Translate the Title - Save the block as custom snippet -> Go in the backend view of this custom snippet, in debug, there is no translation that followed the title. Step to reproduce (part 2): - Following previous steps, now add the translation manually on the custom snippet view - Back in a page in edit mode, drag & drop this custom snippet in the page - Switch to french -> The title is not translated, the drag & drop copy code but no translations task-3375518 opw-3242100 Forward-Port-Of: odoo/odoo#150945 Forward-Port-Of: odoo/odoo#125444
This bug was introduced from this commit 21ca976 This PR fixes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151067 Forward-Port-Of: odoo/odoo#150855
Original PR description
This bug was introduced from this commit 21ca976 This PR fixes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151067 Forward-Port-Of: odoo/odoo#150855
Problem: The test value for the expiration date was being shown on gift card reports that don't have expiration dates. Purpose: The expiration date should only be shown if it's set for the gift card code. It will be consistent with loyalty_report and the email template mail_template_gift_card in which both conditionally displays the expiration date. Steps to Reproduce on Runbot: 1. Install Sales 2. Settings > Sales > Enable Discounts & loyalty programs 3. Navigate to Sales > Gift cards
Original PR description
Problem: The test value for the expiration date was being shown on gift card reports that don't have expiration dates. Purpose: The expiration date should only be shown if it's set for the gift card code. It will be consistent with loyalty_report and the email template mail_template_gift_card in which both conditionally displays the expiration date. Steps to Reproduce on Runbot: 1. Install Sales 2. Settings > Sales > Enable Discounts & loyalty programs 3. Navigate to Sales > Gift cards and create/generate a gift card code with no expiration date 4. Print the gift card report and the report will show the expiration date of 2023-12-31 opw-3686110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150954
Add a l10n_ph_reports module, adding a new composite report comprised of two sub-reports: Summary List of Sales and Summary List of Purchases. Also add an export for these reports following the format set by the BIR. Task id #3211351 Forward-Port-Of: odoo/enterprise#54908
Original PR description
Add a l10n_ph_reports module, adding a new composite report comprised of two sub-reports: Summary List of Sales and Summary List of Purchases. Also add an export for these reports following the format set by the BIR. Task id #3211351 Forward-Port-Of: odoo/enterprise#54908
steps to reproduce: 1. Go to Payroll with Kenya localization 2. Click on Reports > NHIF Report or NSSF Report -> Odoo error because 0 is not a valid month Expected behavior: The wizards should not crash and the default month should be december fix: set the default month to december in january Behavior after fix: The wizards do not crash and the default month is december in january task-3668618 Forward-Port-Of: odoo/enterprise#53647
Original PR description
steps to reproduce: 1. Go to Payroll with Kenya localization 2. Click on Reports > NHIF Report or NSSF Report -> Odoo error because 0 is not a valid month Expected behavior: The wizards should not crash and the default month should be december fix: set the default month to december in january Behavior after fix: The wizards do not crash and the default month is december in january task-3668618 Forward-Port-Of: odoo/enterprise#53647
taskid: 3682434 Forward-Port-Of: odoo/enterprise#55135
Original PR description
taskid: 3682434 Forward-Port-Of: odoo/enterprise#55135
When setting an analytic distribution on an aml line in bank reco widget and switching to exchange diff line (and vice versa), the component is not rerendered, therefore analytic distribution is also set on analytic distribution component. opw-3686867 Forward-Port-Of: odoo/enterprise#55140
Original PR description
When setting an analytic distribution on an aml line in bank reco widget and switching to exchange diff line (and vice versa), the component is not rerendered, therefore analytic distribution is also set on analytic distribution component. opw-3686867 Forward-Port-Of: odoo/enterprise#55140
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but th
Original PR description
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf…
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but the POS button "to_invoice" at order checkout was used as a toggle between the types of invoices, instead of a choice to invoice or not. And since the generation of the invoice is strongly coupled with the generation of the pdf, I've added a context key to skip the pdf generation during POS checkout. The user can still "Send & Print" the invoice from the backend. The key is present when we *don't* select the invoice option at checkout (so for boleta invoices), for factura the invoice's pdf is created in sync. ## Affected versions 17.0 up to master ## Reference opw-3610333 Community PR: https://github.com/odoo/odoo/pull/148159 Forward-Port-Of: odoo/enterprise#53655
This commit modifies the text/plain blob used for the template behavior (now called the Clipboard) because it was using the innerHTML instead of text. This enabled the user to copy a string containing HTML tags instead of just text that was pasted inside of the small chatter. When the user click on the copy button we write inside of the user's clipboard a blob that contains a ClipboardItem. This Object enables us to choose which data should be pasted depending on a MIME Type. Here the `t
Original PR description
This commit modifies the text/plain blob used for the template behavior (now called the Clipboard) because it was using the innerHTML instead of text. This enabled the user to copy a string containing HTML tags instead of just text that was pasted inside of the small chatter. When the user click on the copy button we write inside of the user's clipboard a blob that contains a ClipboardItem. This Object enables us to choose which data should be pasted depending on a MIME Type. Here the `text/plain` and `text/html` were storing the same HTML. The issue is that when pasting inside an input that uses the `text/plain` type the user outputs the HTML as litteral string tags and all. Which is not ideal for the user as it would prefer to have the text content instead of the HTML. Now this blob will contain the innerText of the template reverting it to its default behavior. task-3691185 Forward-Port-Of: odoo/enterprise#54597
Currently some terms we not being translated besides having the term in the .pot file and the translation in the .po files. Steps to reproduce: ------------------- * Go to **Setting** * Add a language (french for example here) * Enable to translate to your website * Go to **website** * Select apointment * Select any appointment * Change the language of the website You can observe that the line *Select a time* is not being translated. When selecting **Translate**, you can observe th
Original PR description
Currently some terms we not being translated besides having the term in the .pot file and the translation in the .po files. Steps to reproduce: ------------------- * Go to **Setting** * Add a language (french for example here) * Enable to translate to your website * Go to **website** * Select apointment * Select any appointment * Change the language of the website You can observe that the line *Select a time* is not being translated. When selecting **Translate**, you can observe that the line is not highlight in yellow or green. Why the fix: ------------ When the route `/website/translations` is called, the modules loaded do not include appointment. opw-3671043 Forward-Port-Of: odoo/enterprise#54377
When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account Error:- ``` ValueError: Expected singleton: mail.message(195, 193, 192) File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", line 1732, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/service/model.py", line 133, in retrying re
Original PR description
When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account Error:- ``` ValueError: Expected…
When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account
Error:-
```
ValueError: Expected singleton: mail.message(195, 193, 192)
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/whatsapp/controller/main.py", line 42, in webhookpost
wa_account_id._process_messages(value)
File "home/odoo/src/enterprise/17.0/whatsapp/models/whatsapp_account.py", line 190, in _process_messages
channel = self.env['discuss.channel'].sudo().search([('message_ids', 'in', parent_id.id)], limit=1)
File "odoo/fields.py", line 5118, in __get__
raise ValueError("Expected singleton: %s" % record)
```
This is because at line [1], we receive multiple parent ids in WhatsApp messages because the value of `context.get()` is none, so at line [1] searches for the message whose msg_uid is not set (messages either in queue or failed).
This commit fixes the above issue by adding the condition that checks the ID is present in the context of the message.
https://github.com/odoo/enterprise/blob/272856993b21d9e7edfb573e33a368f80ba0c9c8/whatsapp/models/whatsapp_account.py#L185
sentry-4745952077
Forward-Port-Of: odoo/enterprise#53500Because of the renaming of the some lines, it causes conflict. For l10n_pl_small_bs_assets_a_3, we had a shortcut for the expression. We need to nullify it, if not the field stays filled on the model. For l10n_pl_small_bs_assets_a_4, the problem is bigger. We had an aggregation before and we go to a line with groupby. The problem is that we add the groupby before the suppression of expressions. We can't nullify a field to correct it, so we just change the ids back. Linked to runbo
Original PR description
Because of the renaming of the some lines, it causes conflict. For l10n_pl_small_bs_assets_a_3, we had a shortcut for the expression. We need to nullify it, if not the field stays filled on the model. For l10n_pl_small_bs_assets_a_4, the problem is bigger. We had an aggregation before and we go to a line with groupby. The problem is that we add the groupby before the suppression of expressions. We can't nullify a field to correct it, so we just change the ids back. Linked to runbot error 55641, 55642, 55643, 55644 Forward-Port-Of: odoo/enterprise#54688
Currently, a public user can't add any product to the cart when using GeoIP and Avatax. ### Steps to reproduce * setup GeoIP[^1] * setup Avatax credentials * enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position * access to the website as a public user with an IP address from the US[^1] * try adding a product to the cart. You should be met with a validation pop. [^1]: This is quite annoying to reproduce on a local database. In cases like these,
Original PR description
Currently, a public user can't add any product to the cart when using GeoIP and Avatax. ### Steps to reproduce * setup GeoIP[^1] * setup Avatax credentials * enable "Detect Automatically" on the…
Currently, a public user can't add any product to the cart when using GeoIP and Avatax.
### Steps to reproduce
* setup GeoIP[^1]
* setup Avatax credentials
* enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position
* access to the website as a public user with an IP address from the US[^1]
* try adding a product to the cart.
You should be met with a validation pop.
[^1]:
This is quite annoying to reproduce on a local database. In cases like these, I find it much easier to directly modify the code in order to emulate the behavior we want. Here, you can simply replace the entire content of `odoo/addons/http_routing/geoipresolver.py` with the following:
```py
class GeoIPResolver(object):
@classmethod
def open(cls, fname):
return GeoIPResolver()
def resolve(self, ip):
return {
'city': 'New York',
'country_code': 'US',
'country_name': 'United States',
'latitude': 40.7263,
'longitude': -73.9818,
'region': 'NY',
'time_zone': 'America/New_York'
}
```
### Cause
For the Avatax fiscal position to work, we need the partner's country, state and zip code. Usually, this isn't a problem because the fiscal position is set after the Public User enters their address. But, when using GeoIp, the fiscal position is set right when the user lands on the page, based on their location data. This triggers a check for the address, but the Public User hasn't entered one yet, which causes a validation error.
opw-3625410
Forward-Port-Of: odoo/enterprise#53547Before this commit, the filter for EC Sale List codes was invisible if the report doesn't have a variant. It was caused by the xpath based on a div which can be not present in the DOM. When this div is not present, the filter doesn't appear. no task id Forward-Port-Of: odoo/enterprise#55120
Original PR description
Before this commit, the filter for EC Sale List codes was invisible if the report doesn't have a variant. It was caused by the xpath based on a div which can be not present in the DOM. When this div is not present, the filter doesn't appear. no task id Forward-Port-Of: odoo/enterprise#55120
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatica
Original PR description
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting…
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatically reduce the font size of text in order to fit content within the specified page width. We use this option to help prevent content from overflowing the designated page boundaries. However, it seems that "smart shrink" doesn't take into account the text direction unless it is set on the `body` or `html` tag specifically. opw-3472357 opw-3567655 opw-3520084 opw-3683210 opw-3684178 Community PR: odoo/odoo#146470 Forward-Port-Of: odoo/enterprise#55107 Forward-Port-Of: odoo/enterprise#50530
Before this commit, credit notes would be calculated to have a negative total amount which is incorrect and prevents posting. New in Odoo 17 is that account_external_tax sets line.price_subtotal on invoices. This was necessary to correctly support price-included taxes for Brazil. A side-effect is that it uncovers an inconsistency in the US integration [1]. Avatax returns negative amounts (both lineAmount and tax) when the record is a ReturnInvoice. In Odoo we don't invert the price_* fields o
Original PR description
Before this commit, credit notes would be calculated to have a negative total amount which is incorrect and prevents posting. New in Odoo 17 is that account_external_tax sets line.price_subtotal on invoices. This was necessary to correctly support price-included taxes for Brazil. A side-effect is that it uncovers an inconsistency in the US integration [1]. Avatax returns negative amounts (both lineAmount and tax) when the record is a ReturnInvoice. In Odoo we don't invert the price_* fields on account.move.line for credit notes so this commit inverts the sign coming from Avatax in these cases. [1] PS. in https://github.com/odoo/enterprise/pull/45095#issuecomment-1696102292 opw-3699206 Forward-Port-Of: odoo/enterprise#55094