Monday, February 3, 2025
18 changes · 17.0
Enhancements to existing features
The recruitment demo data now replaces questionable email addresses for two sample applicants. Their demo CV files were also refreshed, keeping sample recruitment records more appropriate and consistent for users evaluating the app.
Original PR description
Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003
This change makes attendance data filtering in the Gantt view easier to adapt for local country rules. It helps businesses customize attendance displays without changing core behavior, supporting more accurate workforce management across regions.
Original PR description
Different countries have different attendance rules and therefore customizing the attendance entries might be relevant. In order to be able to properly filter we introduce a domain retrieval method which can be properly inherited. Info: @wt-io-it
Resolved issues and error corrections
Manufacturing orders now show the expected color indicators for component consumption: under-consumed quantities stay neutral, exact consumption is highlighted as correct, and over-consumption remains flagged. This helps users quickly spot whether materials match the planned production needs without misleading visual cues.
Original PR description
**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; -…
**Steps to reproduce:**
- Create a storable product `P1` with the following BoM:
- Qty: 1 unit
- Components:
- C1, C2, C3: 3 units
- Create a MO to produce one unit of `P1`;
- Confirm the order;
- Update the product's `Quantity` to 1 at least;
*The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.*
- Update the field `Quantity` of components to:
- **C1**: 1 unit
- **C2**: 3 units
- **C3**: 4 units
___
**Issue:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less than the <ins>total needed</ins> value → highlights in green;
- **C2**: equal to the value → highlights in black;
- **C3**: higher than the value → highlights in orange.
___
**Expected:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less -> black;
- **C2**: equal -> green;
- **C3**: higher -> orange.
___
**Cause:**
Text decorations are based on a wrong logic by getting the quantities from wrong field. This field has been changed during an apocalypse.
https://github.com/odoo/odoo/blob/c43297435cfcaf560d5c952ac3c4a383a6f1dc28/addons/mrp/views/mrp_production_views.xml#L405-L406
___
**Fix:**
Reset good field to check quantities, inspired by Odoo 16 using the computed `should_consume_qty` value to check the consumption status:
https://github.com/odoo/odoo/blob/67c78b38e794333eae55758ad4610515df5c49d2/addons/mrp/views/mrp_production_views.xml#L342-L343
___
**Forward:**
To forward up to master.
Odoo 17 :
```
<field name="quantity" string="Quantity"
decoration-success="product_uom_qty - quantity > -0.0001 and product_uom_qty - quantity < 0.0001"
decoration-warning="quantity - product_uom_qty > 0.0001"
```
___
opw-4393156
opw-4391582
opw-4391600
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMiscellaneous changes
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s
Original PR description
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, so also the non sales moves will have the team assigned opw-4422292 Forward-Port-Of: odoo/odoo#195645
The web editor’s font size dropdown now includes smaller options: 8, 10, and 12. This gives backend users more precise formatting choices without affecting areas where custom font size input is already available.
Original PR description
### Description of the issue/feature this PR addresses:
- Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided.
### Desired behavior after PR is merged:
- The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`.
task-3829323Bank statement names that are very long are now shortened on screen so the statement total button remains accessible. Users can still see the full statement name by hovering over it, improving usability without changing the underlying data.
Original PR description
If the statement name is too long, it is not truncated, making it impossible to access the button displaying the statement total. Steps to reproduce: - Go to the accounting dashboard - In the Bank journal, select statements - Open a statement and rename it with a long name that occupies the full width of the left column in the reconciliation page The fix truncates the text and adds its full value in the `title` attribute for better accessibility. Before:  After:  opw-4414518
The Planning app now shows a more general error when copying shifts from the previous week fails. This avoids misleading users when the copy is blocked by related business rules from other installed apps, such as project hour limits.
Original PR description
Make the error message in Planning more generic, as the copy of shifts from the previous week can fail for other reasons if other modules are installed. Example: with Project installed, the shift is not copied if it is linked to a project and there are not enough hours available on the project. opw-4285651
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
Original PR description
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:
Original PR description
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id: 4531511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195814
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Original PR description
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196154
Original PR description
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196154
Before this commit: =================== - when creating a discount and loyalty program type coupon with rules for minimum quantity and purchase equals 1, along with a specific product reward, `multiple reward order lines` were erroneously generated if the coupon balance exceeded 1. - upon refreshing the page, the reward line quantity would increment incorrectly. After this commit: ================== - with this commit, only one reward order line is created per coupon application, a
Original PR description
Before this commit: =================== - when creating a discount and loyalty program type coupon with rules for minimum quantity and purchase equals 1, along with a specific product reward, `multiple reward order lines` were erroneously generated if the coupon balance exceeded 1. - upon refreshing the page, the reward line quantity would increment incorrectly. After this commit: ================== - with this commit, only one reward order line is created per coupon application, and the coupon now correctly applies only once, resolving the previous inconsistencies. task - 3869549 Forward-Port-Of: odoo/odoo#162359
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreak
Original PR description
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreakable()` function has been updated to ensure that nav items (tabs) are treated as non-splittable elements. This prevents the tab from being split when the Enter key is pressed. Additionally, a test case has been added to cover the scenarios outlined in [commit]( https://github.com/odoo/odoo/commit/439e491608bab07f3f001d38b7774040a4b18980) as well to ensure the fix is effective. task-4316648 Forward-Port-Of: odoo/odoo#193239
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe
Original PR description
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe a traceback error. opw-4381159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193255
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. 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#195909
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from
Original PR description
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from 17.4): - Install website_sale module - Go to /sitemap.xml - Observe that all the products and category urls are duplicated. [1]: https://github.com/odoo/odoo/commit/1b52b00d2aa96b9360d50a0f0960f1febb5e607e opw-4420398 task-4074719 Forward-Port-Of: odoo/odoo#195949
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#193971
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task
Original PR description
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task-id: 4531511 Forward-Port-Of: odoo/enterprise#78205