Monday, March 25, 2024
15 changes · master
Enhancements to existing features
The email template actions have been repositioned so users can more clearly save or load templates while composing messages. The update also makes the related autocomplete behavior safer, reducing the chance of interface issues in edge cases.
Original PR description
Align the "Save Template" button on the right. Align the "Load Template" action on the left of the "Save Template" button Remove the icon on the "Save Template" button. Guard the autocompleteContainerRef.el since the autocompleteContainerRef cannot be guaranteed not null. task-3646066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reorganizes how refund line information is stored in the Point of Sale app, keeping it closer to the order where it is used. This simplifies the underlying system structure and reduces unnecessary dependencies, with no expected change to cashier workflows.
Original PR description
lineToRefund is a property that is only used in pos_order, so it makes sense to move it to pos_order. With this change we get rid of the pos_store dependency in the models.
Resolved issues and error corrections
This update fixes an internal issue affecting restaurant Point of Sale and Indian localization features. It ensures these modules follow the current application rules, helping avoid errors or instability during Point of Sale operations.
Original PR description
PoS variable was use in models in localization modules. This is not allowed anymore. This commit fixes the issue.
Miscellaneous changes
Bug: When an irish company without VAT invoices a Norvegian company with a 0% tax, the category of the tax is "K" in the Bis 3 xml, which will raise: "[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48)." Using code "G" would also raise: "[BR-G-02]-An Invoice that c
Original PR description
Bug: When an irish company without VAT invoices a Norvegian company with a 0% tax, the category of the tax is "K" in the Bis 3 xml, which will raise: "[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48)." Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Export outside the EU" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63)." Fix: We should only use "G" or "K" when the supplier has a VAT. If a supplier without a VAT invoices with a 0% tax, we should use the tax category "E" (Exempted). opw-3785810 Forward-Port-Of: odoo/odoo#158549
The Planning demo data now uses safer relative date calculations so sample shifts have valid start and end dates. This prevents demo data from triggering a scheduling date constraint and helps installations load the Planning examples reliably.
Original PR description
Working with relative week days can be surprising, sor instance ```python In [3]: datetime(2024, 3, 23) - relativedelta(weeks=2, weekday=4) Out[3]: datetime.datetime(2024, 3, 15, 0, 0) In [4]: datetime(2024, 3, 23) - relativedelta(weeks=2, weekday=5) Out[4]: datetime.datetime(2024, 3, 9, 0, 0) ``` This is due to the fact that 2024-03-23 is a Saturday (weekday=5), so setting the weekday has no effect, whereas searching for weekday=4 will search for the next day that matches the criterion (Friday), leading in a future date. This was breaking the constraint `planning_slot_check_start_date_lower_end_date`
This update adjusts Point of Sale-related modules to follow the latest internal rules for how sales data is handled. It helps prevent errors in Chilean electronic invoicing for PoS and preparation display workflows after recent platform changes.
Original PR description
PoS variable was use in models in localization modules. This is not allowed anymore. This commit fixes the issue.
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field. - If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main ta
Original PR description
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which…
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field. - If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main tab but changes the visibility attribute of all the instances suit SK-based companies. However this means the field becomes hidden for CZ-based companies (current company). Plus the field is doubled if the current company is a SK-based one. - A similar problem happens if the l10n_sk is installed first and l10n_cz comes after it. Fix: - Remove the invisible attribute so that the Company ID field on the main tab and on Sales and Purchase tab remains untouched and visible whatever the current company's country is. Forward-Port-Of: odoo/odoo#158605
This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display. Forward-Port-Of: odoo/odoo#158453 Forward-Port-Of: odoo/odoo#158083
Original PR description
This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display. Forward-Port-Of: odoo/odoo#158453 Forward-Port-Of: odoo/odoo#158083
In https://github.com/odoo/odoo/pull/126065 we introduced the feature, that blacklists providers. The issue with it, is that even if we only provide email_from once we check it's not blacklisted [1], when we call the super method, email_from is still filled in [2] In order to correct it, we also delete blacklisted mail from msg_dict [1] - https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/hr_recruitment/models/hr_applicant.py#L615-L616 [2] -https://github
Original PR description
In https://github.com/odoo/odoo/pull/126065 we introduced the feature, that blacklists providers. The issue with it, is that even if we only provide email_from once we check it's not blacklisted [1], when we call the super method, email_from is still filled in [2] In order to correct it, we also delete blacklisted mail from msg_dict [1] - https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/hr_recruitment/models/hr_applicant.py#L615-L616 [2] -https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/mail/models/mail_thread.py#L1388-L1390 task-3793345 Forward-Port-Of: odoo/odoo#157107
### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, try to choose a state. - An error arises: `Uncaught Javascript Error > this.rpc is not a function` ### Investigation: - `this.
Original PR description
### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, try to choose a state. - An error arises: `Uncaught Javascript Error > this.rpc is not a function` ### Investigation: - `this.rpc` is no longer used in 17.1. It's `undefined`. opw-3793838 Forward-Port-Of: odoo/odoo#158295
- Create PO - Confirm, delivery and create bill - Confirm and create reverse move via "Add credit note" (Full Refund) - Open portal view of the PO Issue: The credit note payment status display `Waiting Payment` badge instead of `Paid` opw-3806514 Forward-Port-Of: odoo/odoo#158556 Forward-Port-Of: odoo/odoo#158108
Original PR description
- Create PO - Confirm, delivery and create bill - Confirm and create reverse move via "Add credit note" (Full Refund) - Open portal view of the PO Issue: The credit note payment status display `Waiting Payment` badge instead of `Paid` opw-3806514 Forward-Port-Of: odoo/odoo#158556 Forward-Port-Of: odoo/odoo#158108
When the user imports CSV file of a bank statement and the file has an empty date in one of the rows, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Dashboard > Bank > Import Statement - Select a CSV file that has an empty date in one of the rows > Upload Traceback: ``` TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date' File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", l
Original PR description
When the user imports CSV file of a bank statement and the file has an empty date in one of the rows, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Dashboard > Bank >…
When the user imports CSV file of a bank statement and the file has an empty date in one of the rows,
a traceback will appear.
Steps to reproduce the error:
- Go to Accounting > Dashboard > Bank > Import Statement
- Select a CSV file that has an empty date in one of the rows > Upload
Traceback:
```
TypeError: '<' not supported between instances of 'NoneType' and 'datetime.date'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 121, in execute_import
res = super().execute_import(fields, columns, options, dryrun=dryrun)
File "addons/base_import/models/base_import.py", line 1313, in execute_import
input_file_data = self._parse_import_data(input_file_data, import_fields, options)
File "home/odoo/src/enterprise/17.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py", line 68, in _parse_import_data
if dates != sorted(dates):
```
https://github.com/odoo/enterprise/blob/312b4e5df327b25e1678755b24bd27803720cd3d/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L104-L105
Here, When one of the dates is empty, line[index_date] will be None,
So, when it tries to sort dates at "sorted(dates)",
It will lead to above traceback.
sentry-4687473224
Forward-Port-Of: odoo/enterprise#58605
Forward-Port-Of: odoo/enterprise#52019If the departement of the contract template is a parent of the employee's current department, we shouldn't update that value, since contract templates are mostly defined on the super department task-3818437 Forward-Port-Of: odoo/enterprise#59134
Original PR description
If the departement of the contract template is a parent of the employee's current department, we shouldn't update that value, since contract templates are mostly defined on the super department task-3818437 Forward-Port-Of: odoo/enterprise#59134
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have `l10n_mx_edi_cfdi_to_public` to True by default. The tour `test_mx_pos_invoice_previous_order` is failing undeterministically. The tour proceeds as follows: - create an order without partner, and validate it - later, go the list of paid orders, select the last one and invoice it - the list of partne
Original PR description
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have…
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have `l10n_mx_edi_cfdi_to_public` to True by default.
The tour `test_mx_pos_invoice_previous_order` is failing undeterministically. The tour proceeds as follows:
- create an order without partner, and validate it
- later, go the list of paid orders, select the last one and invoice it
- the list of partners opens to allow setting one
- then, a dialog opens to set the `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public`
Currently, we simply select the first partner in the list ("(AR) Exento" if l10n_ar is installed...). When selecting this partner, we trigger the compute which will set a value on `l10n_mx_edi_cfdi_to_public`. Then, we can input `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public` in the dialog. But the values filled in that dialog are not always saved to the database before ending the tour.
This fix uses a new partner to no longer depends on demo data. In addition, we leave the default values in the dialog to make sure the test will not fail no matter if the dialog's values are saved or not in the database (in a proper subsequent fix, we should ensure that we always end the tour after the dialog's values are saved).
runbot build error 60671
Forward-Port-Of: odoo/enterprise#59174The test creates an invoice, then a reversal, then checks the report values on the day of the invoice. But currently, there is no date for the reversal, s o if the invoice is created at 23:59:59 and the reversal at 00:00:01, the reversal won't be in the report values and so, the test will fail. The solution proposed is just to create the reversal at the invoice date Linked to runbot error 59289 Forward-Port-Of: odoo/enterprise#59157 Forward-Port-Of: odoo/enterprise#58644
Original PR description
The test creates an invoice, then a reversal, then checks the report values on the day of the invoice. But currently, there is no date for the reversal, s o if the invoice is created at 23:59:59 and the reversal at 00:00:01, the reversal won't be in the report values and so, the test will fail. The solution proposed is just to create the reversal at the invoice date Linked to runbot error 59289 Forward-Port-Of: odoo/enterprise#59157 Forward-Port-Of: odoo/enterprise#58644