Daily updates from Odoo
Monday, July 13, 2026
29 changes · 18.0
New functionality added to Odoo
Adds the required Latvian VAT report attachments and an XML export so businesses can prepare and submit more complete VAT reporting from Odoo. The update covers detailed domestic, EU purchase, domestic sales/export, and EU sales transaction breakdowns, including special handling for small transactions and partial deductible bases.
Original PR description
This commit adds 4 attachments to the Latvian tax report and an XML export for the tax report (including the attachments). The attachments are the following - PVN 1-I: domestic purchase / import -…
This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).
The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale
The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
independently of the move
- 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
- There is max 1 line per partner
- 'T': All small transactions that are not grouped under some 'V' line
- There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
(like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
- All transactions with (document) type 'X' are aggregated on a single line
- Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
(like PVN 1-I)
- The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
- No aggregation is performed here
Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.
The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.
task-4251184This update introduces new tax reporting capabilities for Latvia, specifically adding 'car tax' and 'representation tax' with associated VAT deduction rules. It also standardizes tax report attachment tagging for improved transaction type determination, impacting how VAT is processed.
Original PR description
#### [IMP] l10n_lv: add tax report attachment tags Add tags for the tax report attachments added in the related enterprise PR and tag all existing taxes. They determine the transaction type. It also adds the special tag `Rep` that is irrelevant for the transaction type. From a base amount line tagged with `Rep` we only put 40% of the amount for the attachments. #### [IMP] l10n_lv: add a car and a representation purchase tax This commit adds 2 new taxes - "car tax": 50% of the VAT is deductible - "representation tax": 40% of the VAT is deductible #### references task-4251184
Enhancements to existing features
This update improves the performance and reliability of our website's image galleries by upgrading the Owl library to version 2.8.4. Specifically, it fixes a bug that prevented the loss of rendered images and adds support for running Owl with Node.js, enhancing flexibility.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details 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#275568
Resolved issues and error corrections
This fix ensures cached payroll rule parameters are safely copied before use, preventing one calculation from accidentally changing values used by another. It reduces the risk of hard-to-trace payroll calculation issues and improves reliability for payroll processing.
Original PR description
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc. It could lead to very obscure bugs such as: ```python def…
Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.
It could lead to very obscure bugs such as:
```python
def some_innocent_code():
category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
incapacity_codes = category_dict['partial_incapacity']
incapacity_codes |= category_dict['total_incapacity']
# ... then use incapacity_codes
def print_rule_param():
print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])
print_rule_param() # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param() # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```
The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.
task-6329380This fix prevents internal deferred accounting dates from being imported or exported on Colombian electronic invoice lines. It avoids exposing vendor revenue recognition information to customers and keeps invoice data focused on relevant billing details.
Original PR description
The current implementation of the Peppol XML export incorrectly populates the cac:InvoicePeriod nodes on line level with internal deferred entry dates. These dates are intended for the vendor's revenue recognition process, and the customer has nothing to do with these dates. This PR ensures that: - deferred entries are never created when importing vendor bills. - cac:InvoicePeriod is no longer exported in invoice lines (for now). Part of the task-6014315 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
The POS Avatax integration now calculates taxes for normal in-store sales without requiring a customer, using the company location as the sale location. It also preserves the exact tax amounts returned by Avatax so customers are charged correctly, especially when external tax calculations differ from Odoo's internal estimates.
Original PR description
This module has never worked in a stable release. It was broken two days after it was merged by the removal of replaceDataByKey [1]. On top of that, the module behaves in an unexpected way: - Tax is…
This module has never worked in a stable release. It was broken two days after it was merged by the removal of replaceDataByKey [1]. On top of that, the module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders. We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes: - Stop requiring a customer to be selected, - Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config, - Fix a bug where price_subtotal is not multiplied by quantity, - Removes copy/pasted code from sale.order that serves no purpose, This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations. The module also doesn't handle the biggest challenge regarding external taxes: tax amounts Odoo calculates are not guaranteed to be the same as the ones returned by Avatax. There have been many fixes regarding this in other modules [2]. The summary of the situation is that the tax percentage returned by external tax calculators is only informational, and will not always be the "actual" tax percentage charged. Only the $ amount is authoritative. Differences can occur due to rounding, or due to automatically applied (partial) exemptions. The added test simulates this by deliberately misconfiguring a tax percentage amount. Before this fix the POS would charge the wrong amounts in the above case. This commit adds a hacky mechanism that "freezes" tax amounts returned by Avatax and displays them as-is, bypassing the machinery that calculates taxes in JS. When a line is modified the amounts are unfrozen. Note that in the case described above (Odoo taxes != Avatax taxes) the session closing entry won't be balanced. In this case the session must be force-closed with `pos.close.session.wizard`. It's not possible to fix this like we do for `l10n_br_edi_pos`, because we don't store the amounts per tax. A tour test was added to make sure the module keeps working. [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f [2] d941074434a0, a9783b107df2, b65308d67584 task-4676595
Event communications now prevent users from creating or editing WhatsApp templates from the event mailing field. This avoids choosing an incompatible template model that could later show an access error and reflects the stricter approval requirements for WhatsApp templates.
Original PR description
Issue: User goes to Event.event Form -> communication tab -> add line Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add a patch to the js get m2oProps to deactivate edit, and create on the prop. WA Templates need more limitations for creation and edits due to the approval process from META's external API. We cannot block the full creation and edit in the xml becuase other event.mail types rely on that flow to create their types like social posts. This was a fix implemented due to needing to revert the oginal fix odoo/odoo@f58e9f97192ac0ff8d159377494d6c68f871d20b opw-6334168
Email links for appointments now use the website tied to the appointment instead of another website visited by the user. This prevents customers on multi-website setups from being sent to the wrong site when managing their bookings.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369 Forward-Port-Of: odoo/enterprise#122669
This update resolves an issue where dragging tables in the HTML editor caused layout problems. Now, tables can be seamlessly dropped and pasted, maintaining their original formatting and functionality, ensuring a smoother editing experience.
Original PR description
**Current behavior before PR:** - Dragging and dropping a selected table caused the layout of the dropped table to become broken. **Desired behavior after PR is merged:** - Now, dragging and dropping a selected table now maintains the table's layout, ensuring that the entire table is dropped without any layout issues. task:4138408
This update fixes an issue where pressing 'Enter' within a code block nested in a list would incorrectly create a new list item. Now, 'Enter' will simply add a new line within the existing code block, providing a smoother and more intuitive editing experience for code snippets.
Original PR description
Current behavior before PR: - When the cursor was placed within the text of a code block that was a child of a list, pressing enter create a new list item containing a code block. Desired behavior after PR is merged: - Now, if the cursor is positioned within the text of a code block that was child of a list, pressing enter will insert a new line within the code block instead of creating a new list item. task:4240721
This update addresses a technical issue where a report was failing when analytic plans were not available. The fix ensures the system gracefully handles missing plans, preventing errors and maintaining data accuracy. This resolves a previously reported problem (OPW-6383774, OPW-6383787) and improves report stability.
Original PR description
After this commit 403d9d7, current_plans is being used to get the column name but not always have a analytic plan. To fix this issue we review if is empty or not. OPW-6383774 OPW-6383787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the DSO (Days Sales Outstanding) data on the Invoice Dashboard was misaligned. The problem stemmed from a discrepancy in how fiscal years were handled, leading to inaccurate reporting. This change ensures the DSO data accurately reflects invoice performance.
Original PR description
Invoice dashboard data, specifically DSO, was incorrectly aligned due to a mismatch in the fiscal year structure. Task-6049887
This update corrects a crash that occurred when the system attempted to merge partners using UUID-formatted access tokens. The fix ensures the system correctly handles both the older numeric partner ID format and the newer UUID format, preventing errors and improving stability.
Original PR description
The SQL query in _update_foreign_keys was casting access_token to integer unconditionally, but website_visitor.access_token is a Char field that uses two formats: - Legacy: partner_id stored as a numeric string (e.g. '105249') - Current: 32-char UUID hex string (e.g. 'b0dd4bfd041f4b42957357ba7e067dda') The ::int cast raises InvalidTextRepresentation on UUID-format tokens. Fix: guard the cast with a regex so only rows with numeric access_tokens are processed; UUID-format rows are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a technical issue where an empty distribution model could cause errors. The fix prevents unnecessary merging of these models, streamlining the system and avoiding potential problems. This improves the stability and efficiency of the analytic accounting features.
Original PR description
It is possible to have an empty distribution model, there is therefore ne need to merge it, especially since it raises when doing this ```python self.env['account.analytic.plan'].mapped(lambda p: p._column_name()) ```
This update corrects a technical issue where some users were unable to access certain elements within the partner view due to inconsistent access rights. The fix ensures all users, regardless of their group membership, can properly interact with the relevant features. This improves overall system usability and prevents potential data access problems.
Original PR description
This PR fixes the following warning (similar ones with different XMLID) which occurred during system update. ``` WARNING ? odoo.addons.base.models.ir_ui_view: <b>Access Rights…
This PR fixes the following warning (similar ones with different XMLID) which occurred during system update.
```
WARNING ? odoo.addons.base.models.ir_ui_view: <b>Access Rights Inconsistency</b><br/>This view may not work for all users: some users may have a combination of
groups where the elements <b><tt><button></tt></b> are displayed, but they depend on the field <b><tt>loyalty_card_count</tt></b> that is not accessible. You might fix this by mo
difying user groups to make sure that all users who have access to those elements also have access to the field, typically via group implications. Alternatively, you could adjust the “<
i>groups</i>” or “<i>invisible</i>” attributes for these fields, to make sure they are always available together.<br/>Debugging information:<br/>- field “loyalty_card_count” is accessib
le for groups: 'base.group_user'<br/>- element “<button name="action_view_loyalty_cards" type="object" class="oe_stat_button" icon="fa-money"
groups="base.group_system,sales_team.group_sale_salesman" invisible="loyalty_card_count == 0"/>” is shown in the view for groups: ('base.group_portal' & &
#39;base.group_system') | ('base.group_public' & 'base.group_system') | ('base.group_system' & 'base.group_user') | ('base.group_system&#
39; & 'base.group_partner_manager') | 'sales_team.group_sale_salesman'
View error context:
{'file': '/tmp/addons/account_invoice_import_simple_pdf/views/res_partner.xml',
'line': 1,
'name': 'res.partner form',
'view': ir.ui.view(15203,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(15202,),
'xmlid': 'view_partner_property_form_move'}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a technical issue in the Odoo accounting system that could have caused errors during payment processing. The fix ensures the system correctly identifies the 'company' record instead of the 'self' record, preventing potential errors and improving payment reliability. This resolves a minor bug impacting financial transactions.
Original PR description
This commit https://github.com/odoo/odoo/commit/f54d6918d8ef5aa143e63b7dc79e8c3e3d8583f8 introduced a bug, calling _get_batch_payment_sequence_values on self instead of company triggering possible ensure_one exception if self is not one company.
During checkout, users experienced a frustrating issue where the 'Save Address' button would get stuck in a loading state when navigating back to the address form. This was caused by the browser's cache incorrectly preserving a disabled button state. This update ensures the button is correctly reset, providing a smooth and reliable checkout experience.
Original PR description
When the address form is submitted, the button is disabled and a spinner is shown while the POST is in flight. On success, redirect() is called, which schedules a navigation via location.assign()…
When the address form is submitted, the button is disabled and a spinner is shown while the POST is in flight. On success, redirect() is called, which schedules a navigation via location.assign() asynchronously. The browser's bfcache can snapshot the page at this point — while the button is still disabled — and restore that snapshot when the user presses back, leaving the button stuck in the loading state. Fix: re-enable the button and remove the spinner before branching on result.redirectUrl so bfcache always captures a clean button state. In Odoo master this was fixed implicitly by PR odoo/odoo#201730 (commit 1d79eddc62a0), which refactored the widget to use the Interaction class with makeButtonHandler(), which always restores the button after the handler's promise resolves. Description of the issue/feature this PR addresses: Current behavior before PR: During checkout, when pressing the return arrow to go back into the address editing panel, the "Save Address" button gets stuck in loading forever. Desired behavior after PR is merged: The "Save Address" button is shown normal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that was preventing batch payments from processing correctly. The fix corrects a faulty call within the Odoo system, ensuring that payment sequences initialize properly. This improves the reliability of batch payment operations.
Original PR description
Fix a wrong call to self breaking ensure_one 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
This update adjusts Dominican Republic (l10n_do) income tax withholding rates to comply with Law 30-26, effective July 1st, 2026. The standard rate for service fees and rentals has increased from 10% to 15%, reflecting new tax regulations. This ensures accurate tax reporting for Dominican businesses using Odoo.
Original PR description
## Description Law no. 30-26 of June 18, 2026 (art. 17) amended article 309 of the Dominican Tax Code. Effective **July 1st, 2026**: - The income tax (ISR) withholding on fees, commissions and other…
## Description
Law no. 30-26 of June 18, 2026 (art. 17) amended article 309 of the Dominican Tax Code. Effective **July 1st, 2026**:
- The income tax (ISR) withholding on fees, commissions and other remunerations for services rendered by individuals not in a dependency relationship is raised from **10% to 15%** (payment on account).
- The ISR withholding on rentals of movable and immovable property paid to individuals is raised from **10% to 15%** (now a definitive payment).
Official references:
- Amended article 309 CT (art. 17 of the law): "a) 15% *(antes 10%)* ... alquiler o arrendamiento ... provistos por personas físicas ... pago único y definitivo; b) 15% *(antes 10%)* sobre los honorarios, comisiones y demás remuneraciones y pagos por la prestación de servicios en general provistos por personas físicas, no ejecutados en relación de dependencia ... pago a cuenta."
- Law 30-26 at the Ministry of Finance: https://www.hacienda.gob.do/marco-legal/ley-no-30-26/
- PwC summary quoting the new art. 309 scale ("15%, previously 10%"): https://www.pwc.com/ia/es/publicaciones/Noticias-Tax-Legal/Tax-and-legal-2026/modificaciones-Ley-30-26.pdf
- DGII implementation calendar (notice 10-26 — calendar only, the rates are in the law text): https://dgii.gov.do/publicacionesOficiales/avisosInformativos/Documents/2026/10-26.pdf
- DGII confirming the new percentages are in force since 2026-07-01: https://ayuda.dgii.gov.do/conversations/discusiones/retenciones-segun-ley-3026/6a42be2e3365d30845e40234
## Implementation notes
- The existing XML IDs (`ret_10_income_person`, `ret_10_income_rent`) are kept unchanged, so on existing databases the standard chart template reload (`_pre_reload_data`) replaces the outdated 10% taxes through the usual `[old]` renaming mechanism.
- The tax group `tax_group_person_services` labels are updated from "(10%)" to "(15%)" accordingly.
- No other article 309 rates changed for the taxes present in this template (5% government, 10% dividends, 2% N07-07, 27% remittances remain in force).
This is the first contribution by Grupo de Consultoria Henca (https://www.consultoriahenca.com); the corporate CLA signature is included in `doc/cla/corporate/consultoriahenca.md` as instructed by `doc/cla/sign-cla.md`.
## Related PRs
- 17.0: https://github.com/odoo/odoo/pull/275986
- 18.0: https://github.com/odoo/odoo/pull/275987
- 19.0: https://github.com/odoo/odoo/pull/275988This pull request updates the core spreadsheet component within Odoo. It addresses several technical improvements and bug fixes related to spreadsheet functionality, specifically focusing on conditional formatting and internal configuration. These updates ensure the spreadsheet component continues to operate smoothly and reliably.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9183e3668 [REL] 18.0.74 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9183e3668 [REL] 18.0.74 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ec8874600 [FIX] conditional_formatting: handle zero color scale midpoint [Task: 6312961](https://www.odoo.com/odoo/2328/tasks/6312961) https://github.com/odoo/o-spreadsheet/commit/8278af136 [FIX] config: filter-out claude folder from prettier [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update ensures that the Klipy search placeholder now displays "Search KLIPY" as required by Klipy's attribution guidelines. This improves the user experience and maintains compliance with Klipy's documentation. The change was made to align with the platform's integration with Klipy.
Original PR description
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution Forward-Port-Of: odoo/odoo#275677
A recent change blocked users from creating social media posts within event communications. This update removes a restriction that was causing the issue, allowing users to once again add social media posts to event communication templates. The change was initially intended to limit template edits but inadvertently caused broader functionality problems.
Original PR description
Issue: User goes to Event.event Form -> communication tab -> add line - can no longer create a social post in template communication tab Fix: remove "no_create_edit: True" to the associated field in the xml to unblock creation of new mail.templates Reverted from commit (odoo/odoo@f58e9f97192ac0ff8d159377494d6c68f871d20b) due to not being able to make social media posts on event communication tab. I originanlly suggested this change because WA Templates need more limitations for creation and edits. This then blocked other creation and edits that rely on this flow. opw-6334168
This update resolves an issue where activity descriptions weren't consistently appearing in all tabs after duplicating a chat window. The fix removes unnecessary computed fields from activity broadcasts, ensuring descriptions are accurately reflected across all connected tabs. This improves the user experience for sharing and receiving activity updates.
Original PR description
**Steps to reproduce:** - Install Contacts app - Open any record - Go to the chatter - Create an activity with a description - Duplicate the tab - Go back to the initial tab - Description doesn't…
**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab
**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.
Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).
This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```
**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.
(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)
[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6
opw-6247412This update resolves an issue where animated GIFs used within image shapes wouldn't play correctly in Firefox and Safari. The team added a technical workaround to ensure GIFs now function as expected, expanding the usability of image shapes with animated content.
Original PR description
Animated GIFs applied with an image shape freeze on Firefox and Safari when the shape's SVG is otherwise static. A dummy `<animateMotion dur="1ms" repeatCount="indefinite"/>` child on the <image> element keeps the animation running so the GIF plays. This hack was introduced in [1] but was missing from most shapes. This commit adds it to every <image> element that lacked it so any shape can be used with a GIF. task-5967171 [1]: https://github.com/odoo/odoo/commit/144e5ef799060da860a5fb1fbe0fd009919afe79
This update corrects a minor error in the turnstile template that prevented users from consistently controlling the display mode via the ?cf=show parameter. The fix ensures the turnstile appears as intended, resolving a visual inconsistency. This update is a safe forward-port from the 17.0 release.
Original PR description
Stable forward-port source patch. Issue - The turnstile template uses a misspelled variable name in data-appearance: appeareance. - JS provides appearance. - Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode. Fix - Replace appeareance with appearance in the turnstile template. Why stable-safe - One-line template fix. - No API/model/signature changes. - No behavior change outside the intended appearance selection. This is intended as the 17.0 source fix so forward-porting can propagate to upper versions. Related: odoo/odoo#273306 and odoo/odoo#273652 Forward-Port-Of: odoo/odoo#273706
This update fixes a potential issue where loading certificates could cause unexpected errors and crashes in Odoo. By implementing safeguards, the system now gracefully handles malformed certificates, preventing tracebacks and ensuring smoother operation. This improves the overall reliability of certificate management within Odoo.
Original PR description
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 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
This update fixes an issue where event registration emails were directing users to the wrong website. The problem stemmed from a misconfigured base URL, leading to incorrect links. This change ensures that event registration emails now accurately reflect the event's assigned website, improving user experience and event management.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) opw-4146760 opw-4336369 Forward-Port-Of: odoo/odoo#274051
This update fixes a discrepancy in the default tax date obligation for Serbian VAT invoices. Previously, the system defaulted to a 'By Issuance Date' setting, which wasn't compliant with Serbian law. Now, it correctly defaults to 'By Delivery Date' as mandated by Article 16 of the Serbian VAT Law, ensuring accurate tax reporting.
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273608
Features or functions removed from Odoo
This update removes an unnecessary and always-true check within the Odoo POS self-ordering module. The previous code was designed to verify if the self-ordering mode was 'qr_code', but this option is no longer valid. This change streamlines the code and improves efficiency without impacting functionality.
Original PR description
Description of the issue/feature this PR addresses: Removed obsolete code checking "this.config.self_ordering_mode !== 'qr_code'". Since "qr_code" is not a valid value of the "self_ordering_mode" selection field. The condition is always true.