Wednesday, October 16, 2024
41 changes · saas-17.4
Enhancements to existing features
Odoo now shows unread messages received while the tab is inactive as a simple number at the start of the browser tab title instead of blinking text. This makes new message alerts easier to notice without being distracting, and it also includes new inbox messages in the count.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/177238 PR above improved showing of new messages in Odoo while being out of focus by showing it in tab title and blinking the text. However this felt too obstructive in practice. This commit removes the blinking part, and instead show the out-of-focus amount of unread messages as a counter as prefix of the tab title. For example, if the action is "Inbox", it shows "(4) Inbox" when there are 4 unread and important messages received while odoo is out-of-focus. Also take new inbox messages into account for the out-of-focus counter. Task-4242524 Inbox contains a single message, 21 messages are posted in a DM. Before  After 
Resolved issues and error corrections
This fix prevents small decimal rounding differences from reducing calculated kit availability by one unit. It helps keep manufacturing availability figures accurate after a prior rounding behavior change.
Original PR description
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the…
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the qty_available with product their is difference come. [Here](https://github.com/odoo/odoo/blob/251ef3edcc7e0894683acb7c69bfa437a024110f/addons/stock/models/product.py#L207) before product record ``qty_avaliable`` (it non stored field and compute) to come like this ``'qty_available': 0.7000000000000001 `` after new changes in ``float_round`` after this [pr](https://github.com/odoo/odoo/pull/152709) in 17.4 value is ``'qty_available': 0.7`` coming like this and after dividing [here](https://github.com/odoo/odoo/blob/913c081a8687d0f2aa6c40faeee9013fa10865db/addons/mrp/models/product.py#L280) with 0.1(qty per kit) becomes like ```py before 0.7000000000000001/0.1 7.0 after 0.7/0.1 6.999999999999999 ``` while taking quotent [here](https://github.com/odoo/odoo/blob/b3d61b372a8cd315f9063b6add634ad194f3341b/addons/mrp/models/product.py#L264) it taking 6 instead of 7 so this difference come and test case failed ``` AssertionError: Lists differ: [[142[456 chars]63, '7'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] != [[142[456 chars]63, '6'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] First differing element 27: [14263, '7'] [14263, '6'] Diff is 15569 characters long. Set self.maxDiff to None to see it. : Invariant check fail ``` for correcting this as discussed here https://github.com/odoo/odoo/pull/152709#issuecomment-2383006955 this fixed is proposed. 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
Miscellaneous changes
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and
Original PR description
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and at the same time gets rid of the trailing spaces. [1] https://github.com/odoo/odoo/commit/7c54acaebe38e47cad25d8a1bbdb430e5bad265d task-3974334 Forward-Port-Of: odoo/odoo#179739
The Point of Sale product logic now uses the intended process for identifying archived product option combinations. This helps keep archived product variants handled consistently and reduces the risk of incorrect product data appearing in POS workflows.
Original PR description
Before this commit, archived combinations were computed using a different method, despite the existence of a specific function designed for this purpose. opw-4261061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores missing colored borders in printed invoice reports, including Chilean invoice layouts. It ensures the PDF printing tool can read the border styling correctly, so customer-facing documents appear complete and professional.
Original PR description
Elements with border class are missing the colored border How to reproduce: With a cl company setup Create an invoice to a CL partner Print invoice Issue: Border of top right element is missing This occurs because wkhtmltopdf is not recognizing the css vars opw-4210167 opw-4211635
This update removes a redundant setup step from web client tests because the router is already started automatically by shared test helpers. It keeps the test suite simpler and reduces the chance of duplicated setup causing confusion, with no expected effect on end users.
Original PR description
Before each test on load_state.test.js and push_state.test.js, the startRouter function is called. This is not necessary, because is already called in : https://github.com/odoo/odoo/blob/3f142f332ef1eb168f91c6a83346c9c28a169aba/addons/web/static/tests/_framework/env_test_helpers.js#L109
Users editing links can now choose a suggested link from the dropdown with the keyboard without accidentally applying the old value. This makes link creation and editing in the web editor more predictable and reduces mistakes when using keyboard navigation.
Original PR description
### Steps to reproduce: - Open the To-do app. - Enter /link and provide a label. - Type / (e.g., /web) in the link dialog to preload available links. - Use the arrow keys to select a link from the dropdown. - Press Enter. - Edit the link again and check the result. ### Description of the issue/feature this PR addresses: Selecting a link from the dropdown with Enter would directly apply the link in the dialog, ignoring the selected dropdown link. ### Desired behavior after PR is merged: Selecting a link from dropdown with Enter now correctly updates the link dialog with the selected link, and pressing Enter again applies the updated link.
This update makes the purchase order portal page easier and safer for partners or implementers to customize. It adds clearer identifiers in the page structure, reducing the risk of fragile custom changes breaking during future updates.
Original PR description
Add some ids to avoid xpaths like "//th[3]" etc. task-4250697
The restaurant appointment demo setup now keeps timezone and duration details hidden by default for table bookings. This makes the sample configuration cleaner and more aligned with the intended customer-facing booking experience.
Original PR description
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the to
Original PR description
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar. Solution: ========= Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image). task-4235140 [1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b Forward-Port-Of: odoo/odoo#183702 Forward-Port-Of: odoo/odoo#182723
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed th
Original PR description
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176618
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of t
Original PR description
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of the tax amount, this creates an issue where the base amount and `amount_untaxed` are different when `tax_calculation_rounding_method` is set to 'round_globally'. (e.g.: 141.45 vs 141.48) ### Fix reasoning: `raw_price` is rounded out if `precision_rounding` is specified to avoid rounding to unit, it will replace all occurences of `price_unit * quantity` in the tax calculation. opw-4136024 Forward-Port-Of: odoo/odoo#179603
Currently, it is not possible to inherit the company selector widget. To modify the behavior of the widget, developers need to create a new one instead of inheriting it, which is not ideal. This commit introduces changes that allow inheriting the company selector widget and also makes it easier to replace or extend the CompanySelector class within the SwitchCompanyMenu. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Currently, it is not possible to inherit the company selector widget. To modify the behavior of the widget, developers need to create a new one instead of inheriting it, which is not ideal. This commit introduces changes that allow inheriting the company selector widget and also makes it easier to replace or extend the CompanySelector class within the SwitchCompanyMenu. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175094
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order for 10 P > *Mark as Todo* * go to the detailed ops for the move * => it auto suggest the sml: pk1, qty = 10 * set the qty on the generated sml to 3 * *add a line* > pick from *WHStock - pk2*: * => this creates the sml: pk2, qty = 7 * set the new sml's package to pk1
Original PR description
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order…
Steps
---
* install `stock`
* from *Settings* > *Stock* activate packages
* create a product P and put 2 packages (pk1, pk2) of 10 units each
in stock (inventory adjustment)
* create a delivery order for 10 P > *Mark as Todo*
* go to the detailed ops for the move
* => it auto suggest the sml: pk1, qty = 10
* set the qty on the generated sml to 3
* *add a line* > pick from *WHStock - pk2*:
* => this creates the sml: pk2, qty = 7
* set the new sml's package to pk1
* => the *Pick From* field doesn't change
* *save*, the second sml's package has been reset to pk2
Cause
---
In the detailed ops we use a dummy `quant_id` field on sml to allow
selecting a quant and carrying some fields values from it to the sml.
But, when the quant was selected, setting the values of the carried
field, will not affect back the quant. And later, because the quant is
set, we use its values instead of the ones the user specified.
Fix
---
Hide the affected fields in the view, so the user cannot attempt to set
them, which would not work. i.e if they want to set the package id they should
do it via the quant dropdown.
opw-4089523
Forward-Port-Of: odoo/odoo#177260Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176599
Original PR description
Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176599
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183809 Forward-Port-Of: odoo/odoo#183321
Original PR description
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183809 Forward-Port-Of: odoo/odoo#183321
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency.
Original PR description
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183182 Forward-Port-Of: odoo/odoo#182799
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183347 Forward-Port-Of: odoo/odoo#182791
Original PR description
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183347 Forward-Port-Of: odoo/odoo#182791
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website > Shop > Add a product to cart > View cart - Pay with Demo > Pay - Click the back button - Apply Coupon code Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5975, in ensure_one _id, = self._ids ValueError: Expected singleto
Original PR description
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website >…
When user tries to apply a discount code in order,
a traceback will appear.
Steps to reproduce the error:
- Install ```website_sale_loyalty```
- Activate ```Demo``` payment provider
- Go to Website > Shop > Add a product to cart > View cart
- Pay with Demo > Pay
- Click the back button
- Apply Coupon code
Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5975, in ensure_one
_id, = self._ids
ValueError: Expected singleton: sale.order()
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2100, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale_loyalty/controllers/main.py", line 17, in pricelist
coupon_status = order._try_apply_code(promo)
File "addons/sale_loyalty/models/sale_order.py", line 1197, in _try_apply_code
self.ensure_one()
File "odoo/models.py", line 5978, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/9a9063a2d1f385b02f8453b766ec225def531d7e/addons/website_sale_loyalty/controllers/main.py#L16
When user clicks the back button and applies the coupon,
```order``` will be empty, So, it will lead to the above traceback.
sentry-5856780654
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#180450Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182837 Forward-Port-Of: odoo/odoo#180029
Original PR description
Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182837 Forward-Port-Of: odoo/odoo#180029
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 ###
Original PR description
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure…
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 #### > A return is created from patner to stock instead of updating the P2 move of the delivery ### Cause of the issue: When the sale order was confirmed the moves created for the delivery were both used the same procurment group and their `procure_method` was set to `make_to_order`. When the purchase order for P2 is cancelled, the delivery move associated with the related sol is cancelled and its `procure_method` is set to `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/purchase_stock/models/purchase.py#L148 Then, when you decrease the qty of the SOL from 0 to 1, a procurement for -1 unit of P2 will be created and run by the `_action_launch_stock_rule`. A negative move will then be created and confirm with a `procure_method`: `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/stock/models/stock_rule.py#L275-L277 Because the `procure_method` used at the creation of the negative move is determined from the `procure_method` of the first move related to the procurement group with a positive qty (here the P1 move): https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 As such, the negative P2 move will have a different `procure_method` than the positive P2 move and they will not be merged here: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_move.py#L1384 ### Fix: The fix proposed in commit 65d5e7900f41aa7f65159f8f4cdb0c6638eaf8ca and introducing the lines: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 works perfectly fine in most situtations but should considers only the moves related to the procurment group that concerns the same product to also work in the above case. opw-4214369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183362 Forward-Port-Of: odoo/odoo#182802
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where
Original PR description
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where a client had a server action that invoked this function with multiple records at the same tim, and it caused a duplicate document sent. opw-4195392 Forward-Port-Of: odoo/odoo#183060
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
Original PR description
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
Original PR description
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
Original PR description
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181513
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
Original PR description
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
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
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
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#70577
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#71423
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invo
Original PR description
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to…
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invoice. - Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again. - The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX). Cause of the issue: The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py. opw-4212069 Forward-Port-Of: odoo/enterprise#71344
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of t
Original PR description
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of the tax amount, this creates an issue where the base amount and `amount_untaxed` are different when `tax_calculation_rounding_method` is set to 'round_globally'. (e.g.: 141.45 vs 141.48) ### Fix reasoning: `raw_price` is rounded out if `precision_rounding` is specified to avoid rounding to unit, it will replace all occurences of `price_unit * quantity` in the tax calculation. opw-4136024 Forward-Port-Of: odoo/enterprise#71222
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#71825 Forward-Port-Of: odoo/enterprise#69973
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#71825 Forward-Port-Of: odoo/enterprise#69973
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create thread._message_auto_subscribe(create_values, followers_existing_policy='update') File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscr
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```
Forward-Port-Of: odoo/enterprise#71188### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info. ### Steps to reproduce 1. Open runbot install AR and UY modules 2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000 ### Before the PR W
Original PR description
### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the…
### Description
When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info.
### Steps to reproduce
1. Open runbot install AR and UY modules
2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000
### Before the PR
We receive a traceback error
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1783, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1810, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 2014, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/addons/base/models/ir_http.py", line 226, in _dispatch
result = endpoint(**request.params)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 759, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 732, in action_send_and_print
return self._process_send_and_print(
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 666, in _process_send_and_print
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 572, in _generate_invoice_documents
self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/wizards/account_move_send.py", line 59, in _hook_invoice_document_before_pdf_report_render
if errors := invoice._l10n_uy_edi_check_move():
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/models/account_move.py", line 502, in _l10n_uy_edi_check_move
dtype=self.partner_id.l10n_latam_document_type_id.name))
AttributeError: 'res.partner' object has no attribute 'l10n_latam_document_type_id'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2891:163)
at XMLHttpRequest.<anonymous> (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2895:13)
```
This happens because the document type is related to the invoice, the partner actually has identification type field.
### After the PR
Now it shows the proper message telling the message the problem related to the partner configuration so they can fix it before sending EDI invoice
Reference: LATAM 1275 / ADHOC TICKET 81219
Forward-Port-Of: odoo/enterprise#71416Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
Original PR description
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71743 Forward-Port-Of: odoo/enterprise#71682
Original PR description
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71743 Forward-Port-Of: odoo/enterprise#71682
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
Original PR description
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: o
Original PR description
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: odoo/enterprise#71463
Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71859 Forward-Port-Of: odoo/enterprise#71641
Original PR description
Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71859 Forward-Port-Of: odoo/enterprise#71641
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012
Original PR description
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012