Thursday, January 6, 2022
23 changes · master
Enhancements to existing features
The eCommerce settings now only allow internal users to be selected as the salesperson for order follow-up. This prevents portal users or other inappropriate accounts from being assigned, reducing configuration mistakes and keeping sales responsibilities with staff users.
Original PR description
### Current behavior Any users (not only internal users, but portal users too) can be selected from the Salesperson field in the Settings. ### Expected behavior Only internal users can be selected. ### Steps - Install eCommerce - Go to Settings > Website category - Find 'Orders Followup' category - Try to pick a salesperson OPW-2709759
This update adjusts the Website Forum guided tours so they continue to work when related helpdesk demo settings change. It helps keep automated checks stable and reduces false failures during validation.
Original PR description
[IMP] website_forum: adapt tours The enterprise module website_helpdesk_forum changes the demo data karma_answer value to 0 for the default Help forum thus breaks the tour. odoo/enterprise#19870 odoo/upgrade#2681 TaskID: 2499623 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
Resolved issues and error corrections
The eCommerce settings now only allow internal users to be selected as the salesperson for order follow-up. This prevents portal or external users from being assigned by mistake, keeping sales responsibilities with the appropriate staff.
Original PR description
### Current behavior Any users (not only internal users, but portal users too) can be selected from the `Salesperson` field in the Settings. ### Expected behavior Only internal users can be selected. ### Steps to reproduce - Install eCommerce - Go to Settings > Website category - Find 'Orders Followup' category - Try to pick a salesperson OPW-2709759
Miscellaneous changes
Description of the issue/feature this PR addresses: Current behavior before PR: amounts QR code are in currency of the invoice Desired behavior after PR is merged: amounts QR code should be in company currency (Saudi Riyal) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81979
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: amounts QR code are in currency of the invoice Desired behavior after PR is merged: amounts QR code should be in company currency (Saudi Riyal) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81979
with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report. odoo/enterprise#21591 Task-2585661 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82152 Forward-Port-Of: odoo/odoo#82086
Original PR description
with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report. odoo/enterprise#21591 Task-2585661 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82152 Forward-Port-Of: odoo/odoo#82086
Description of the issue/feature this PR addresses: In the accounting dashboard, sales and purchase journals in kanban view display a graph of due amounts grouped by week, but the amounts are not always set in the proper week. Current behavior before PR: The amounts in the graph don't match the correct week and are set randomly Desired behavior after PR is merged: The amounts in the graph match the correct week OPW-2702707 -- I confirm I have signed the CLA and read the PR gu
Original PR description
Description of the issue/feature this PR addresses: In the accounting dashboard, sales and purchase journals in kanban view display a graph of due amounts grouped by week, but the amounts are not always set in the proper week. Current behavior before PR: The amounts in the graph don't match the correct week and are set randomly Desired behavior after PR is merged: The amounts in the graph match the correct week OPW-2702707 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#80627
Before this commit, a ValueError would be raised upon receiving a refund notification for a source transaction whose reference was not found in the database. As only ValidationError's are caught by the webhook controller, the acknowledgment string was never returned to Adyen and the endpoint was automatically disabled. This commit adds a check on the existence of the source transaction to allow discarding refund notifications if it is not found. task-2704522 Forward-Port-Of: odoo/odo
Original PR description
Before this commit, a ValueError would be raised upon receiving a refund notification for a source transaction whose reference was not found in the database. As only ValidationError's are caught by the webhook controller, the acknowledgment string was never returned to Adyen and the endpoint was automatically disabled. This commit adds a check on the existence of the source transaction to allow discarding refund notifications if it is not found. task-2704522 Forward-Port-Of: odoo/odoo#80776
### Current behavior Mail body is missing on mailing demo ### Steps to reproduce - Install Email Marketing & Sales - Go to Email Marketing - Select "_Our last promotions, just for you !_" ### Reason mass_mail used to the `body_html` but since this commit (de56e1919d11cc497341f59ef38fb2d756ede7a3) it now shows the `body_arch` field (and `body_html` in debug mode). OPW-2702534 Forward-Port-Of: odoo/odoo#82265
Original PR description
### Current behavior Mail body is missing on mailing demo ### Steps to reproduce - Install Email Marketing & Sales - Go to Email Marketing - Select "_Our last promotions, just for you !_" ### Reason mass_mail used to the `body_html` but since this commit (de56e1919d11cc497341f59ef38fb2d756ede7a3) it now shows the `body_arch` field (and `body_html` in debug mode). OPW-2702534 Forward-Port-Of: odoo/odoo#82265
Steps: - Users > Admin > Acces Rights > Human Resources - Time Off : empty - Time Off > a past day > Time Off Request wizard : - Time Off Type : Sick Time Off - Confirm Issue: - User Error : 'You must have manager rights to modify/validate a time off that already begun' Cause: - When creating the request, attachments are writen onto the record. - Yet the user do not have rights to write in hr_holidays. Fix: - sudo in the compute and inverse methods that write the attachment
Original PR description
Steps: - Users > Admin > Acces Rights > Human Resources - Time Off : empty - Time Off > a past day > Time Off Request wizard : - Time Off Type : Sick Time Off - Confirm Issue: - User Error : 'You must have manager rights to modify/validate a time off that already begun' Cause: - When creating the request, attachments are writen onto the record. - Yet the user do not have rights to write in hr_holidays. Fix: - sudo in the compute and inverse methods that write the attachments. opw-2714597 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#82036
Co-authored-by: rafaelbn <rblasco@moduon.team> 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#82260
Original PR description
Co-authored-by: rafaelbn <rblasco@moduon.team> 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#82260
## [FIX] account: soften duplicate ref constrains The aim of this commit is to allow EDIs to create and save account move even if a supplier reference is duplicated. This is achieved by delaying the moment to which the constrains is triggered. ## Before this commit: A user can only upload a bill once. (xml ubl format for instance) If he needs to upload it a second time, he will be forced to find a workaround. ## After this commit: User will be able to upload as many bill as he want
Original PR description
## [FIX] account: soften duplicate ref constrains The aim of this commit is to allow EDIs to create and save account move even if a supplier reference is duplicated. This is achieved by delaying the moment to which the constrains is triggered. ## Before this commit: A user can only upload a bill once. (xml ubl format for instance) If he needs to upload it a second time, he will be forced to find a workaround. ## After this commit: User will be able to upload as many bill as he wants but will receive a ValidationError when trying to post the invoice if the reference is duplicated. The user will be able to post the bill very easily by changing the reference a bit if he wants to pursue. community-PR: #81748 enterprise-PR: odoo/enterprise#23255 task: #2612299 Forward-Port-Of: odoo/odoo#82261 Forward-Port-Of: odoo/odoo#81748
Suppose a product with several suppliers, all with the same partner. On the purchase order, the product description will always be based on the last supplier To reproduce the issue: 1. Create a vendor V 2. Create a product P: - Type: Storable - In Purchase, add a line L01: - Vendor: V - Vendor Product Name: Name01 - Vendor Product Code: C01 - Quantity: 1 - Price: 10 - In Purchase, add a second line L02: - Vendor: V
Original PR description
Suppose a product with several suppliers, all with the same partner. On the purchase order, the product description will always be based on the last supplier To reproduce the issue: 1. Create a…
Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
Forward-Port-Of: odoo/odoo#82296
Forward-Port-Of: odoo/odoo#82049Current behavior : When sending an invoice by email there was 2 signature in the mail Steps to reproduce : Create an invoice Send it by email Check the mail, there are 2 signatures opw-2703272 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82314 Forward-Port-Of: odoo/odoo#81086
Original PR description
Current behavior : When sending an invoice by email there was 2 signature in the mail Steps to reproduce : Create an invoice Send it by email Check the mail, there are 2 signatures opw-2703272 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82314 Forward-Port-Of: odoo/odoo#81086
After the commit #77895 if _find_delivery_ids_by_lot is calling by lot with lot_path gone flush delivery_by_lot as it's not passed with the calling. issue to reproduce: open lot and serial number with group by category id, and try to unfold category which lot have reproduced lines but not lot is there. steps: https://bit.ly/3qwFmKg ``` 2021-12-28 09:22:14,914 3403132 ERROR 60316_upg odoo.http: Exception during JSON request handling. Traceback (most recent call last): File
Original PR description
After the commit #77895 if _find_delivery_ids_by_lot is calling by lot with lot_path gone flush delivery_by_lot as it's not passed with the calling. issue to reproduce: open lot and serial number…
After the commit #77895 if _find_delivery_ids_by_lot is calling by lot
with lot_path gone flush delivery_by_lot as it's not passed with
the calling.
issue to reproduce:
open lot and serial number with group by category id, and try to
unfold category which lot have reproduced lines but not lot is there.
steps: https://bit.ly/3qwFmKg
```
2021-12-28 09:22:14,914 3403132 ERROR 60316_upg odoo.http: Exception during JSON request handling.
Traceback (most recent call last):
File "/home/hpr/src/odoo/15.0/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 13
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/hpr/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/hpr/src/odoo/15.0/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'stock.production.lot(13,).last_delivery_partner_id'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/hpr/src/odoo/15.0/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 687, in dispatch
result = self._call_function(**self.params)
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 359, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/home/hpr/src/odoo/15.0/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 348, in checked_call
result = self.endpoint(*a, **kw)
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 916, in __call__
return self.method(*args, **kw)
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 535, in response_wrap
response = f(*args, **kw)
File "/home/hpr/src/odoo/15.0/addons/web/controllers/main.py", line 1293, in search_read
return self.do_search_read(model, fields, offset, limit, domain, sort)
File "/home/hpr/src/odoo/15.0/addons/web/controllers/main.py", line 1312, in do_search_read
return Model.web_search_read(domain, fields, offset=offset, limit=limit, order=sort)
File "/home/hpr/src/odoo/15.0/addons/web/models/models.py", line 62, in web_search_read
records = self.search_read(domain, fields, offset=offset, limit=limit, order=order)
File "/home/hpr/src/odoo/15.0/odoo/models.py", line 5036, in search_read
result = records.read(fields, **read_kwargs)
File "/home/hpr/src/odoo/15.0/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/home/hpr/src/odoo/15.0/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/hpr/src/odoo/15.0/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/hpr/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File "/home/hpr/src/odoo/15.0/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/home/hpr/src/odoo/15.0/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/home/hpr/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/hpr/src/odoo/15.0/odoo/models.py", line 4256, in _compute_field_value
getattr(self, field.compute)()
File "/home/hpr/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 124, in _compute_delivery_ids
lot.delivery_ids = delivery_ids_by_lot[lot.id]
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 643, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/home/hpr/src/odoo/15.0/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
KeyError: 369
```
after this commit delivery_by_lot is passed with the present values so,
it'll not fluch in between recursion.
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#81975Steps to reproduce the bug: - Connect as Admin - install stock_account - Go to inventory > Product Variants > choose any product > click on the FORECAST button - Traceback Problem: docs['product_templates'] can be False, so we can't use it to check the user's group: https://github.com/odoo/odoo/blob/15.0/addons/stock/report/report_stock_forecasted.py#L98 Opw-2728473 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo
Original PR description
Steps to reproduce the bug: - Connect as Admin - install stock_account - Go to inventory > Product Variants > choose any product > click on the FORECAST button - Traceback Problem: docs['product_templates'] can be False, so we can't use it to check the user's group: https://github.com/odoo/odoo/blob/15.0/addons/stock/report/report_stock_forecasted.py#L98 Opw-2728473 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82289
When we ack a file for having correctly received the response e.g., the file is deleted on the server and will not have a file key in the reponse, at least before the server itself will have a new response to share. Before, it would traceback, while now, we do nothing. (as we are still waiting) Also, for the batching we had a traceback, because it was possible to have a batching mixing step 1 and step 2, which fails doing invoices.l10n_it_edi_transaction So we added whether there is
Original PR description
When we ack a file for having correctly received the response e.g., the file is deleted on the server and will not have a file key in the reponse, at least before the server itself will have a new response to share. Before, it would traceback, while now, we do nothing. (as we are still waiting) Also, for the batching we had a traceback, because it was possible to have a batching mixing step 1 and step 2, which fails doing invoices.l10n_it_edi_transaction So we added whether there is a tranaction or not in the batch key. opw-2703669 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#82298
Forward-Port-Of: odoo/enterprise#23113
Original PR description
Forward-Port-Of: odoo/enterprise#23113
The old way of fixing dates was making it harder to write tests with values relative to today (needed because of the complexity of the depreciation schedules) By hard setting a date with freezegun, that complexity is removed, at the cost of maybe not detecting some date issues (because we don't test with various dates) Forward-Port-Of: odoo/enterprise#23267
Original PR description
The old way of fixing dates was making it harder to write tests with values relative to today (needed because of the complexity of the depreciation schedules) By hard setting a date with freezegun, that complexity is removed, at the cost of maybe not detecting some date issues (because we don't test with various dates) Forward-Port-Of: odoo/enterprise#23267
Due to the commit "[FIX] account: soften duplicate ref constrains" done in the community repository, the duplicated bill constrains is delayed to the moment the user will try to post the invoice/bill. Therefore, the error raised by the constrains won't occure anymore during the OCR document import which makes this test obsolete. community-PR: odoo/odoo#81748 enterprise-PR: #23255 task: 2612299 Forward-Port-Of: odoo/enterprise#23260 Forward-Port-Of: odoo/enterprise#23255
Original PR description
Due to the commit "[FIX] account: soften duplicate ref constrains" done in the community repository, the duplicated bill constrains is delayed to the moment the user will try to post the invoice/bill. Therefore, the error raised by the constrains won't occure anymore during the OCR document import which makes this test obsolete. community-PR: odoo/odoo#81748 enterprise-PR: #23255 task: 2612299 Forward-Port-Of: odoo/enterprise#23260 Forward-Port-Of: odoo/enterprise#23255
Two bugs here: - When processing a transfer, if the user scans a weight, it may lead to incorrect result due to UoM conversions - When scanning a packaging, the quantity is not updated and an error message is displayed. The scanned packagings are not considered in the code More info in the description of each commit OPW-2705898 Forward-Port-Of: odoo/enterprise#22952
Original PR description
Two bugs here: - When processing a transfer, if the user scans a weight, it may lead to incorrect result due to UoM conversions - When scanning a packaging, the quantity is not updated and an error message is displayed. The scanned packagings are not considered in the code More info in the description of each commit OPW-2705898 Forward-Port-Of: odoo/enterprise#22952
The QR on PDF report for invoice and payment of a CFDI must have the next attributes: 1. URL access to the SAT service that show the data of public version of each CFDI. 2. Fiscal Folio 3. Emitter VAT 4. Receiver VAT 5. CFDI total 6. Last 8 characters of digital stamp (Sello) of CFDI On the refactor of l10n_mx_edi depending account_edi was removed this section that only adds the 8 characters from the Sello: https://github.com/odoo/enterprise/commit/1ccb480b8e95f5702b6fb4e01446d24
Original PR description
The QR on PDF report for invoice and payment of a CFDI must have the next attributes: 1. URL access to the SAT service that show the data of public version of each CFDI. 2. Fiscal Folio 3. Emitter VAT 4. Receiver VAT 5. CFDI total 6. Last 8 characters of digital stamp (Sello) of CFDI On the refactor of l10n_mx_edi depending account_edi was removed this section that only adds the 8 characters from the Sello: https://github.com/odoo/enterprise/commit/1ccb480b8e95f5702b6fb4e01446d24107514550 Forward-Port-Of: odoo/enterprise#22878
…s due Forward-Port-Of: odoo/enterprise#23101 Forward-Port-Of: odoo/enterprise#22979
Original PR description
…s due Forward-Port-Of: odoo/enterprise#23101 Forward-Port-Of: odoo/enterprise#22979
The MX government requires all deliveries to have a CartaPorte XML document sent to the PAC for signing. This module enables the feature to generate and send a CFDI XML for CartaPorte, and the ability to print these details on the Delivery Slip PDF. Since the XML document also requires the distance in KM, this module also has a distance calculator that uses the MapBox API to compute the distance from source address to destination address. Forward-Port-Of: odoo/enterprise#23214 Forward-Port-
Original PR description
The MX government requires all deliveries to have a CartaPorte XML document sent to the PAC for signing. This module enables the feature to generate and send a CFDI XML for CartaPorte, and the ability to print these details on the Delivery Slip PDF. Since the XML document also requires the distance in KM, this module also has a distance calculator that uses the MapBox API to compute the distance from source address to destination address. Forward-Port-Of: odoo/enterprise#23214 Forward-Port-Of: odoo/enterprise#21591