Thursday, May 2, 2024
33 changes · saas-17.1
Enhancements to existing features
The product UNSPSC reference list has been updated to include missing classification codes that were reported. This helps businesses categorize products more accurately for reporting, purchasing, and compliance workflows.
Original PR description
Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714 Related PR: https://github.com/odoo/enterprise/pull/61618
Resolved issues and error corrections
The recruitment app now counts job applications linked to records that are shared across all companies. This gives businesses using multiple companies a more accurate applicant total and avoids undercounting candidates.
Original PR description
Record without company_id is visible for all commpanies. In the context of counting applicants, these records are now included in the total applicant count.
Miscellaneous changes
Versions -------- - 16.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Forward-Port-Of: odoo/odoo#164034 Forward-Port-Of: odoo/odoo#163154
Original PR description
Versions -------- - 16.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Forward-Port-Of: odoo/odoo#164034 Forward-Port-Of: odoo/odoo#163154
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin on that menu to compensate the parent navbar's padding. However, [2] later forced that parent padding to 0 with a class. This commit removes the negative margin compensation to fix the issue. Note: the design may not seem that broken without this fix. But in custo it could look very bad as it co
Original PR description
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin…
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin on that menu to compensate the parent navbar's padding. However, [2] later forced that parent padding to 0 with a class. This commit removes the negative margin compensation to fix the issue. Note: the design may not seem that broken without this fix. But in custo it could look very bad as it could introduce a horizontal scrollbar: just make the portal layout use a fluid container and have `$navbar-padding-x` be higher than `$grid-gutter-width`. Also, note that the design is not perfect as the inner padding of that menu also relies on the navbar padding value... which is ok in Odoo but only because we change the default of Bootstrap, which is 0. It was chosen to ignore that problem in stable. In master, the navbar padding will be left back to the BS default (0) and another spacing value will thus be used for the portal menu. [1]: https://github.com/odoo/odoo/commit/f8940943592b696b4f27c0013f837a6cdecb0433 [2]: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 Related to https://github.com/odoo/odoo/pull/163996 | Before | After | | -------- | -------- | |  |  | Forward-Port-Of: odoo/odoo#164014
The Kitchen Display app uses a conditional menu that can leads to the frontend. In some situation, other apps are tested again during the Kitchen Display test leading to a mess in the logs and a epic failure. As no viable solution was found, the menu is now skippep with this commit. Forward-Port-Of: odoo/odoo#164006
Original PR description
The Kitchen Display app uses a conditional menu that can leads to the frontend. In some situation, other apps are tested again during the Kitchen Display test leading to a mess in the logs and a epic failure. As no viable solution was found, the menu is now skippep with this commit. Forward-Port-Of: odoo/odoo#164006
Since 3.8, some ast object and parameters changed, with backward compatibility. They are now deprecate in 3.12 and will be removed in 3.14. Keeping a compatibility between both solutions is possible but hard to do with python > 3.7, the solution was to mute the warning in odoo 15.0 since it is unlikely to make it compatible with python 3.14, but we can fix it a cleaner way in 16.0 since the minimal python version is higher than 3.8. **EDIT 16.0 minimal version is actually 3.7, this can be
Original PR description
Since 3.8, some ast object and parameters changed, with backward compatibility. They are now deprecate in 3.12 and will be removed in 3.14. Keeping a compatibility between both solutions is possible but hard to do with python > 3.7, the solution was to mute the warning in odoo 15.0 since it is unlikely to make it compatible with python 3.14, but we can fix it a cleaner way in 16.0 since the minimal python version is higher than 3.8. **EDIT 16.0 minimal version is actually 3.7, this can be adapted starting in 16.3** reverted in #164011 see #162438 for 15.0 suppress warning fix part of #162438 , adaptations for ubuntu noble Forward-Port-Of: odoo/odoo#163982 Forward-Port-Of: odoo/odoo#163487
**Steps** - Install hr_timesheet. - Create a new product. - Add a property to the product, type many2one, model Project. - Chose any project. - Save the product. ** Traceback error ** **Issue** When the product is saved, the product.template model is flushed and the context keys are all set to None. https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L6352 Which causes a problem when computing the display_name of project.project **Fix** Handle t
Original PR description
**Steps** - Install hr_timesheet. - Create a new product. - Add a property to the product, type many2one, model Project. - Chose any project. - Save the product. ** Traceback error ** **Issue** When the product is saved, the product.template model is flushed and the context keys are all set to None. https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L6352 Which causes a problem when computing the display_name of project.project **Fix** Handle the case where context=None. opw-3885370 Forward-Port-Of: odoo/odoo#163306
Steps: - Install timesheet app. - Create a project and task in that project. - Add timesheet in that task. - Share that project. - Open that project in project sharing in mobile. - Open task form and go to timesheet page. Issue: - Employee field is displayin twice instead of displaying avatar and it's name. Cause: - PR-https://github.com/odoo/odoo/pull/95971 here it suposed to add employee avatar in portal but it added same employee that why employee name is showing twice in kanban
Original PR description
Steps: - Install timesheet app. - Create a project and task in that project. - Add timesheet in that task. - Share that project. - Open that project in project sharing in mobile. - Open task form and go to timesheet page. Issue: - Employee field is displayin twice instead of displaying avatar and it's name. Cause: - PR-https://github.com/odoo/odoo/pull/95971 here it suposed to add employee avatar in portal but it added same employee that why employee name is showing twice in kanban. Fix: - Added kanban avatar instead of employee field twice to display employee avatar properly. task-3716784 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#153390
This commit is: 1. Forcing the website domain (if set) when generating the sitemap, instead of the root url. Otherwise, it was possible to generate the sitemap for a website with a non canonical URL. It's not the end of the world as those non canonical pages have a canonical meta tag anyway to correctly "explain" to the crawler where to go, but always using the correct domain is better. Note that this sitemap, once generated, is cached for 12 hours. 2. Adding link to the canonical sitemap on t
Original PR description
This commit is: 1. Forcing the website domain (if set) when generating the sitemap, instead of the root url. Otherwise, it was possible to generate the sitemap for a website with a non canonical URL.…
This commit is: 1. Forcing the website domain (if set) when generating the sitemap, instead of the root url. Otherwise, it was possible to generate the sitemap for a website with a non canonical URL. It's not the end of the world as those non canonical pages have a canonical meta tag anyway to correctly "explain" to the crawler where to go, but always using the correct domain is better. Note that this sitemap, once generated, is cached for 12 hours. 2. Adding link to the canonical sitemap on the robots.txt page if we are not on the canonical robots.txt. Note that this robots.txt was already forbidding all pages with `Disallow: /`. This is a good practice, see this google doc [1]: `The URL doesn't have to be on the same host as the robots.txt file.` 3. Using the website domain (if set) to generate the opengraph links. This one is probably just nitpicking and to prevent bad copy paste as it doesn't really change anything. Step to reproduce: - Install website - Set `http://localhost:8069/` as website domain - Go to `http://127.0.0.1:8069/sitemap.xml` (it's cached for 12 hours once you generated it by accessing it the first time) - Go to `http://localhost:8069/sitemap.xml`, it will be displaying pages with `127.0.0.1` URL instead of the canonical localhost. [1]: https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt?hl=en#sitemap task-3391021 opw-3366013 opw-2311003 opw-2358120 opw-3105191 opw-2949165 opw-3341083 opw-3103527 opw-3075342 opw-2962433 opw-2718606 opw-2674387 opw-2647926 opw-3163677 opw-3114853 Forward-Port-Of: odoo/odoo#127265
The tag `udt:Indicator` should either be "true" or "false" but not "faux", which will raise an exception on the Chorus Pro platform. opw-3859249 Forward-Port-Of: odoo/odoo#163990
Original PR description
The tag `udt:Indicator` should either be "true" or "false" but not "faux", which will raise an exception on the Chorus Pro platform. opw-3859249 Forward-Port-Of: odoo/odoo#163990
Two account translations were missing in the Italian localization. We're adding them here. Forward-Port-Of: odoo/odoo#163999
Original PR description
Two account translations were missing in the Italian localization. We're adding them here. Forward-Port-Of: odoo/odoo#163999
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add product; 6. change the unit price. Issue ----- The unit price changes back to default. Cause ----- When changing the `price_unit` field, the `_compute_amount` method gets triggered, which depends on the `discount` field. As this field wasn't present in the mobile view, its compute me
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add…
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add product; 6. change the unit price. Issue ----- The unit price changes back to default. Cause ----- When changing the `price_unit` field, the `_compute_amount` method gets triggered, which depends on the `discount` field. As this field wasn't present in the mobile view, its compute method was called, which is the same method that computes `price_unit`. Normally this method skips recomputing `price_unit` if it was modified, but because `sale_timesheet` makes `uom.group_user` an implied ID of `base.group_user`, it can now access the `product_uom` field, and assumes a change from `_origin` as there is no `_orgin.product_uom` to compare it to if the PO hasn't been saved yet. Solution -------- Add the `discount` field to the mobile kanban view. Also display the discount on mobile if its value is non-zero. opw-3767765 Forward-Port-Of: odoo/odoo#161355
Commit [1] made sure `span`s without attributes are removed, as they're useless. However, it did not take pseudo-elements into account. This commit ensures that if there is no attribute but a pseudo-element can be detected, the tag is not removed. [1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c opw-3881401 Forward-Port-Of: odoo/odoo#163627 Forward-Port-Of: odoo/odoo#163392
Original PR description
Commit [1] made sure `span`s without attributes are removed, as they're useless. However, it did not take pseudo-elements into account. This commit ensures that if there is no attribute but a pseudo-element can be detected, the tag is not removed. [1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c opw-3881401 Forward-Port-Of: odoo/odoo#163627 Forward-Port-Of: odoo/odoo#163392
Since commit [1], a fake unit can be specified on `InputUserValueWidget` widgets, thanks to the `data-fake-unit` attribute. It allows to display a unit whose purpose is only to show a dummy unit and which does not need to be converted to other ones. However, it is still a unit, so the value written in the input should still be considered as numeric and should therefore be processed as such (e.g. checking if it has the correct format or if it is well a number). This is currently not the case,
Original PR description
Since commit [1], a fake unit can be specified on `InputUserValueWidget` widgets, thanks to the `data-fake-unit` attribute. It allows to display a unit whose purpose is only to show a dummy unit and…
Since commit [1], a fake unit can be specified on `InputUserValueWidget` widgets, thanks to the `data-fake-unit` attribute. It allows to display a unit whose purpose is only to show a dummy unit and which does not need to be converted to other ones. However, it is still a unit, so the value written in the input should still be considered as numeric and should therefore be processed as such (e.g. checking if it has the correct format or if it is well a number). This is currently not the case, since only values with real units (i.e. with `data-unit`) allows to go through these checks. This means that fake unit inputs can accept any values, which can cause errors if only numeric ones were expected (e.g. for numeric CSS properties). The same goes for inputs without unit but still having a step specified. Indeed, the `data-step` attribute allows to increase/decrease the value by using the keyboard arrows, which implies that the value should be considered as numeric. Note that no option is really broken by that, as they generally either parsed the value themselves or accepted the value without any traceback assuming that the user should write logical values and should not be surprised if it does not work. But the comma use case makes it worth being fixed. This commit adds the fake unit and step cases to the checks, so the input values are considered as numeric and can properly be parsed to numbers. Steps to reproduce: For the fake unit case: - In website edit mode, go to the "Theme" tab in the right panel. - In the "Paragraph" section, set the "Line Height" option to a decimal number but with a comma instead of a period. - Save. => There is a style compilation error, because the value was used as is in the CSS file, which is not correct. If it was a real unit, the value would have been cut before the comma by the `parseFloat` function. For the step case: - In edit mode, drop the "Form" snippet. - Add a new field and set its "Type" option to "File Upload". - Set the "Max # Of Files" option to a decimal number but with a comma. => If we wrote a number bigger than 1 to allow uploading multiple files, the field will stay as a single file input. [1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086 opw-3635886 Forward-Port-Of: odoo/odoo#163160
Steps to reproduce ================== - Enable debug mode - Go to studio - Add a new field - Switch to the view tab - Restore the default view => The old view is displayed Cause of the issue ================== The studio view is unlinked [0] but the template cache is not cleared --- [0]: https://github.com/odoo/enterprise/blob/b97f4c440d020141940a3d9e05aa25c9847ae5b9/web_studio/controllers/main.py#L448 Forward-Port-Of: odoo/odoo#162953
Original PR description
Steps to reproduce ================== - Enable debug mode - Go to studio - Add a new field - Switch to the view tab - Restore the default view => The old view is displayed Cause of the issue ================== The studio view is unlinked [0] but the template cache is not cleared --- [0]: https://github.com/odoo/enterprise/blob/b97f4c440d020141940a3d9e05aa25c9847ae5b9/web_studio/controllers/main.py#L448 Forward-Port-Of: odoo/odoo#162953
Steps to reproduce ================== - Install stock,purchase - Create a new storable product tracked by USN - Create a new RFQ with that product - Confirm it - Click on the receipt smart button - In the operation notebook, click on the "Open move" button (last blue button) - Press tab => The focus is moved to the list view outside the dialog Cause of the issue ================== This issue is specific to the `StockMoveX2ManyField` as it's the only one where you can eith
Original PR description
Steps to reproduce ================== - Install stock,purchase - Create a new storable product tracked by USN - Create a new RFQ with that product - Confirm it - Click on the receipt smart button - In the operation notebook, click on the "Open move" button (last blue button) - Press tab => The focus is moved to the list view outside the dialog Cause of the issue ================== This issue is specific to the `StockMoveX2ManyField` as it's the only one where you can either edit the record inline, or open it in a dialog. Outside stock, if we are allowed to edit a line record in a dialog, isInlineEditable will evalutate to false. In that case, the record will be considered readonly, and focusCell won't do anything. Solution ======== We should only change the focus is the list view is the one from `uiService.activeElement` opw-3719834 Forward-Port-Of: odoo/odoo#157603
Previously, some pieces of tracking info were parsed in the wrong format in the product configurator. I.e. id, quantity and price were parsed as strings but should be numbers (to be consistent with tracking info computations elsewhere). This change fixes the issue. Fixes #158052 Forward-Port-Of: odoo/odoo#163743 Forward-Port-Of: odoo/odoo#162932
Original PR description
Previously, some pieces of tracking info were parsed in the wrong format in the product configurator. I.e. id, quantity and price were parsed as strings but should be numbers (to be consistent with tracking info computations elsewhere). This change fixes the issue. Fixes #158052 Forward-Port-Of: odoo/odoo#163743 Forward-Port-Of: odoo/odoo#162932
### Steps to reproduce: - Create a storable product and add a vendor - Go to settings and activate the Multi-step Routes - Go to Inventory > Configuration > Warehouse Manag. > Operations Types - Create a new Operation type of type Receipt with WH/Stock/Shelf 1 as default Destination Location - Go to Inventory > Operations > Replenishment - Create a new replenishment for one unit of your storable product using the Buy route with destination WH/Stock - Click on the truck icon > go to the
Original PR description
### Steps to reproduce: - Create a storable product and add a vendor - Go to settings and activate the Multi-step Routes - Go to Inventory > Configuration > Warehouse Manag. > Operations Types -…
### Steps to reproduce: - Create a storable product and add a vendor - Go to settings and activate the Multi-step Routes - Go to Inventory > Configuration > Warehouse Manag. > Operations Types - Create a new Operation type of type Receipt with WH/Stock/Shelf 1 as default Destination Location - Go to Inventory > Operations > Replenishment - Create a new replenishment for one unit of your storable product using the Buy route with destination WH/Stock - Click on the truck icon > go to the associated Purchase order - Add your receipt operation in the deliver to field - Confirm the purchase order and go to the associated receipt ### Current behavior: The destination of the stock picking is set to WH/Stock/Shelf1 but the detailed operation of the stock move line is set to WH/Stock. ### Expected behavior: The destination of the stock move line should always be more or equally as precise as the associated stock picking. In this case the destination should be WH/Stock/Shelf1. ### Cause of the issue: Confirming the PO, will first create a stock picking and then generate the associated stock moves from the purchase order lines and the picking: https://github.com/odoo/odoo/blob/3f7b19ba05acf59c5780444be2446fcb0da7a907/addons/purchase_stock/models/purchase.py#L225-L230 However, since the purchase order was created via an orderpoint (our replenishment), the purchase order line is associated with an orderpoint, so that the stock move destination will be set to the destination of the orderpoint in priority: https://github.com/odoo/odoo/blob/3f7b19ba05acf59c5780444be2446fcb0da7a907/addons/purchase_stock/models/purchase.py#L514 opw-3812952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163235 Forward-Port-Of: odoo/odoo#161285
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag
Original PR description
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag started, therefore it would never start. This commit fixes the issue by setting the tolerance to 0, so the drag and drop starts immediately. task-3802746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157584
Steps to reproduce the bug: - Create a storable product C1: - standard_price: $10 - Update the quantity to 2 units - Create a storable product P1 with BoM: - Component: 1 unit of C1 - Create a MO to produce 1 unit of P1: - Confirm it - Update the price of C1 to $20 - Go back to the MO and set the quantity consumed of C1 to 2 - Mark the MO as done - Confirm the difference in consumption Problem: Another move is created with 1 unit of C1 consumed but is not merged
Original PR description
Steps to reproduce the bug: - Create a storable product C1: - standard_price: $10 - Update the quantity to 2 units - Create a storable product P1 with BoM: - Component: 1 unit of C1 - Create a MO to produce 1 unit of P1: - Confirm it - Update the price of C1 to $20 - Go back to the MO and set the quantity consumed of C1 to 2 - Mark the MO as done - Confirm the difference in consumption Problem: Another move is created with 1 unit of C1 consumed but is not merged with the first move because the two moves were created with different prices, making them incompatible for merging. Solution: There's no need to create the moves with `price_unit`. OPW-3791816 Forward-Port-Of: odoo/odoo#163175
Steps: - Set up LDAP authentication with Create User enabled and a Template User set - Log in with an LDAP identity that doesn't have an account yet Get odoo.exceptions.MissingError: Record does not exist or has been deleted See https://github.com/odoo/odoo/issues/41060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162456
Original PR description
Steps: - Set up LDAP authentication with Create User enabled and a Template User set - Log in with an LDAP identity that doesn't have an account yet Get odoo.exceptions.MissingError: Record does not exist or has been deleted See https://github.com/odoo/odoo/issues/41060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162456
Steps to reproduce: - create-aprove-post an expense - Go to the accounting dashboard Issue: expenses' amount is 0 Cause: In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result: https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644 Solution: Get the right columns. We also change the domain to make sure that expenses partially paid ar
Original PR description
Steps to reproduce: - create-aprove-post an expense - Go to the accounting dashboard Issue: expenses' amount is 0 Cause: In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result: https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644 Solution: Get the right columns. We also change the domain to make sure that expenses partially paid are also displayed. Note: For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed. In master: Use the amount_residual (discussed with po Laura) opw-3849036 Forward-Port-Of: odoo/odoo#162182
Quick fix to unlock runbot and mergebot builds. Forward-Port-Of: odoo/odoo#164141
Original PR description
Quick fix to unlock runbot and mergebot builds. Forward-Port-Of: odoo/odoo#164141
… variables To be able to render a human-readable qweb, we need to evaluate some arbitrary python expressions. Thos can produce bad sql queries because at this point, we are not, by construction in the conditions that produce correct queries (missing records etc....) Before this commit, when an query error occured at that step, the whole transaction was corrupted, and crashed the whole thing. After this commit, we do our partial evaluation things in a separate cursor, to avoid polluting
Original PR description
… variables To be able to render a human-readable qweb, we need to evaluate some arbitrary python expressions. Thos can produce bad sql queries because at this point, we are not, by construction in the conditions that produce correct queries (missing records etc....) Before this commit, when an query error occured at that step, the whole transaction was corrupted, and crashed the whole thing. After this commit, we do our partial evaluation things in a separate cursor, to avoid polluting the main one. opw-3815284 Forward-Port-Of: odoo/enterprise#60754
Before this commit: ============== When the delivery address is in India but the invoice address is outside India, Shiprocket will not consider the shipping address and mobile number from a different country. After this commit: ============== The correct phone/mobile number is provided for the delivery address. opw - 3841506 Forward-Port-Of: odoo/enterprise#61234
Original PR description
Before this commit: ============== When the delivery address is in India but the invoice address is outside India, Shiprocket will not consider the shipping address and mobile number from a different country. After this commit: ============== The correct phone/mobile number is provided for the delivery address. opw - 3841506 Forward-Port-Of: odoo/enterprise#61234
This commit moves the call for the Banxico currency update to the IAP server, where we can create a daily cache of currency rates. Part of: task-3749574 Forward-Port-Of: odoo/enterprise#61726 Forward-Port-Of: odoo/enterprise#58685
Original PR description
This commit moves the call for the Banxico currency update to the IAP server, where we can create a daily cache of currency rates. Part of: task-3749574 Forward-Port-Of: odoo/enterprise#61726 Forward-Port-Of: odoo/enterprise#58685
`Net profit/Loss for the Year` report.line has now an aggregation expression[1] which cannot have a groupby. But as the groupby field was removed instead of set to `eval=False`. The groupby is still there and blocking upgrades to 16.0 and 17.0 [1] https://github.com/odoo/enterprise/pull/52157 ``` File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
Original PR description
`Net profit/Loss for the Year` report.line has now an aggregation expression[1] which cannot have a groupby. But as the groupby field was removed instead of set to `eval=False`. The groupby is still there and blocking upgrades to 16.0 and 17.0
[1] https://github.com/odoo/enterprise/pull/52157
```
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_no_reports/data/profit_loss.xml:3
Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'Net profit/Loss for the Year'
View error context:
'-no context-'
```
Forward-Port-Of: odoo/enterprise#61445As seen in support tickets, other errors can be raised by PyPDF2 when trying to compute pages count on corrupted files. As we are not going to do any kind of handling and must not crash because of this, we'll simply log and discard any non-exit exception raised. Task-3614532 Forward-Port-Of: odoo/enterprise#59026
Original PR description
As seen in support tickets, other errors can be raised by PyPDF2 when trying to compute pages count on corrupted files. As we are not going to do any kind of handling and must not crash because of this, we'll simply log and discard any non-exit exception raised. Task-3614532 Forward-Port-Of: odoo/enterprise#59026
The `send as message` macro for the template/clipboard block is only supposed to open and edit the message composer on the target form view, then discard it. The form view does not become dirty because of that. However it has been observed that on some Odoo versions, the form view sometimes becomes dirty (indeterministic factor), which is unrelated to the successful macro operation. Therefore it has been decided to always attempt to discard the form so that the test does not fail no matter
Original PR description
The `send as message` macro for the template/clipboard block is only supposed to open and edit the message composer on the target form view, then discard it. The form view does not become dirty because of that. However it has been observed that on some Odoo versions, the form view sometimes becomes dirty (indeterministic factor), which is unrelated to the successful macro operation. Therefore it has been decided to always attempt to discard the form so that the test does not fail no matter if the view is dirty or not during the test. runbot error 62459 Forward-Port-Of: odoo/enterprise#61705 Forward-Port-Of: odoo/enterprise#61682
Added bold formatting to the header text in the template preview to help users distinguish it from the body text. A new line is added between the header and body text in the template preview for the same reason. Task - 3605612 Forward-Port-Of: odoo/enterprise#59143
Original PR description
Added bold formatting to the header text in the template preview to help users distinguish it from the body text. A new line is added between the header and body text in the template preview for the same reason. Task - 3605612 Forward-Port-Of: odoo/enterprise#59143
Steps to reproduce ================== - Open studio on a form view - Edit something - Click on "Restore default view" => Nothing visually happens and the changes stays Forward-Port-Of: odoo/enterprise#61236 Forward-Port-Of: odoo/enterprise#60009
Original PR description
Steps to reproduce ================== - Open studio on a form view - Edit something - Click on "Restore default view" => Nothing visually happens and the changes stays Forward-Port-Of: odoo/enterprise#61236 Forward-Port-Of: odoo/enterprise#60009
In saas-16.3 we started to use a dedicted field transaction_details on statements [1] instead of the narration fields from `account.move`. 1. Fix the view so that it displays the right field. 2. Move transaction details to the same place regardless of the reconciled status of the transaction, into the dedicated tab. Previously, this transaction details was displayed in the manual operations tab when the statement was not reconciled and in debug mode. When reconciled it was available in
Original PR description
In saas-16.3 we started to use a dedicted field transaction_details on statements [1] instead of the narration fields from `account.move`. 1. Fix the view so that it displays the right field. 2. Move transaction details to the same place regardless of the reconciled status of the transaction, into the dedicated tab. Previously, this transaction details was displayed in the manual operations tab when the statement was not reconciled and in debug mode. When reconciled it was available in a dedicted tab "Transaction Details" (no need to be in debug). [1] https://github.com/odoo/odoofin/blob/17.0/odoofin_proxy/models/odoofin_proxy.py#L315 task-id: 3888162 Forward-Port-Of: odoo/enterprise#61683 Forward-Port-Of: odoo/enterprise#61316
Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714 Forward-Port-Of: odoo/enterprise#61252
Original PR description
Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714 Forward-Port-Of: odoo/enterprise#61252