Monday, February 24, 2025
48 changes · 18.0
Enhancements to existing features
The point of sale interface now highlights the More action button when a customer reward is available. This helps cashiers spot loyalty rewards more quickly, making it easier to apply benefits during checkout.
Original PR description
In this commit: === - When a reward is available, the More action button is visually highlighted .
This update improves Odoo's internal unit testing tools, especially the Hoot test framework, so automated tests are more stable, easier to interpret, and less likely to interfere with each other. The changes are limited to test infrastructure, reducing risk for day-to-day product behavior while helping developers catch issues more reliably.
Original PR description
## Pull Request HOOT (PRHOOT) 28 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/78636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The country/state reference data now includes Papua Barat Daya as an official Indonesian province. This helps businesses keep addresses, localization data, and regional records aligned with Indonesia's current administrative structure.
Original PR description
Official Document, [link](https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022) Wikipedia in English, [link](https://en.wikipedia.org/wiki/Southwest_Papua) 
This update keeps journal entries in sync when analytic items are changed or deleted. It helps prevent accounting discrepancies by automatically updating the related analytic distribution, reducing manual corrections and improving financial data reliability.
Original PR description
created a synchronzing function then overrode the write and unlink functions related to the analytic_line so that it calls the synchronization function when someone deletes or modify an account on an analytic item, a discrepency is created on the analytic distribution of the journal item. so a synchronization function had to be implemented to make sure that there is no discrepency when a customer edit or delete the analytic account on an analytic item task-4378407 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
Accounting entries and sales orders now include the customer's country as a field available for custom grouping. This makes it easier for teams to analyze financial and sales data by market or region without extra setup.
Original PR description
Adding a new related field to account_move to be used in Custom Group By. task-4419706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Update es_419 translations for the following modules: - l10n_uy - l10n_latam_invoice_document - l10n_latam_base - l10n_latam_check --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Update es_419 translations for the following modules: - l10n_uy - l10n_latam_invoice_document - l10n_latam_base - l10n_latam_check --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Analytic reporting now includes a date filter based on fiscal years, with the default view showing the current and previous fiscal years. This helps users focus on the most relevant reporting periods without manually adjusting date filters.
Original PR description
This commit introduces a new filter in the analytic reporting view, which filters dates based on the fiscal year and sets the default filter to the current and previous fiscal years. task-4453226 linked:https://github.com/odoo/odoo/pull/194983
Resolved issues and error corrections
A notice was added for combo products on the website when prices are configured to include VAT. This helps shoppers understand that taxes may not be shown on combo product prices upfront, but they will still be calculated correctly during checkout.
Original PR description
**Issue:** When the website is configured to display prices VAT included, combo products incorrectly show their prices VAT excluded. **Steps to Reproduce:** - in website setting check tax included of `Display Product Prices` - Sales > Products > Products - Create a new product of type "Combo" and set a price - click on go to website The price displayed on the website is VAT excluded, even though VAT inclusion is configured. To address this issue, a disclaimer has been added to inform users that while taxes are not displayed for combo products, they will be properly calculated during checkout. opw-4454112
Miscellaneous changes
Before this commit, searching emoji required at least 2 chars. There is no reason to not allow 1 char, especially when searching some emoji that are best found with a single char, e.g. "9️⃣" with "9". Forward-Port-Of: odoo/odoo#198759
Original PR description
Before this commit, searching emoji required at least 2 chars. There is no reason to not allow 1 char, especially when searching some emoji that are best found with a single char, e.g. "9️⃣" with "9". Forward-Port-Of: odoo/odoo#198759
This fixes a crash in the HTML editor that could happen when attempting to delete embedded component data that was not actually present. The editor now safely ignores this no-op situation, improving stability for users editing embedded content.
Original PR description
Issue: Deleting a non-existing property in the embeddedState of an EmbeddedComponent would produce a traceback. Expected: If no embeddedState snapshot was done (previousEmbeddedState is null), it means that no effective change was performed, and in that case `changeState` should return early to prevent the traceback. task-4600079
This fixes how tax subtotals are calculated on accounting documents. Subtotals now build from the untaxed amount plus earlier taxes, making displayed totals more consistent and easier to understand.
Original PR description
The first subtotal is always the untaxed amount of the document. All following subtotals are just the previous one plus the previous taxes. So the subtotal no longer depend of the taxes under it. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes intermittent failures in the two-factor authentication test flow. The change helps keep automated checks stable so releases are less likely to be delayed by false errors.
Original PR description
Following https://github.com/odoo/odoo/pull/196980 There is still a few non-deterministic errors in auth_totp modules We will assume that the issue cause is the same thus solving them in the same way. Note: None of them were able to be reproduced more easily by toggling the browser CPU rb-135125,135120,135113
The sample payload shown for webhook server actions has been corrected to match the actual data sent when the action runs. This helps users configure and test webhook integrations with more accurate example information.
Original PR description
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PayPal payments no longer fail when started by guests or PoS sessions that use the public user. The payment request now avoids sending missing customer email data and uses the company country code when needed, preventing malformed PayPal payloads.
Original PR description
When making a payment from the PoS, the user would always be the Public User. This would cause the payload sent to paypal to be incorrect and the payment to fail. This happens because we are trying…
When making a payment from the PoS, the user would always be the Public User. This would cause the payload sent to paypal to be incorrect and the payment to fail. This happens because we are trying to make a payment without any user, so this can be reproduced in other workflows. Like making a donation Steps to reproduce: ------------------- * Setup paypal payment provider * Create a PoS payment method with the paypal provider * Create a PoS order and pay with the paypal payment method > Observation: You get an error saying that something is malformed Alternative steps to reproduce: -------------------------------- * Make sure you are not connected on Odoo * Go to the `donation/pay` url * Fill out the form and make the payment via paypal > Observation: You get an error saying that something is malformed Why the fix: ------------ When using the public user, we cannot provide an email address or a country code. To fix this we make sure to not send the email address at all when there is none available. And we send the country code of the company instead of none. opw-4446219
Point of Sale product searches now find items when staff enter only part of an internal reference, rather than requiring the full exact code. This makes checkout product lookup faster and reduces missed search results when users know only part of a reference.
Original PR description
Currently searching with the reference requires to enter the full reference to find the product Steps to reproduce: ------------------- * Modify the Acoustic bloc screen product with an internal reference as TEST_01 * Open pos session * Search TEST > Observation: The Acoustic bloc screen is not in the result Why the fix: ------------ We don't require the `default_code` to be an exactMatch anymore, we make it an inclusion matching. opw-4587548
This fixes an intermittent issue where guest users could sometimes see a blank or missing Discuss conversation if the page loaded slowly. The change makes the public Discuss page wait and update correctly, improving reliability for users accessing shared conversations.
Original PR description
Before this PR, the `discuss_channel_as_guest_tour` would sometimes fail. Discuss is displayed once the thread is restored. However, one patch removes the `useState` from the store of the component, which leads to the `hasRestoredThread` flag not being observed. If `restoreDiscussThread` is too slow to execute, no render occur, no thread is displayed. This PR fixes the issue. runbot-106455 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 fixes an eCommerce product page issue where customers could see both “Add to cart” and “Contact Us” after selecting a product option that makes a zero-priced product sellable. The page now shows the appropriate purchase option, reducing customer confusion and improving the shopping flow.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Prevent Sale of Zero Priced Product; 2. have a product with attributes; 3. set its list price to 0; 4. add a price extra to one of its attributes; 5. go to its eCommerce page; 6. select the price extra attribute. Issue ----- Both the "Add to cart" and "Contact Us" buttons are shown. Cause ----- - Commit 8f4c8ada7e9fe refactored the `website_sale.product` template, moving the "Contact Us" button outside of the `div.js_product` element. - This element gets passed as `$parent` to the `_onChangeCombination` method, which ought to handle these changes. - Because the `#contact_us_wrapper` is no longer in `$parent`, it fails to find it and change its classes accordingly. Solution -------- Instead of querying for the `#contact_us_wrapper` element directly in `$parent`, look for the `#product_details` element first, then query it. opw-4423323
The online store add-to-cart snippets now correctly read true/false settings instead of treating every value as enabled. This ensures quantity options appear only when intended, including outside standard product pages, reducing customer confusion during shopping.
Original PR description
We forgot to parse a boolean which was stored as a string so it was always considered true (both the strings `'true'` and `'false'` evaluate to `true` in a boolean context. This change also fixes the `showQuantity` computation in the product and combo configurators (the computation assumed the user was on the product page, which isn't necessarily the case for "add to cart" snippets).
This fixes a test issue around recalculating allocated hours on project tasks when timesheet-related behavior is overridden. It helps ensure the timesheet and project task logic is validated correctly, reducing the risk of incorrect hour allocation handling.
Original PR description
In this PR https://github.com/odoo/enterprise/pull/78465 the test is failing because it is not taking the override into account as it is not a post_install. opw-4192775
Images in the HTML editor now keep their resized dimensions after using the transform option. This prevents images from jumping back to their original size or shifting position when rotated, making content editing more reliable.
Original PR description
### Steps to Reproduce: - Open the To-Do App. - Upload an image (e.g., `/image`). - Resize the image to 25%, 50%, or 100%. - Click the `Transform` button in the toolbar. ### Approach: - Initially,…
### Steps to Reproduce: - Open the To-Do App. - Upload an image (e.g., `/image`). - Resize the image to 25%, 50%, or 100%. - Click the `Transform` button in the toolbar. ### Approach: - Initially, `this.transfo.settings.style = this.image.style` created a shared reference to the same `CSSStyleDeclaration` object, meaning changes to one were reflected in both. - Later, when `this.image.style = settings.style` was executed, the inline styles were lost because it reassigned the same reference instead of copying the styles individually, resulting in properties like `width` being reset. ### Description of the issue/feature this PR addresses: - Resizing an image (e.g., 25%, 50%, or 100%) would revert it to its original size after clicking the `Transform` button. - Rotating the image would cause it to be misplaced. ### Desired behavior after PR is merged: - The image retains its resized dimensions after transformation. - The image remains correctly positioned during rotation. task-4251410
Recruitment users can now update interviewers for multiple applications at the same time without triggering an error. This makes bulk editing in the Applications list more reliable and avoids interruptions for HR teams managing candidate records.
Original PR description
Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view. Step to produce: - Install the `hr_recruitment` module. - Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them. `ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)` The error occurs because the system attempts to access a single value from multiple records at [1]. Link [1]: https://github.com/odoo/odoo/blob/f1637a10db2f34ca3a272792079115e0192489f8/addons/hr_recruitment/models/hr_applicant.py#L384-L385 To resolve this issue, Use an iteration(for loop) to process each record one by one. Sentry-6229305438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the internal test setup for Odoo Discuss display properly when simulating multiple browser tabs. It helps developers verify cross-tab behavior more reliably, reducing the chance of issues reaching users.
Original PR description
Discuss test helpers provide an `asTab` parameter to mount two main clients, simulating odoo being opened in two different tabs and a dropdown is available to switch from one view to the other. However, height is not propagated to the parent div. As a result, discuss components are invisible, as height is not working properly. This PR ensures the parent div is properly configured, allowing to see discuss UI. 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
The editor toolbar now appears in the correct place when users select all content in right-to-left text. This improves editing reliability for languages that read right to left and avoids a confusing misplaced toolbar.
Original PR description
**Problem**: When selecting all content with `Ctrl+A`, the main `o_editable` element is selected, which has an `ltr` direction by default. If we switch the direction while having a single `rtl`…
**Problem**: When selecting all content with `Ctrl+A`, the main `o_editable` element is selected, which has an `ltr` direction by default. If we switch the direction while having a single `rtl` paragraph, the toolbar appears on the left instead of above the text. **Solution**: When `Ctrl+A` is used (selection is on `o_editable`), use deep position on the container edges. This simulates the browser’s default `Ctrl+A` behavior. **Example**: content: `<div contenteditable=true><p>tex[]t</p></div>` Existing Ctrl+A: `<div contenteditable=true>[<p>text</p>]</div>` New Ctrl+A: `<div contenteditable=true><p>[text]</p></div>` Default Ctrl+A (done by browser): `<div contenteditable=true><p>[text]</p></div>` **Steps to reproduce**: 1. Add some text. 2. Switch the text direction to `rtl`. 3. Press `Ctrl+A`. 4. The toolbar appears on the left instead of above the text. opw-4557762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where installing the Chilean localization caused the Document Number field to appear on invoices for other Latin American localizations, such as Uruguay. After the change, the field remains visible where needed for Chilean invoices without affecting Uruguayan electronic invoices.
Original PR description
Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl…
Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl is modifying the visibility of the field "Document number" to appear when necessary directly on latam_invoice_document view. This make that the field visibility is being changed on other localizations as well when you have both installed. Current behavior before PR: The "Document Number" field below "Document Type" should is present on uruguayan electronic invoices (where it should not be). Desired behavior after PR is merged: The "Document Number" field is present on chilean invoices as expected and not in uruguayan electronic invoices. Steps to reproduce the error: - Install l10n_uy - On the UY company, go to Customer/Invoices section, create one, select a customer and check that you have an electronic journal selected. The field "Document Number" should not be present. - Install l10n_cl - Go to the previously created invoice and check that the field "Document Number" now appears. Ticket ADHOC side: 86491 Ticket Odoo side: 4505977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Message notification icons in the Mail app now look more subtle and respond visually when users hover over them, making it clearer that they can be clicked. Notifications with labels also have improved sizing and weight, so they read more consistently as buttons while failed notifications stand out better.
Original PR description
Before this commit, style of message notification icon (e.g. envelope) was not subtle enough. Intent was to use `text-600`, but due to typo this was not actually used (was `NaN` so does nothing). Also this wasn't clear this button is clickable, due to lack of moouse hover feedback. This commit fixes the issue by having an opacity change on mouse hover. When there's a failure, the static opacity is lower so that failed notifications are a bit more noticeable. Also message notification with label had slightly improper style that make them less look like a button: buttons should have a bit of font weight, and also the label was too big compared to icon. This commit also fixes that issue. Before  After 
This update improves and repairs internal automated tests for several Odoo Enterprise areas, including appointments, timesheets, and the mobile/web interface. It helps ensure future changes can be validated more reliably while keeping the impact limited to testing infrastructure rather than day-to-day user features.
Original PR description
## Pull Request HOOT (PRHOOT) 28 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/189710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how UPS delivery log messages are displayed by removing unsupported formatting inside translated text. It helps ensure users see clear, readable messages instead of broken or confusing HTML-style text.
Original PR description
HTML code in log messages does not work this way: `In Odoo 18, the _() function is used for translating strings and supports placeholders for variables. However, it does not support HTML tags such as <br/> or <b>.` 
Fixed an issue that prevented sales users from opening the commission pivot view. The commission achievement rate can now be aggregated correctly, avoiding the error and restoring access to reporting.
Original PR description
**Problem:** The problematic PR is this one : https://github.com/odoo/enterprise/pull/78537 This fix caused the pivot view to be inaccessible, creating a traceback, because the field 'achieved_rate' needs to be able to be aggregated. The line that removed the aggregator that was added was the new problem. https://github.com/odoo/enterprise/blob/137b233d4990ea9f48c8aa5b6a3990dc4170356b/sale_commission/report/commission_report.py#L19 **Steps to reproduce:** - Go to commissions in the sales app - Click on the pivot view - The traceback will appear **Fix:** Change the aggregator from None to the default one. opw-4512739
The sales commissions pivot view now opens without an error. Commission achievement rates are averaged when results are grouped, giving users a meaningful aggregated view of performance.
Original PR description
**Problem:** This is a reverse and improvement of a previous fix. The first PR is this one : https://github.com/odoo/enterprise/pull/78537 This fix caused the pivot view to be inaccessible, creating a traceback, because the field 'achieved_rate' needs to be able to be aggregated. The line that removed the aggregator that was added was the new problem. https://github.com/odoo/enterprise/blob/137b233d4990ea9f48c8aa5b6a3990dc4170356b/sale_commission/report/commission_report.py#L19 **Steps to reproduce:** - Go to commissions in the sales app - Click on the pivot view - The traceback will appear **Fix:** Change the aggregator from None to 'avg' to pick the average of the achieved_rate in case of a group by. opw-4512739
This fix prevents upgrade processes from creating duplicate demo document access records in the Documents and Project integration. It avoids setup or upgrade errors while keeping normal demo data loading behavior unchanged.
Original PR description
The upgrade script might create document access records that match the demo loaded from the data file, triggering a unique constraint record. Marking them as not forcecreate solves the issue and doesn't affect the normal behaviour of loading demo data. See: https://runbot.odoo.com/runbot/build/71461439
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because
Original PR description
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that…
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because we tried to sort records on a field that is unknown. 2) if it wasn't the first field of the order, e.g. `default_order="x,y"` but y wasn't in the view: the changes done in the dialog were lost, so it was no possible to edit records. Both issues had the same root cause. After the edition, we tried to sort the relation (as the order might have changed). We do that since [1], but it wasn't the main purpose of this commit. It has been done because it looked like a quick win at the time, and we thought it was a good idea. However, functionally speaking, sorting the records after the edition isn't wanted. If I just clicked on a record, edited it, I expect the record to remain where it was after closing the dialog. So as sorting isn't necessarily wanted, and it even produces issues in some cases, this commit reverts that "feature". [1] https://github.com/odoo/odoo/commit/17e198153ecfd9c5c32b3b22f43e2f1b8100a1c3 Closes #197867 opw-4499150 (case (2)) 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#198918 Forward-Port-Of: odoo/odoo#198757
At some point, servers started to return `image/svg+xml; charset=utf-8` instead of `image/svg+xml` in the `content-type` header of SVG images. Because of this, dynamic SVGs were not properly handled anymore. This commit adapts the mimetype comparisons to cope for this extra `charset` info inside the mimetype. Steps to reproduce: - Drop an image block inside a website page. - Replace the image. - Search for e.g. "city". - Pick an undraw illustration. => The image was lost because its
Original PR description
At some point, servers started to return `image/svg+xml; charset=utf-8` instead of `image/svg+xml` in the `content-type` header of SVG images. Because of this, dynamic SVGs were not properly handled anymore. This commit adapts the mimetype comparisons to cope for this extra `charset` info inside the mimetype. Steps to reproduce: - Drop an image block inside a website page. - Replace the image. - Search for e.g. "city". - Pick an undraw illustration. => The image was lost because its `src` became `false`. Forward-Port-Of: odoo/odoo#198267
Add "(copy)" to the name of the duplicated payment term. task-4227445 Forward-Port-Of: odoo/odoo#198913 Forward-Port-Of: odoo/odoo#197605
Original PR description
Add "(copy)" to the name of the duplicated payment term. task-4227445 Forward-Port-Of: odoo/odoo#198913 Forward-Port-Of: odoo/odoo#197605
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was invited to more than one event. - At least one of them was going to be notified in the future. - Google cancelled the first of those. <details> ``` 2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`. 2024-12-1
Original PR description
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was…
Description of the issue/feature this PR addresses:
allow portal attendees to be synced by google calendar
Current behavior before PR:
There was an `AccessError` happening when:
- One portal user was invited to more than one event.
- At least one of them was going to be notified in the future.
- Google cancelled the first of those.
<details>
```
2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`.
2024-12-11 10:19:02,151 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(29,)
2024-12-11 10:19:02,539 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-12-11 10:19:03,029 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(50,)
2024-12-11 10:19:03,414 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(40,)
2024-12-11 10:19:03,823 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(52,)
2024-12-11 10:19:04,219 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(10,)
2024-12-11 10:19:04,580 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(28,)
2024-12-11 10:19:04,936 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(2,)
2024-12-11 10:19:05,501 31 INFO odoo odoo.models.unlink: User #2 deleted mail.message records with IDs: [1055490, 1055487, 1055480, 1055478, 1055403]
2024-12-11 10:19:05,518 31 INFO odoo odoo.models.unlink: User #2 deleted calendar.event records with IDs: [2920874, 2920875, 2920880]
2024-12-11 10:19:05,520 31 INFO odoo odoo.models.unlink: User #2 deleted mail.followers records with IDs: [6232226, 6232227, 6232228, 6232229, 6232230, 6232231, 6232232, 6232233, 6232234, 6232235, 6232236, 6232237, 6232238, 6232239, 6232240, 6232241, 6232242, 6232243, 6232270, 6232271, 6232272, 6232283]
2024-12-11 10:19:05,544 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario. !
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 997, in get
cache_value = field_cache[record._ids[0]]
KeyError: 8
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 1004, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.alarm(8,).alarm_type'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 79, in _sync_google_calendar
synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
cancelled_odoo._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/calendar.py", line 326, in _cancel
super(Meeting, my_cancelled_records)._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 152, in _cancel
self.unlink()
File "/opt/odoo/auto/addons/calendar/models/calendar_event.py", line 721, in unlink
self.env['calendar.alarm_manager']._notify_next_alarm(partner_ids)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 242, in _notify_next_alarm
notif = self.with_user(user).with_context(allowed_company_ids=user.company_ids.ids).get_next_notif()
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 210, in get_next_notif
last_found = self.do_check_alarm_for_one_date(in_date_format, meeting, max_delta, time_limit, 'notification', after=partner.calendar_last_notif_ack)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 130, in do_check_alarm_for_one_date
if alarm.alarm_type != alarm_type:
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1189, in __get__
record._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
2024-12-11 10:19:05,547 31 INFO odoo odoo.addons.base.models.ir_cron: Job `Google Calendar: sincronización` done.
```
</details>
Desired behavior after PR is merged:
Google Sync works.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@moduon MT-8345
cc @arj-odoo
Forward-Port-Of: odoo/odoo#190708
Forward-Port-Of: odoo/odoo#190356Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196813 Forward-Port-Of: odoo/odoo#173010
Original PR description
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196813 Forward-Port-Of: odoo/odoo#173010
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
Original PR description
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal
Original PR description
Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal dashboard view due to missing access After this commit: The Accounting module and journal dashboard view work correctly for non-admin users Reproducing the issue in Runbot: https://drive.google.com/file/d/1YIjvoXNDe6atVyzWC1dVU58rDFnoYH7x/view?usp=drive_link opw-4551932 Forward-Port-Of: odoo/odoo#197520
We add the variable msg_id and references to the test mail template MAIL_EML_ATTACHMENT to allow to use it as a response to another mail. We also add "subject" to allow to use test-related subject. Task-3707821 Forward-Port-Of: odoo/odoo#154332
Original PR description
We add the variable msg_id and references to the test mail template MAIL_EML_ATTACHMENT to allow to use it as a response to another mail. We also add "subject" to allow to use test-related subject. Task-3707821 Forward-Port-Of: odoo/odoo#154332
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Internal, New - Add an operation - Change the location and destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move #### Error: the location and destination location of the stock move are still the initia
Original PR description
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable…
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Internal, New - Add an operation - Change the location and destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move #### Error: the location and destination location of the stock move are still the initial ones. ### Cause of the issue: The onchange method `_onchange_locations` of the "stock.picking" model: https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/stock/models/stock_picking.py#L825-L836 has been removed in saas-17.2 byt the push pull refactror: 11e69870db1c49d9a6af79ffd263e4e162b34b6b However, it should not have been for the "location_id" since it was not replaced by any other mechanic and it has been replaced by a compute method for the "location_dest_id": https://github.com/odoo/odoo/blob/5a61e440232b119f712ff9545ec3e535210bbb94/addons/stock/models/stock_move.py#L200-L201 However, this compute method is not triggered in the above flow for the following reason: On the picking model, there are two fields that contain the stock moves: https://github.com/odoo/odoo/blob/17a63a6cda41a44e3d4ff8b5a9042e93ba956bc8/addons/stock/models/stock_picking.py#L612-L614 Where `move_ids_without_packages` is a subset of `move_ids` When editing the operations of a picking, we are actually dealing with the field `move_ids_without_packages`. So, when changing the locations of the picking, the webclient sends the SMs via the field `move_ids_without_packages`, i.e.: the web client does not provide any value for `move_ids`. Server side, when creating a `new` record based on the provided values, we will handle the inverse of `move_ids_without_packages`, i.e.: we will make sure that the stock moves have the field `picking_id` correctly defined: https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L6366-L6374 **But** we don't define any value for the siblings of the field. It means that we don't set any value for the field `move_ids`. This will lead to the bug: later on in the onchange, we flag all fields that will have to be recomputed: https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L983 And here we would hope that the field `location_dest_id` of the stock moves will be flagged, as mentioned in the dependencies: https://github.com/odoo/odoo/blob/68ae97bd27fbdc874922e03f52f8b0c7953df801/addons/stock/models/stock_move.py#L206-L207 But... In `_modified_triggers`, at some point, we are here https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L7200-L7203 Where `field` is `stock.move.picking_id`. So, we iterate on the inverse field of `field`, i.e.: `move_ids` and `move_ids_without_packages`. However, as explicitly mentioned in the comment, we "use an inverse of field without domain", i.e.: `move_ids`. We therefore read the value of this field on the picking which is, because of the bug explained in the previous paragraph, an empty record. As a result, the ORM considers that it does not have to recompute any `location_dest_id`. The ORM team is aware of the issue. They have tried to write a generic solution (cf PR [191318](https://github.com/odoo/odoo/pull/191318)) but it led to a lot of other errors. So, the issue has been considered as a limitation and added to a todo list on their side. In the meantime, it is possible to patch the issue with a stock-specific fix. Note: the issue will also happen when editing an existing picking. Suppose a picking with one move SM01. The user adds a second move SM02, does not save and edits the destination location of the picking: for the same reasons, the ORM will only see SM01 and, therefore, will call the compute method for SM01 only. Contains a backport of 22e17e513e9d0309a832e27ee10f89a96688d905 Co-authored-by: "Adrien Widart (awt)" <awt@odoo.com> opw-4491101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198504
Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198719
Original PR description
Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198719
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t
Original PR description
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. opw-3993305 Forward-Port-Of: odoo/odoo#178315 Forward-Port-Of: odoo/odoo#174950
This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#79863 Forward-Port-Of: odoo/enterprise#77578
Original PR description
This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#79863 Forward-Port-Of: odoo/enterprise#77578
These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79347 Forward-Port-Of: odoo/enterprise#79200
Original PR description
These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79347 Forward-Port-Of: odoo/enterprise#79200
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours - Change the start or end date of the task - Notice allocated hours didn't change ### Current behavior before PR: This is happening because we are supposed to only compute the allocated hours when the task is getting created and after this we don't re-calculate it but the user can edit i
Original PR description
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours -…
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours - Change the start or end date of the task - Notice allocated hours didn't change ### Current behavior before PR: This is happening because we are supposed to only compute the allocated hours when the task is getting created and after this we don't re-calculate it but the user can edit it manually but if the 'Timesheets' option is false the allocated hours won't be shown in any form to be edited so only if the 'Timesheets' option is deactivated for the project we should re-compute the allocated hours ### Desired behavior after PR is merged: Add another condition where if the project allows timesheets we don't re-compute the allocated hours field if it doesn't allow timesheets we re-compute it. opw-4192775 Forward-Port-Of: odoo/enterprise#74528 Forward-Port-Of: odoo/enterprise#71681
[FIX] documents: fix documents creation on documents 1. Fix reply with an attachment on message from existing document How to reproduce: - Go to the chatter of a document - Add yourself as a follower - Send a message from the chatter: you should receive an email - Reply to this email with an attachment You receive a delivery error message ("Address not found") and your reply doesn't appear in the chatter, nor your attachment. With this fix, the message with its attachment appears
Original PR description
[FIX] documents: fix documents creation on documents 1. Fix reply with an attachment on message from existing document How to reproduce: - Go to the chatter of a document - Add yourself as a follower…
[FIX] documents: fix documents creation on documents
1. Fix reply with an attachment on message from existing document
How to reproduce:
- Go to the chatter of a document
- Add yourself as a follower
- Send a message from the chatter: you should receive an email
- Reply to this email with an attachment
You receive a delivery error message ("Address not found") and your reply doesn't appear in the chatter, nor your attachment.
With this fix, the message with its attachment appears in the chatter and there is no delivery error message.
2. Fix sending a message with an attachment on a request
How to reproduce:
- Go to the chatter of a request
- Send a message with an attachment from its chatter
You get the error "The operation cannot be completed: This attachment is already a document." while the message with its attachment should be added in the chatter.
With this fix, the message with its attachment appears in the chatter and the request remains to be fulfilled.
3. Error while uploading a requested document through activity popover
How to reproduce:
- As user A, create a requested document for User B
- As user B, click on the activity of that request and upload a document
You get the error "The operation cannot be completed: This attachment is already a document." while the uploaded file should be linked to the request.
With this fix, the request is fulfilled, and you get no error.
We solve those problems by not creating document by default when messages with attachments are posted on a document and delegate the creation of the documents to the _message_post_after_hook method for the case of a post on a folder alias. We have chosen that default behavior as in all uses case except the alias, we expect the attachment to be added to the chatter and not as a new document.
TestMailGateway already tests that incoming mail with attachment on an alias create the related documents, and we introduce a test for each case described above in other commits.
[IMP] documents: add a test on replying with an attachment on a document post
We add a test that check that when answering a mail posted on a document with an attachment, that the attachment is added to the document and the message is posted on the document.
We also modify slightly an existing test because a parameter given to _message_post_after_hook was incorrect.
[IMP] documents: add a test on document type change when sending a message
We add a test that check that when sending a message on a URL or a request document, it is not turned into a binary document.
[IMP] documents: add a test that upload a document in the activity popover
We add a test that upload requested document through activity popover.
Task-3707821
Forward-Port-Of: odoo/enterprise#78951
Forward-Port-Of: odoo/enterprise#56779Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial
Original PR description
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test opw-3993305 Forward-Port-Of: odoo/enterprise#68949 Forward-Port-Of: odoo/enterprise#67589
### Before this commit: When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget. ### After this commit: - When there are one or multiple budget line records in a budget, the form view of that budget will be opened. **task-4195738** Forward-Port-Of: odoo/enterprise#73799
Original PR description
### Before this commit: When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget. ### After this commit: - When there are one or multiple budget line records in a budget, the form view of that budget will be opened. **task-4195738** Forward-Port-Of: odoo/enterprise#73799
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#78013
Original PR description
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#78013