Tuesday, June 30, 2026
12 changes · 19.0
New functionality added to Odoo
This pull request continues a learning-focused Odoo tutorial by adding an estate example module with access rules, menus, views, and related business objects. It helps demonstrate how security permissions and user-facing screens are configured in Odoo, with limited expected impact outside the tutorial add-on.
Original PR description
Description of the issue/feature this PR addresses: ngbri tutorial Current behavior before PR: meh Desired behavior after PR is merged: keep on learning --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update adds missing translations to customer- and staff-facing messages across Point of Sale apps. It helps multilingual users see clearer dialogs, errors, warnings, and payment or restaurant messages in their chosen language.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/enterprise/pull/102094 Forward-Port-Of: odoo/odoo#271883 Forward-Port-Of: odoo/odoo#239972
Resolved issues and error corrections
When someone unfollows a mail thread, Odoo no longer suggests that same person as a recipient for the thread. This avoids confusing re-prompts and keeps recipient suggestions aligned with the user's decision to stop following.
Original PR description
### Steps to reproduce: - Open any mail thread in chatter - Click the "Send To" button once - Click "Unfollow" - You will be a suggested recipient ### Cause of Issue: The suggested recipient generation did not filter out the current user. When the user unfollows, `_message_get_suggested_recipients` is called when storing the thread, and since the user is no longer on the followers list, they get added back as a suggested recipient. https://github.com/odoo/odoo/blob/b4c7247ff218fb850fd91af3e2baa726a82d439c/addons/mail/models/models.py#L467-L468 ### Fix: Since followers are excluded from suggested recipient candidates in the mail thread, and the current user should be excluded when they unfollow, the current user is excluded altogether. This means the current user will not be suggested as a recipient again unless they re-follow the record. opw-6122351
This change appears to be a small maintenance update in the Website area, focused on sitemap testing. It helps keep website functionality reliable without introducing noticeable changes for end users.
Original PR description
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 fills in missing translations across Point of Sale screens, dialogs, alerts, and error messages. It helps staff see clearer messages in their language, improving usability and reducing confusion during day-to-day operations.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#121690 Forward-Port-Of: odoo/enterprise#102094
The point-of-sale connection for German fiscal reporting now sends buyer address information only when it actually exists. This avoids sending placeholder values like “N/A,” improving data quality and reducing the chance of rejected or confusing requests.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#121989 Forward-Port-Of: odoo/enterprise#113621
Point of Sale internal note tags now keep their assigned colors instead of being overwritten by a default style. This makes demo and live tag labels easier to distinguish visually, especially in light mode.
Original PR description
Before this commit: ===================== The internal note styling applied a custom background color to all tags, overriding the colors provided by TagsList (o_tag_color_*). As a result, colored tags were displayed with the default background in light mode. After this commit: ====================== The custom background color is applied only to default tags, while tags with an explicit color keep their original TagsList styling. Additionally, demo internal notes were updated with color values to showcase the colored tag behavior. Task:6294250
This fixes two Spanish (Latin America) labels used for customer identification types in Odoo 19. Users will now see the correct local terms “NIF” for VAT and “Pasaporte” for Passport, reducing confusion when managing contacts in Latin American localizations.
Original PR description
In Odoo 19, translations for l10n.latam.identification.type were moved from .po files to inline columns in the CSV data file. The es_419 correction previously applied via es_419.po (VAT → NIF) was…
In Odoo 19, translations for l10n.latam.identification.type were moved from .po files to inline columns in the CSV data file. The es_419 correction previously applied via es_419.po (VAT → NIF) was never ported to the new CSV mechanism, causing "IVA" to reappear. Passport was also missing its es_419 translation.
**Description of the issue/feature this PR addresses:**
In Odoo 17 and 18, the Spanish (es_419) translation of the VAT identification type was corrected from "IVA" to "NIF" (Número de Identificación Fiscal) via the es_419.po file in l10n_latam_base. In Odoo 19, the translation mechanism for this data changed: translations are now stored as name@es_419 columns directly in l10n_latam.identification.type.csv. The correction was never applied to this new file, so the wrong value ("IVA") reappeared. Additionally, the Passport type was missing its es_419 translation entirely.
**Current behavior before PR:**
- In any Odoo 19 instance with a Latin American localization, the identification type dropdown shows "IVA" for the VAT type (es_419 locale).
- The Passport type shows the untranslated English label "Passport" in es_419 locales.
**Desired behavior after PR is merged:**
- The VAT identification type displays "NIF" in es_419 locales.
- The Passport identification type displays "Pasaporte" in es_419 locales.
- Behavior in v17 and v18 is unaffected (different translation mechanism).
**Steps to test the functionality:**
1. On an Odoo 19 instance with l10n_latam_base installed and language es_419 active, go to Contacts → Configuration → Identification Types.
2. Verify that the type with external ID l10n_latam_base.it_vat shows "NIF" (not "IVA").
3. Verify that the type with external ID l10n_latam_base.it_pass shows "Pasaporte" (not "Passport").
4. Open a contact form, set country to Argentina, and confirm the identification type dropdown reflects the corrected labels.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where the activity counter in the chatter could become negative after multiple overdue or due-today activities were completed on the same record. Users now see a more reliable activity count, avoiding confusing dashboard indicators.
Original PR description
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there…
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there activity counter next to the activity clock icon in the top right should be 2 - Click on the activity clock icon in the top right > Notifce the activity counter decreases to 1 - Mark as done both To-Do activites # The problem The activity counter is negative # Cause This issue is due to a desync between the activity counter client side and server side. When clicking on the activity clock icon, the front-end fetches the mail store data from the backend, which is why we see the activity counter decrease. The server computes the activity counter the following way : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457 It searches for up to 1000 activities and group them by the record they are associated to (e.g. a sale.order). Then, for each of these records, if atleast one activity is late or for today, increase the counter by 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509 Essentially, server side, we get a single +1 in the activity counter by record, not by activity On the other hand, client side, we simply add 1 in the activity counter every time a new activity is created. If an activity is deleted, then we remove 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30 https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309 # Proposed solution Both the client and server side logic were edited fairly recently Server side : https://github.com/odoo/odoo/pull/234899 Client side : https://github.com/odoo/odoo/pull/215880 According to experts, the activity counter should count records, not activities, so we should fix the client side but properly doing so would introduce too much complexity. We instead simply prevent the counter from going below 0. opw-6116821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website language selector now adds descriptive text to flag images when flags are shown without nearby language names. This helps screen reader users understand the available language options and gives search engines clearer page context.
Original PR description
Steps to reproduce: 1. Enable the language selector in the website header. 2. Enable the "Inline" and "Flag" options. 3. Inspect the flag images rendered in the inline variant. Issue: Flag images in the list items have an empty `alt=""` attribute in "Flag only" mode, where the flag is the sole visual indicator of the language, making the selector inaccessible to screen readers and providing no context for search crawlers. Expected behavior: Inline + Flag should have a descriptive ALT tag since there is no adjacent text or code to identify the language, the flag is not decorative. opw-6246464 Forward-Port-Of: odoo/odoo#271362
This fix prevents Romanian electronic stock batch rules from being applied in situations where they should not be used. It reduces false errors in automated checks and helps keep stock operations stable for companies outside the Romanian localization scope.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098 Forward-Port-Of: odoo/odoo#271985
When a new file is uploaded in Documents, its available actions now appear right away. This removes the extra step of unselecting and reselecting the file just to access those actions, making file handling faster and smoother.
Original PR description
Bug === When uploading a new file in documents, it's selected, but the actions are not visible (we need to unselect - select the record to see the actions). Task-5408471 Forward-Port-Of: odoo/enterprise#121985 Forward-Port-Of: odoo/enterprise#114770