Odoo Changelog — 2024-07-09

Tuesday, July 9, 2024

44 changes · saas-17.1

Bug Fixes(4)

Resolved issues and error corrections

[FIX] point_of_sale: ensure exact matches for short internal references

Coresaas-17.1point_of_sale

Point of Sale searches now correctly prioritize exact matches for short product references and barcodes. This prevents staff from seeing fuzzy search results when the exact product code exists, making checkout lookup more reliable.

Original PR description

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long.

opw-4029891

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#point of sale#product search#barcodes

[FIX] pos*: correctly set default values for a new partner

PR #172399

Coresaas-17.1l10n_ar_posl10n_pe_pospoint_of_sale

Creating a new customer in Point of Sale now applies default values to the new customer record instead of accidentally changing the existing customer data. This helps avoid incorrect customer information during checkout and in country-specific POS flows for Argentina and Peru.

Original PR description

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners.

Enterprise PR: https://github.com/odoo/enterprise/pull/66310

opw-4042039

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pos#customers#default-values

[FIX] social_demo: invalid date format

PR #64204

Enterprisesaas-17.1social_demo

Demo data in the Social Marketing sample content now uses the correct date format. This prevents an error when creating a CRM lead from an Instagram comment, allowing the expected lead wizard to open.

Original PR description

Steps:
- Install social_demo, crm
- Open social marketing app
- Open instagram ost
- Create a lead from comment

Actual result:
- issue due to the demo data with invalid date format
- demo date is not ISO8601 compliant

Expected result
- Lead wizard is opened

opw-3975423
opw-4019390

Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142

#social marketing#demo data#crm#date format

[FIX] pos*: correctly set default values for a new partner

PR #66310

Enterprisesaas-17.1l10n_cl_edi_posl10n_ec_edi_pos

Creating a new customer in Point of Sale now applies the intended default details to the new customer record instead of altering an existing customer view. This helps avoid incorrect customer information during checkout in affected localizations.

Original PR description

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners.

Related PR: https://github.com/odoo/odoo/pull/172399

opw-4042039

#pos#customers#default-values

Other(40)

Miscellaneous changes

[FW][FIX] mail: preserve letter case and accents when creating channel

PR #172531

Coresaas-17.1mail

Before this commit, when creating a channel from the discuss sidebar, the name of the channel would be transformed to lower case and stripped of accents. This happens because the same cleaned term used for searching gets used to define the name of the new channel. This commit fixes the issue by using the unaltered search term. Before: ![image](https://github.com/odoo/odoo/assets/32620115/c0fb9a31-d8ae-4607-9c14-cd26cda34a0c) After: ![image](https://github.com/odoo/odoo/assets/32620

Original PR description

Before this commit, when creating a channel from the discuss sidebar, the name of the channel would be transformed to lower case and stripped of accents.

This happens because the same cleaned term used for searching gets used to define the name of the new channel.

This commit fixes the issue by using the unaltered search term.

Before:
![image](https://github.com/odoo/odoo/assets/32620115/c0fb9a31-d8ae-4607-9c14-cd26cda34a0c)

After:
![image](https://github.com/odoo/odoo/assets/32620115/58d1480d-3818-4aab-baac-b8617958cf13)

Forward-Port-Of: odoo/odoo#172494

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long. opw-4029891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners. Enterprise PR: https://github.com/odoo/enterprise/pull/66310 opw-4042039 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps: - Install social_demo, crm - Open social marketing app - Open instagram ost - Create a lead from comment Actual result: - issue due to the demo data with invalid date format - demo date is not ISO8601 compliant Expected result - Lead wizard is opened opw-3975423 opw-4019390 Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142

Before this commit, creating a new partner incorrectly wrote the default values into `this.props.partner`. This commit ensures that default values are correctly set for new partners. Related PR: https://github.com/odoo/odoo/pull/172399 opw-4042039

**Steps to reproduce the bug:** - Create a storable product P1. - Create two purchase agreement with the same product and qty=10 - Create and confirm a PO with only the second PO - Try to export both purchase agreements, selecting the one without a PO first and then the other. For the fields to export, choose: Products to purchase/ordered quantities. **Problem**: Sure, here is the corrected version in English: Both lines will show 0 units. When the `_compute_ordered_qty` is called with the first PO requisition line, no purchase order is linked, and therefore the total quantity remains at 0. However, the product is added as a founded line. So, on the second requisition line, even though the total quantity (10) is correctly calculated because a PO is linked, the condition that checks if the product has already been found will be true, and therefore the quantity will be set to 0. https://github.com/odoo/odoo/blob/e7850da5848993e036ab70b731f37005ccd64604/addons/purchase_requisition/models/purchase_requisition.py#L240-L244 opw-[4005265](https://www.odoo.com/web#id=4005265&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#171972 Forward-Port-Of: odoo/odoo#171809

Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania connected with an ANAF account. The full process on what needs to be done is explained in the settings view, in the "Romanian E-Factura" block. Once a token is generated, we'll be able to use it in all of our request to send/fetch/download data to/from ANAF. --- The Full Sending E-Factura Flow (requires access token) - Upload invoice/credit note to SPV -> get "loading ID" - The invoice gets processed by ANAF (State: "sending") - After some time, fetch the invoice using the acquired loading ID. - If processed, there will be 2 kind of answer: "OK" or "NOK" (not ok) - Either way, we will get a "download ID", which we can then use to download the answer. - If "NOK" -> "Error". Read the zip file and display the error message - If "OK" -> "Sent". Save the zip file attachment task-id: 3595436 related enterprise PR: https://github.com/odoo/enterprise/pull/65602 Forward-Port-Of: odoo/odoo#144061

**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'` When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117 This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823 We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered. opw-4028362 Forward-Port-Of: odoo/odoo#172267

Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 In this method, we first try to find the relevant plans: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L103-L107 To do so, we take all existing plans, evaluate them with a score, and take the one with the higher score. Here is the issue: when evaluating *Projects*, since we didn't provide any business domain and since the plan has a company, we assign a 0.5 score to the plan instead of skipping it: https://github.com/odoo/odoo/blob/f17b37b14cad8f353443586cc9c4ecaf86e476da/addons/analytic/models/analytic_plan.py#L310-L319 Which does not make sense as the business domain of *Project* is *Purchase Order* and here the user is dealing with a BoM... As a result, back to `_validate_distribution`, we check the distribution for this plan and realize there isn't any, hence the error: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L115-L117 Solution: BOM: We don't restrict anymore the creation of a BOM. Setting an analytic distribution is only a tool to facilitate the definition of the analytic distribution on the MO but the creation should not be constrained Workcenter: we correct the flowing by specifying the business domain restricting the creation of a workcenter if any relevant rule is present Forward-Port-Of: odoo/odoo#168688

### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is immediate. When the employee took care of the payment, a Bill and a Caba Entry are created because the company still needs to reimburse the employee. ### Suggested fix: Adding a Caba Entry is not necessary since there is no need to record the transaction in a transitional account, sending the transaction in the final Account would also match the use case when using Taxes Based On Invoice. `account_id` is selected between the `cash_basis_transition_account_id` of the tax and the `account_id` of the repartition line depending on the values of `tax_exigibility` and `caba_no_transition_account`. https://github.com/odoo/odoo/blob/0c0f0b58aa49cff1efafcc1d4c5a9091e99f2ff4/addons/account/models/account_tax.py#L640-L642 The latter is a context key and is only used in this check, meaning it is most likely harmless to add it in the context of the method. opw-3946362 Forward-Port-Of: odoo/odoo#172196 Forward-Port-Of: odoo/odoo#169255

**Current behavior:** Lines in an invoice may display a product name incorrectly if they mix arabic/latin characters. **Expected behavior:** These types of product names should respect the RTL syntax if being sent to an Arabic lang partner. **Steps to reproduce:** *Ensure the rtlcss node package is installed and in PATH* 1. Create a Saudi company / switch to a demo one, switch to Arabic language 2. Create a product with the name: `دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة` 3. Create an invoice to a partner with Arabic set as their lang 4. Confirm the invoice -> print it 5. The product name on the PDF has a mal-ordered name **Cause of the issue:** The right-to-left rule of the Arabic language is not getting enforced. There is a secondary bug where certain whitespace-delimited substrings get displayed in a broken, overlapping way. From my no-comprehensive testing, it seems to only happen when there is a sequence in the string where you have some substring ending in a numeral (0-9) followed by a single-space, then another substring that begins with an Arabic alphabet character. **Fix:** When printing an invoice with an arabic partner: 1. Use right-aligned text instead of left 2. Pad single-space breaks between substrings in a product name where the first substring ends with a numeral and the second begins with an alpha char. 3. Add explicit `dir="rtl"` attribute to the display node opw-3971541 Forward-Port-Of: odoo/odoo#169267

### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and confirm an MO using that bom - Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product #### > Invalid Operation: You should provide a lot/serial number for the final product ### Expected behavior: You should be able to validate the operations of the MO without assigning an SN but you should not be able to mark the MO as done without assigning the SN to the final product. Note: if no component were consumed in an operation, the invalid operation would not be raised. ### Cause of the Issue: The invalid operation is raised because of these lines: https://github.com/odoo/enterprise/blob/1b0435a92492d85f28549a207fcdb7224b457c66/mrp_workorder/models/mrp_workorder.py#L433-L434 However, the existence of "self.move_raw_ids" only indicates that a component has to be consumed in this opration rather than the existence of a move requiring a the SN of the final product to be set. ## opw-3987022 Forward-Port-Of: odoo/enterprise#65075

When a user tries to validate an invoice of the refunded order a traceback will occur. Steps to produce: - Install 'l10n_mx_edi_pos' module. - Switch to a company whose country code is 'MX'(Mexico). - Open 'Point of Sale' and New Session. - Select any products > payment > Select payment method > Invoice > Select customer > Validate. - Click on 'Next Order'. - Click on 'Refund and select your order. - Click on refund > payment > Select payment method > Invoice > Validate. - Error will be generated. Traceback on sentry: ``` TypeError: can only concatenate str (not "bool") to str File "odoo/http.py", line 2252, in __call__ response = request._serve_db() File "odoo/http.py", line 1828, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http return self._serve_ir_http(rule, args) File "odoo/http.py", line 1833, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2058, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 740, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 42, in call_button action = self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 34, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 458, in call_kw result = getattr(recs, name)(*args, **kwargs) File "home/odoo/src/enterprise/saas-17.1/l10n_mx_edi_pos/models/pos_order.py", line 108, in action_pos_order_invoice action_values = super().action_pos_order_invoice() File "addons/point_of_sale/models/pos_order.py", line 856, in action_pos_order_invoice res = self._generate_pos_order_invoice() File "addons/point_of_sale/models/pos_order.py", line 873, in _generate_pos_order_invoice move_vals = order._prepare_invoice_vals() File "addons/pos_sale/models/pos_order.py", line 32, in _prepare_invoice_vals invoice_vals = super(PosOrder, self)._prepare_invoice_vals() File "home/odoo/src/enterprise/saas-17.1/l10n_mx_edi_pos/models/pos_order.py", line 150, in _prepare_invoice_vals vals['l10n_mx_edi_cfdi_origin'] = '03|' + self.refunded_order_id.account_move.l10n_mx_edi_cfdi_uuid ``` This is because 'l10n_mx_edi_cfdi_uuid' is empty at [1] and a string concatenate with it. link [1]: https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/l10n_mx_edi_pos/models/pos_order.py#L150 This commit solves the above issue while checking the existence of 'l10n_mx_edi_cfdi_uuid' while creating the invoice for refund_order sentry-4935781389 Forward-Port-Of: odoo/enterprise#62398 Forward-Port-Of: odoo/enterprise#59873

Bug Fixes(4)

[FIX] point_of_sale: ensure exact matches for short internal references

[FIX] pos*: correctly set default values for a new partner

[FIX] social_demo: invalid date format

[FIX] pos*: correctly set default values for a new partner

Other(40)

[FW][FIX] mail: preserve letter case and accents when creating channel

Bug Fixes(4)

[FIX] point_of_sale: ensure exact matches for short internal references

[FIX] pos*: correctly set default values for a new partner

[FIX] social_demo: invalid date format

[FIX] pos*: correctly set default values for a new partner

Other(40)

[FW][FIX] mail: preserve letter case and accents when creating channel

[FW][FIX] l10n_tr: Fix migration script's execution phase

[FW][FIX] web: make error formatting more resilient cross browsers

[FW][IMP] l10n_cz: Basic setup of czech l10n module

[FW][FIX] stock: fix putting partial picking with multiple dest locations

[FW][FIX] website_event: add to calendar button follows secondary button style

[FW][FIX] hr_expense: mandatory plan not matching product category

[FW][IMP] account: Draft restrictions split from button_draft method

[FW][FIX] l10n_es_pos: don't generate pdf for simplified invoices

[FW][FIX] website_sale: multi-company issue on cart creation

[FW][FIX] core: wrong invalid field name in read_group() error message

[FW][FIX] point_of_sale: clear search on new order

[FW][FIX] im_livechat: standardize author name in livechat transcript

[FW][FIX] purchase_requisition: correct compute of PO agreements ordered qty

[FW][FIX] web: Discarding in an x2many form removes the unsaved changes.

[FW][FIX] web: fix pills resizing in weekly calendar view

[FW][FIX] stock: forbid snooze of auto-trigger reordering rules

[FW][IMP] l10n_ro_edi: send CIUS-RO to E-Factura Platform

[FW][FIX] l10n_sa_pos: increase QR code size on receipts

[FW][FIX] purchase: allow vendor to confirm that delivery will be on time

[FW][FIX] portal: format number of due in days

[FW][FIX] stock: fix put in pack several move lines with different picking

[FW][FIX] hr_attendance: fix traceback in attendance kanban view

[FW][FIX] hr_holidays: Fix displaay of the dashboard date picker

[FW][FIX] account: send and print with audit trail

[FW][FIX] mrp_account: adds business domain to bom check analytic

[FW][FIX] hr_expense: record caba taxes on final account

[FW][FIX] Website_sale : Fix add to cart notifications

[FW][FIX] l10n_gcc_invoice: force RTL Arabic partner

[FW][FIX] web: fix closing dynamic placeholder

[FW][IMP] l10n_cz_reports: Added tax report xml export

[FW][IMP] l10n_{be,eu_oss}_reports{,_post_wizard,_prorata}: add prorata to export

[FW][FIX] whatsapp: composer sample values not updated on template change

[FW][FIX] mrp_workorder: force the SN assign only for the final operation

[FW][FIX] timesheet_grid: calculate timesheet reminders at company creation

[FW][MOV] l10n_mx_edi: _with_locked_records to account/company

[FW][IMP] l10n_nl_hr_payroll: Restrict 30% Exemption field to Dutch contracts

[FW][FIX] l10n_mx_edi_pos: prevent TypeError while generate invoice for refund order

[FW][IMP] l10n_mx_edi: Change certificate help message and translations

[FW][FIX] planning: use employee tz for open slot datetimes