Odoo Changelog — 2024-10-29

Tuesday, October 29, 2024

36 changes · saas-17.4

Bug Fixes(1)

Resolved issues and error corrections

[FIX] point_of_sale: synchronize cashier info on order and receipt

Coresaas-17.4point_of_salepos_hr

This fixes a point of sale issue where changing the cashier after adding products could leave the order linked to the previous cashier while the receipt showed the current one. Orders and printed receipts now show the same cashier, reducing confusion in sales records and staff accountability.

Original PR description

Before this commit, adding a product to an order and then changing the cashier would not update the cashier information on the captured order, resulting in the previous cashier being recorded. However, the printed receipt would display the current cashier, leading to inconsistency.

opw-4257705

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

#pos#cashier#receipt#orders

Other(35)

Miscellaneous changes

[FW][FIX] account: fix balance / amount_currency sync during write

PR #185757

Coresaas-17.4account

Original PR description

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#185619
Forward-Port-Of: odoo/odoo#171705

Before this commit, adding a product to an order and then changing the cashier would not update the cashier information on the captured order, resulting in the previous cashier being recorded. However, the printed receipt would display the current cashier, leading to inconsistency. opw-4257705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The issue is the syncing (function `_sync_invoice`) between - amount in currency (document currency; field `amount_currency`) and - balance (company currency; field `balance`). There we update the amount in currency in case the balance is changed and the amount in currency is not changed. But this is problematic in case we want (in the same write) set a different amount in currency but explicitly set the same balance (and not just not write anything to the `balance` field). Since we write the same balance it is not detected as a change and we update the balance based on the amount in currency. But this should not happen; the balance should be "protected" from being updated (since it is the value we explicitly want). This can i.e. cause the balance of the receivable line to receive the wrong value I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below) Journal Items: - product 1: amount in currency = -1000.00 €, balance = -500.00 - product 2: amount in currency = -200.00 €, balance = -100.00 - tax line 1: amount in currency = -180.03 €, balance = -90.02 - tax line 2: amount in currency = -30.00 €, balance = -15.00 - Receivable: amount in currency = -1410.03 €, balance = 705.02 And we modify tax line 2: amount in currency = -29.99 €. Then first we set the correct values because we basically compute the receivable line by summing the other lines: Journal Items: - product 1: amount in currency = -1000.00 €, balance = -500.00 - product 2: amount in currency = -200.00 €, balance = -100.00 - tax line 1: amount in currency = -180.03 €, balance = -90.02 - tax line 2: amount in currency = -29.99 €, balance = -15.00 - Receivable: amount in currency = -1410.02 €, balance = 705.02 So we have set the balance to the same as before but changed the amount in currency. So then we recompute the balance on the receivable line from the amount in currency due to the syncing (`_sync_invoice`) Journal Items: - product 1: amount in currency = -1000.00 €, balance = -500.00 - product 2: amount in currency = -200.00 €, balance = -100.00 - tax line 1: amount in currency = -180.03 €, balance = -90.02 - tax line 2: amount in currency = -29.99 €, balance = -15.00 - Receivable: amount in currency = -1410.02 €, balance = 705.01 But now the move is not balanced (the sum of the balances should be 0) -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01) After this commit we "protect" the balance and amount in currency from being updated by `_sync_invoice` in case the surrounding `write` sets the balance (`balance`) or amount in currency (`amount_currency`) respectively. Reproduce: (c.f. example above) 1. Select company "My Company (San Francisco)" 2. Ensure EUR currency is activated and has value 2 unit per USD (at the time of the invoice that will be created further below) 3. Copy the 15% tax 4. Create a new invoice in EUR with 2 lines (1) qty = 1, unit price = 1000, taxes = 15% (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy) 5. There should be 2 tax lines in the "Journal Items" tab (1) amount in currency = -180.00 €, credit = 90.00 USD (2) amount in currency = -30.00 €, credit = 90.00 USD 6. Modify tax line (1); set amount in currency to -180.03 € and save. The credit will be updated to 90.02 USD. 7. Modify tax line (2); set amount in currency to -29.99 € and try to save 8. An "Invalid Operation" error is raised: The move (Draft Invoice ) is not balanced. The total of debits equals $ 705.01 and the total of credits equals $ 705.02. Forward-Port-Of: odoo/odoo#185619 Forward-Port-Of: odoo/odoo#171705

This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix. Based on Real World™️ evidence. Description of the issue/feature this PR addresses: <details> ``` odoo-1 | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property: ! odoo-1 | Traceback (most recent call last): odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 100, in _sync_all_google_calendar odoo-1 | user.with_user(user).sudo()._sync_google_calendar(google) odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 78, in _sync_google_calendar odoo-1 | synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences) odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[google_sync.py](https://google_sync.py/)", line 202, in _sync_google2odoo odoo-1 | odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals) odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[calendar_recurrence_rule.py](https://calendar_recurrence_rule.py/)", line 86, in _write_from_google odoo-1 | current_parsed_rrule = self._rrule_parse(current_rrule, self.dtstart) odoo-1 | File "/opt/odoo/auto/addons/calendar/models/[calendar_recurrence.py](https://calendar_recurrence.py/)", line 375, in _rrule_parse odoo-1 | rule = rrule.rrulestr(rule_str, dtstart=date_start) odoo-1 | File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1730, in __call__ odoo-1 | return self._parse_rfc(s, **kwargs) odoo-1 | File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1698, in _parse_rfc odoo-1 | raise ValueError("unsupported property: "+name) odoo-1 | ValueError: unsupported property: ``` </details> Current behavior before PR: Odoo stops sync of users calendars as long as they have one event with an RRULE like this. Desired behavior after PR is merged: Odoo keeps working. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-7215 Forward-Port-Of: odoo/odoo#185089

Currently, an exception is generated when the user tries to open the UTM link by following steps. - Install 'website_links' (for creating a link tracker). - Go to Link Tracker > New > Fill all details - Set the target URL as 'http://localhost:8069/odoo' - Copy Tracked URL > Open url in incognito mode or new browser error: `ValueError: Expected singleton: res.users()` This is because when we open this type of link, the code line [1] tries to set a cookie, and since we have not logged in (not even have a dummy user) at the time of checking, the method `has_group` generate an error from line [2] because `self(user)` is required. In the previous version, the `has_group` method did not require self, but after a code refactor with https://github.com/odoo/odoo/commit/cb31d4352c741a5f8a927a65debb8e027e87df22#diff-16e37db365c1ea1f2e6c79aeb60c80f68f1a5c75970e8e3f198eb18af56278ddL1037-L1043, it needed a record in self. This commit will fix the above issue by allowing cookie when its type is required or the request environment has user. [1]- https://github.com/odoo/odoo/blob/871d20d8ffb00737fe8192223385cdad69fe12e1/addons/utm/models/ir_http.py#L21 [2]- https://github.com/odoo/odoo/blob/871d20d8ffb00737fe8192223385cdad69fe12e1/odoo/addons/base/models/res_users.py#L1133 sentry-5281961509 Forward-Port-Of: odoo/odoo#184733

This pr is created to help de user to know the origin of the afip error 10016. The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client. 1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-1': 'The invoice date cannot be after the last invoice validated in AFIP.' 2) If the last afip invoice number is higher than the current invoice number being validated in Odoo, then the message shown to the user is '10016-2': 'There may have been a mismatch in the numbering of this type of document between Odoo and AFIP.' 3) If any other reason cause the error '10016' then the message shown to the user is: * Please note that if you are trying to validate an invoice with a date other than today, you must verify if it falls within the date range according to the AFIP concept or document type: a) If it is Product: N+5 or N-5 with N being today's date. b) If it is Services or Products and services: N+10 or N-10 with N being today's date. c) If it is a MiPyme Invoice: N-5 0 N+1 with N being today's date. For Debit Note or Credit Note only N-5" Task Adhoc side: 37771 Task latam side: 1194 This pr replaces https://github.com/odoo/enterprise/pull/65675 Forward-Port-Of: odoo/enterprise#72733 Forward-Port-Of: odoo/enterprise#72656

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of lines that are shown. When this limit is reached, we just don't display the exceeding lines, and replace them by a summary line. To avoid confusion, a warning is now shown on top of the report when some lines need to be hidden. Since such a warning requires a module update (because it's a template, and needs to exist in db), we only apply our new trimming mechanism if the warning template exists (and can hence be displayed). This way, we won't change the behavior on existing databases without being sure the user is properly notified. Plus, thanks to that, we're sure the old load_more_limit value (originally 80 by default) set on the VAT Book will have been increased to a value fitting our use case more, so we won't bother people with excessive trimming. Original fix suggestion raised here by Adhoc: https://github.com/odoo/enterprise/pull/45936 Forward-Port-Of: odoo/enterprise#72727 Forward-Port-Of: odoo/enterprise#72096

To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to: - Make it a variant of the Generic BS - Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplicate you made in 3). 7) Unfold both levels of the Receivable line. ====> Prefix groups aren't used, while the number of move lines reaches the threshold value. This happens because the variant is opened from the Generic BS. So, options have first been generated and kept in the session for the Generic BS. When openin the variant, it receives the previously generated options as previous_options, and restores the threshold originally defined on the Generic BS. We don't want to restore the threshold for previous options, so we just remove that code and now always initialize it to the value contained in the apporpriate field when computing the options. Forward-Port-Of: odoo/enterprise#72822

Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will return 0 and The month should be between 1 and 12, so it will raise an error. - While calculating the start_date and end_date of the monthly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.quarter), year=int(record.year))` If there is no quarter, then int(record.quarter) will return 0 and The month should be between 1 and 12, so it will raise an error. After this commit: - The start_date and end_date will not be calculated if a month or quarter is not defined for the monthly or quarterly return periods. Traceback - https://pastebin.com/LyKUDrH5 Task-4243468 Forward-Port-Of: odoo/enterprise#72815 Forward-Port-Of: odoo/enterprise#71883

Bug Fixes(1)

[FIX] point_of_sale: synchronize cashier info on order and receipt

Other(35)

[FW][FIX] account: fix balance / amount_currency sync during write

Bug Fixes(1)

[FIX] point_of_sale: synchronize cashier info on order and receipt

Other(35)

[FW][FIX] account: fix balance / amount_currency sync during write

[FW][PERF] stock: lower limit for report_stock_quantity

[FW][FIX] mail: url attachment breaks breadcrumbs

[FW][FIX] mail: translated image actions + zoom-in cursor

[FW] 17.0 pypdf trixie compat moc

[FW][FIX] calendar: X-named params without RRULE prefix

[FW][FIX] website: allow empty default value for model select fields

[FW][FIX] web: keep nosheet style if a sheet is present in a nested form

[FW][FIX] base, tools: consider icons in is_html_empty

[FW][FIX] l10n_ug: fix account type

[FW][FIX] mrp: unlink archived operations from byproducts

[FW][FIX] hr_holidays : cache issues

[FW][IMP] purchase: purchase representative is now buyer

[FW][FIX] mail: do not show push notif request in iOS

[FW][FIX] product: pricelist import duplication issue

[FW][FIX] stock: add default value to Selection fields

[FW][FIX] mrp_{subcontracting_dropshipping,account}: use comp qty in price unit calc

[FW][FIX] mail : UTF-8 text/* attachment and omitted charset

[FW][FIX] point_of_sale: fix iot box rename script

[FW][FIX] base: allow cookies when it is required or has a user in env

[FW][FIX] l10n_fr_hr_payroll: revert translation of salay rule codes

[FW][FIX] hr_contract_salary: Avoid erasing existing user name

[FW][FIX] l10n_*_reports*: remove 'countries' info from manifest

[FW] 17.0 pypdf trixie compat moc

[FW][IMP] l10n_ar_edi: manage 10016 afip error.

[FW][IMP] l10n_ar_reports: VAT Book: use load_more_limit

[FW][FIX] account_reports: Aged Receivable/Payable: properly check 0-balanced elements in storno accounting

[FW][FIX] account_reports: Don't restore prefix_groups_threshold from previous options

[FW][FIX] l10n_in_reports_gstr: fix traceback when not selecting month in gst return

[FW][FIX] data_merge: handle non-stored company field

[FW][FIX] l10n_mx_reports: use correct XSLT for COA SAT (XML)

[FW][DRAFT][FIX] web_studio: previous button appears in right direction

[FW][FIX] account_{batch_payment,sepa,sepa_direct_debit}: fix sanitize_communication

[FW][FIX] documents: inspector behavior in mobile

[FW][FIX] {documents}_account: fixed onboarding tour

[FW][FIX] l10n__reports: remove 'countries' info from manifest