Tuesday, November 12, 2024
70 changes
Enhancements to existing features
Recruitment users can now see and manage activities directly from the applicants list. This makes it easier to create or track activities for multiple applicants at once, improving follow-up efficiency.
Original PR description
It is not possible at the moment to create activity for more than one applicant. This commit adds the activities column to the list view of `hr.applicant` so that it can be possible. task-4316528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the Muk Web Theme package for Odoo 18.0. The available information does not describe specific functional changes, so the business impact appears limited to maintaining or refreshing the theme package.
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
Resolved issues and error corrections
A small typo was corrected in the Live Chat chatbot setup logic. This helps ensure chatbot step information is stored consistently and avoids issues caused by the earlier typo.
Original PR description
This PR fixes a typo introduced by this commit ce0f8d9e608acdcc6fd8495e7b9cd8f7d2757349. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change simplifies the automated tour system that Odoo uses to test user journeys across apps and websites. It makes test flows more predictable by ensuring each step advances in one consistent way, reducing flaky test results and improving release confidence.
Original PR description
Miscellaneous changes
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and m
Original PR description
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like…
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and memory-expensive because the `purchase_id` field is not stored so it needs to compute the relationship for all moves in the expanded ids due to prefetching. Since there exists a Many2many relationship between stock pickings and purchase orders, it's possible to rely on a search query instead of the `mapped` call. Although this might miss some cache optimizations, it's still much more efficient in terms of memory. This is because this approach is not susceptible to prefetch_ids explosion. It's also worth noting that this function is only called on individual stock moves instead of batches as part of the anglo_saxon_accounting logic. That being said, we don't have to worry this much about cache optimization since the method is not batched to begin with. Using this optimization, we get the following benchmarks. Benchmark: | num stock.move (_prefetch_ids) | time before | no. queries before | time after | no. queries after| |----|------|-----| ----- | ----- | | 1000 | timeout | N/A | ~ 85 seconds | 47897 | opw-4096108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181822
Muted mail notifications will now correctly hide the unread indicator. This prevents users from seeing misleading unread markers on conversations they have chosen to mute.
Original PR description
There was `opacity-0` on muted item, but due to `opacity-50` being mistakenly present at all time, it had precedence over the `opacity-0` thus the unread indicator was always visible. 
This fixes an internal automated test so it checks the intended shared behavior rather than only one specific implementation. It helps prevent false test failures when country-specific electronic invoicing extensions add their own data.
Original PR description
Fix a failing test that was incorrectly patching a class method, instead of patching the base object. Indeed, before this fix the test was only patching `account_edi_ubl_cii._get_ubl_cii_formats_info()` and not extensions such as `l10n_ro_edi._get_ubl_cii_formats_info()`). Therefore extensions could add data to the returned value of the method, and could make the test fail. Related runbot error id: 104916 task-no
Invoice document previews now show only the intended sample QR code when SEPA payment QR codes are enabled. This avoids confusing users during the print and send setup by replacing the real generated QR code in the preview instead of adding a second one.
Original PR description
Version: 18.0 Issue: With a valid SEPA bank account enabled, 2 QR codes are generated on the report invoice preview document. This is because we are xpathing to the `qr_code` element and adding a dummy qr code after for the preview. Purpose of this PR: To replace the generated QR code with the preview, dummy QR code for the preview wizard. Steps to Reproduce on Runbot: install a new company enable QR code in the settings set up a valid SEPA bank account for the bank journal create an invoice and click 'print & send' to trigger the Configure Document Layout wizard view 2 QR codes in the preview opw-4267407 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a test helper in the HTML editor so moving the text selection no longer rebuilds the page content when nothing has changed. It reduces unnecessary background updates during tests, helping keep editor testing more stable and efficient without changing user-facing behavior.
Original PR description
Before this commit, in the tests, when the setContent utils is used to move the selection, the entire html is recreated. This implies a set of unnecessary mutations in the dom. This commit will therefore prevent the creation of all these mutations by checking if the ‘content’ is different from that in ‘el’. 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
Odoo now shows a server-side warning when older Kanban view templates are used, helping teams identify views that need updating. This complements the existing browser warning and helps prevent deprecated configurations from being introduced unnoticed.
Original PR description
A new API for kanban templates has been introduced in [1], which deprecates the former API (the one defining a "kanban-box" template). A client side warning has been added when a legacy kanban view was met. However, there was a lack of server side warning, especially when a legacy kanban arch was introduced. This commit adds this warning. More information about the new Kanban API can be found in the documentation [2]. [1] https://github.com/odoo/odoo/pull/167751 [2] https://www.odoo.com/documentation/master/developer/reference/user_interface/view_architectures.html#kanban 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 fix ensures website notification popups appear in the visible browser window even when visitors are scrolled down the page. It prevents important confirmations, such as newsletter signup messages, from being hidden at the top of the page.
Original PR description
Since [1], the notifications were not positioned properly anymore. Indeed, if the page was scrolled, the notifications were scrolled with it, meaning that they would not be visible at the top of the viewport as intended, but at the top of the scrolled body. Steps to reproduce: - Install website_mass_mailing - Go to your website homepage in edit mode - Add enough content to make the page scrollable - Add a "Newsletter" inner block inside the footer - Save - Scroll to your footer and register to the newsletter => A popup is shown but you can't see it (scroll to the top to see it). The solution is simple: the previous notification manager was positioned based on the fact the body is never scrolled (position: absolute), we now position it based on the viewport (position: fixed) as it could have already been. [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e Closes https://github.com/odoo/odoo/issues/186432 Related to task-4190506
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 reorganizes how the HTML editor coordinates commands, toolbar actions, and plugin communication. It should make future editor changes easier to build, test, and debug while keeping the visible editing experience largely unchanged.
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/72830
At the moment cancelling assets is impossible when audit trail is enabled because it tries to unlink the move. It should be possible, in which case the move should be reversed instead. By adding a check in _can_be_unlinked to return False in such case, the _unlink_or_reverse method will then properly reverse asset moves as expected. Back port of https://github.com/odoo/odoo/pull/181193 task-4251586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
At the moment cancelling assets is impossible when audit trail is enabled because it tries to unlink the move. It should be possible, in which case the move should be reversed instead. By adding a check in _can_be_unlinked to return False in such case, the _unlink_or_reverse method will then properly reverse asset moves as expected. Back port of https://github.com/odoo/odoo/pull/181193 task-4251586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186974 Forward-Port-Of: odoo/odoo#184535
Steps to reproduce: - Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id - In journal items, try to "cut-off" Issue: You won't be able to do so because of the tax lock date Cause: We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/
Original PR description
Steps to reproduce: - Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id - In journal items, try to "cut-off" Issue: You won't be able to do so because of the tax lock date Cause: We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/odoo/blob/16.0/addons/account/wizard/account_automatic_entry_wizard.py#L242-L271 Solution: we set the `has_tax` to False to byapss the check. The user, if he wishes, could excatly the same flow by creating an entry "a la mano" <-> We don't need to block this flow opw-4191527 Forward-Port-Of: odoo/odoo#185078
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
Original PR description
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
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#186718
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 Forward-Port-Of: odoo/odoo#186718
This pull request updates the muk_web_theme package to version 18.0.1.2.3. The available information does not describe specific functional changes, so business impact appears limited to maintaining the theme package version.
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
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_auto
Original PR description
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation…
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_automation_last` after filtering the records by checking the `trigger_field_ids`. ## Benchmarks Measuring `web_save` when updating the stage of a lead in the Kanban view of CRM: | # `crm.lead ` | # `automation.rule` on crm.lead | Before | After | % | -------------------- | -----| -- | ---------- | -------- | 970 records| 6 | 1.5s | 0.3 s | - ~80% ### References opw-4263443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186487
Versions -------- - saas-17.4+ Enterprise PR: https://github.com/odoo/enterprise/pull/73318 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combi
Original PR description
Versions -------- - saas-17.4+ Enterprise PR: https://github.com/odoo/enterprise/pull/73318 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combines it with the `year` of the date, which is 2024. Solution -------- ### Community: Like the `weeknumber` function added in 9c47e911d0ca7 to `odoo.tools.date_utils`, have a function in `web` that returns both year and week number. ### Enterprise: Define a `formatLocalWeekYear` function in `web_gantt` using the new `getLocalYearAndWeek` function from `web`. opw-4280192 Forward-Port-Of: odoo/odoo#186284
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Original PR description
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186510 Forward-Port-Of: odoo/odo
Original PR description
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186510 Forward-Port-Of: odoo/odoo#186243
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected behavior:** AMLs generated for this move have 0 quantity. **Steps to reproduce:** *Having accounting, purchase_stock* 1. Create a storable product with `average` costing 2. Create a purchase order for some of the product with some arbitrary price unit, receive the product 3. In
Original PR description
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected…
**Current behavior:**
Manually adjusting a FIFO/AVCO product's cost creates a journal
items with non-zero quantity, despite there not being a logical
quantity associated with this entry.
**Expected behavior:**
AMLs generated for this move have 0 quantity.
**Steps to reproduce:**
*Having accounting, purchase_stock*
1. Create a storable product with `average` costing
2. Create a purchase order for some of the product with some
arbitrary price unit, receive the product
3. In the product form, change the cost to a smaller value
4. In the journal items pivot view, select the `quantity` field
from the 'Measures' dropdown in the top left, expand the
stock valuation journal on the left axis, observe that the
change in cost has created 2 balancing AMLs, each with
quantity == 1
**Cause of the issue:**
This case was not handled and quantity is always set to 1 if
falsy.
**Fix:**
Create the AMLs created in the cost change handle with
quantity=0. While it does risk being overwritten to 1 if the
`display_type` of the line changes, the diff is minimal and
use-case is non-critical- which makes it the best solution here.
opw-4090620
Forward-Port-Of: odoo/odoo#186514
Forward-Port-Of: odoo/odoo#180998## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we select that pricelist on pos, and put it on default. ## Steps to reproduce: - Go to pos settings and enable flexible pricelists - under the Available Field pick some pricelist and also set it as default - create a loyalty program with a promo code and set the pricelist you picked before as it
Original PR description
## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we…
## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we select that pricelist on pos, and put it on default. ## Steps to reproduce: - Go to pos settings and enable flexible pricelists - under the Available Field pick some pricelist and also set it as default - create a loyalty program with a promo code and set the pricelist you picked before as it's pricelist - open a pos session, add some products and try applying the promo code - a popup will show saying "That promo code program requires a specific pricelist." ## Solution: - While debugging the `activateCode` method, I found that the issue occurred because the code was using `.includes()` to check if `order.pricelist_id.id` was in `program_pricelists`, a list of objects. Since `.includes()` compares values directly, it couldn’t match an ID with objects, leading to it always returning False. - The fix uses the `.some()` method, which checks whether any object in the `program_pricelists` array has an id matching `order.pricelist_id.id`. This ensures that the comparison is made correctly on the id property of the objects. If a match is found, it returns true, and the validation proceeds as expected. OPW-4149335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182124
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Re
Original PR description
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Reload one tab several times: you can sometimes see a flicker from online to offline. task-4236550 Forward-Port-Of: odoo/odoo#186596 Forward-Port-Of: odoo/odoo#184825
Versions -------- - saas-17.4+ Steps ----- 1. Have PDF file with checkbox form fields; 2. upload it as footer for a Quotation Template; 3. set up a quotation using the template; 4. print the PDF Quote. Issue ----- > Odoo Server Error > IndexError: string index out of range Thrown from the PyPDF2 package. Cause ----- Commit e1b05e95e73c expanded the form fields available in the quote builder. It introduced the `_get_form_fields_values_mapping` method. It ignores fields
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Have PDF file with checkbox form fields; 2. upload it as footer for a Quotation Template; 3. set up a quotation using the template; 4. print the PDF Quote. Issue ----- > Odoo Server Error > IndexError: string index out of range Thrown from the PyPDF2 package. Cause ----- Commit e1b05e95e73c expanded the form fields available in the quote builder. It introduced the `_get_form_fields_values_mapping` method. It ignores fields not in the `param_field_map` by associating them with an empty string. This causes issues with non-text form fields, e.g. checkbox, which uses `/Off` to represent the emptiness. Solution -------- Instead of retrieving all fields with `getFields`, use `getFormTextFields`. This way, an empty string should always be a valid value. opw-4290594 Forward-Port-Of: odoo/odoo#185893