Tuesday, January 28, 2025
43 changes · saas-18.1
Enhancements to existing features
This update makes several small visual refinements across Odoo Discuss and Live Chat, including better spacing, softer indicators, clearer dark-mode contrast, and less distracting action buttons. These changes improve readability and make messaging screens feel cleaner without altering core functionality.
Resolved issues and error corrections
The message composer avatar positioning has been adjusted to display correctly in this Odoo version. This fixes a small visual inconsistency introduced by an earlier UI update, improving the polish of the messaging experience.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/195364 PR above made several small UI adjustments, from similar PR made in 18.0. One of the change was to fix avatar alignment with composer. However the alignment fix made sense in 18.0 but not in 18.1. This commit reverts this part of the improvements, so that the alignment is correct. Before  After 
Miscellaneous changes
This PR adds a test to ensure that negative overtime works properly and is recomputed as multiple attendance records are made on a single day. For employees who clock out to take breaks, this is necessary. This ensures that the "extra hours" propagate to the most recent attendance record, while zeroing out those before it. The PR that brought the notion of negative overtime to flexible working schedules is here: https://github.com/odoo/odoo/pull/193523#pullrequestreview-2569240672 Forwar
Original PR description
This PR adds a test to ensure that negative overtime works properly and is recomputed as multiple attendance records are made on a single day. For employees who clock out to take breaks, this is necessary. This ensures that the "extra hours" propagate to the most recent attendance record, while zeroing out those before it. The PR that brought the notion of negative overtime to flexible working schedules is here: https://github.com/odoo/odoo/pull/193523#pullrequestreview-2569240672 Forward-Port-Of: odoo/odoo#194898
This update makes emoji, GIF, and quick reaction popups use matching background and border styling. It improves visual consistency, especially in dark mode, making the messaging interface feel more polished for users.
Original PR description
The emoji picker bg is `bg-100` and the quick reaction menu bg is `bg-view` which seems odd. This PR harmonizes the two backgrounds. | Before | After | | ------------- | ------------- | |  |  |
The mail composer in chatter no longer crashes for users on some older browsers. This improves reliability for customers who have not recently updated their browser, keeping message composition usable.
Original PR description
This happened when opening the composer in chatter on a outdated browser from as late as november 2023. This commit adds a function that polyfills when the function is not implemented by the browser.
The stock picking operations report now uses the correct source for packaging quantities. This prevents errors when viewing or printing the report and helps warehouse documents show reliably.
Original PR description
This commit fixes accessing `stock_move_line.packaging_uom_qty` field which doesn't exist and changes it to access `stock_move.packaging_uom_qty` instead. Runbot : 111967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live chat composer no longer shows the attachment option when file uploads are not permitted. This prevents users from clicking a button that appears available but does nothing, making the chat experience clearer and less frustrating.
Original PR description
Before this PR, the attachm file button in the composer was displayed even if upload was not allowed. Clicking on this button woudln't do anything since upload is forbidden. This PR hides the upload file action is upload is not allowed. task-4433082 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 Payment Policy field is now hidden for companies where it is not needed, such as non-Mexican companies in multi-company setups. This keeps invoice screens cleaner and avoids confusion for users who do not use Mexican electronic invoicing requirements.
Original PR description
Since odoo/enterprise#75709, the 'Payment Policy' field is always visible on move form view, including for non-MX companies (multi company context). This commit make it visible only when needed for EDI.
Before this commit: Using the button command in the powerbox resulted in the creation of a regular link instead of a button. After this commit: Executing the button command now correctly creates a primary button as intended. task-4380129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189893
Original PR description
Before this commit: Using the button command in the powerbox resulted in the creation of a regular link instead of a button. After this commit: Executing the button command now correctly creates a primary button as intended. task-4380129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189893
Steps ----- - Have a user with 'Employees' Administator rights and no 'Administration' rights. - Create a new employee. - When viewing the Kanban views of employees, the image for the newly created employee appears corrupted (the text 'binary file' appears instead of the image). Cause ----- When we create a new employee, `_avatar_generate_svg` is called https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/addons/hr/models/hr_employee.py#L497-L498 that returns a svg
Original PR description
Steps ----- - Have a user with 'Employees' Administator rights and no 'Administration' rights. - Create a new employee. - When viewing the Kanban views of employees, the image for the newly created…
Steps ----- - Have a user with 'Employees' Administator rights and no 'Administration' rights. - Create a new employee. - When viewing the Kanban views of employees, the image for the newly created employee appears corrupted (the text 'binary file' appears instead of the image). Cause ----- When we create a new employee, `_avatar_generate_svg` is called https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/addons/hr/models/hr_employee.py#L497-L498 that returns a svg/xml base-64 encoded. However, only users with write rights to `ir.ui.view` are able to create svg/xml attachments. https://github.com/odoo/odoo/blob/717f3a1ab25613c02c2d0b28fa8dd73f4e6c75e0/odoo/addons/base/models/ir_attachment.py#L368-L371 Else, the attachment has a text mimetype forced, leading to it being incorrectly displayed. Change ----- A default image is not generated at employee creation if the user doesn't have sufficient rights. opw-4311251 Forward-Port-Of: odoo/odoo#194588 Forward-Port-Of: odoo/odoo#190214
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025
Original PR description
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the…
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025). -> ~14 days of time off available: the max postpone amount is not applied, the time gained is in days and not in hours and more than 1 day is gained/month (balance a few days after the start of the allocation should be +1 added_value but is more than that). Causes: - the maximum amount of carry over `postpone_max_days` is applied in days even if the accrual `added_value` is in hours and the UI shows `postpone_max_days` as "Up to X hours". - `get_future_leaves` returns a number of hours if the allocation is in hours, even if the time off type is in days. - the number of hours from the accrual at the beginning of the allocation is too high if the start of the accrual is in the future and gain time added at the start of the period due to cache not being invalidated. https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578 opw-4272315 Forward-Port-Of: odoo/odoo#188728 Forward-Port-Of: odoo/odoo#185699
[FIX] web_editor: adapt `border-style` value based on border widths **Problem**: Outlook always displays the border of an element if `border-style` is set to `solid`, even when all border widths are 0. **Solution**: Change `border-style` to `none` if all border widths are 0. **Steps to Reproduce**: 1. Open the "Event: Registration Confirmation" email template in the web editor. 2. Add a character and save the template. 3. Check the saved `body_html`. -> All t
Original PR description
[FIX] web_editor: adapt `border-style` value based on border widths
**Problem**:
Outlook always displays the border of an element if `border-style` is set
to `solid`, even when all border widths are 0.
**Solution**:
Change `border-style` to `none` if all border widths are 0.
**Steps to Reproduce**:
1. Open the "Event: Registration Confirmation" email template in the web editor.
2. Add a character and save the template.
3. Check the saved `body_html`.
-> All table elements will have `border-style: solid;` added as inline styling,
causing borders to appear in Outlook.
opw-4211794
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195282
Forward-Port-Of: odoo/odoo#193973Steps to reproduce the bug: - Create a “Company A” and a “ branch 1” linked to this company - Create a storable product “P1”: - limited to Company A - Select only the branch 1 as current company - Create a receipt for one unit of P1 - Mark it as to do. - Try to create a lot or use lot created in Company A Problem: An acces error is raised: `Incompatible companies on records: - 'Product B' belongs to company 'Branch X' and 'Lot/Serial Number' (lot_id: 'sn_test') belongs to anot
Original PR description
Steps to reproduce the bug:
- Create a “Company A” and a “ branch 1” linked to this company
- Create a storable product “P1”:
- limited to Company A
- Select only the branch 1 as current company
- Create a receipt for one unit of P1
- Mark it as to do.
- Try to create a lot or use lot created in Company A
Problem:
An acces error is raised:
`Incompatible companies on records:
- 'Product B' belongs to company 'Branch X' and 'Lot/Serial Number' (lot_id: 'sn_test') belongs to another company.`
opw-4415565
Forward-Port-Of: odoo/odoo#191529Before this commit, cancelling an order would result in keeping the removed orderlines in the unlink command, causing issues in different cases when trying to sync a new order. opw-4403100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192118
Original PR description
Before this commit, cancelling an order would result in keeping the removed orderlines in the unlink command, causing issues in different cases when trying to sync a new order. opw-4403100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192118
Issue ----- When selecting a variant for the bom, all of the component lines lose the "Apply on variants" info. This is intended behaviour but can lead to big data losses for larger boms. Discussed it with PO and we went with a simple user warning when this happens. Steps to reproduce ----- - Create product "A" with variant "A1" and product "B" - Create a bom for A - Create a bom line with "Apply on variants" set to A1 - Save the bom - Change the bom product from A to B - Save the
Original PR description
Issue ----- When selecting a variant for the bom, all of the component lines lose the "Apply on variants" info. This is intended behaviour but can lead to big data losses for larger boms. Discussed it with PO and we went with a simple user warning when this happens. Steps to reproduce ----- - Create product "A" with variant "A1" and product "B" - Create a bom for A - Create a bom line with "Apply on variants" set to A1 - Save the bom - Change the bom product from A to B - Save the bom / Leave the page Ticket: opw-4182384 Forward-Port-Of: odoo/odoo#191541
Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now. 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#195103 Forward-Port-Of: odoo/odoo#194801
Original PR description
Because 'Tax ID' was within the `t-esc` the term was never translated. This goes against some country's compliance requirements for receipts, so we make it translatable now. 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#195103 Forward-Port-Of: odoo/odoo#194801
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have
Original PR description
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have their product description printed on the report --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193502
Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193969 Forward-Port-Of: odoo/odoo#193764
Original PR description
Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193969 Forward-Port-Of: odoo/odoo#193764
Before this commit, syncing a Google Calendar that includes an all-day recurrent event—one of which is rescheduled—would fail entirely. This happened because `full_recurring_event_id` only handled events with a specific date-time format (`T...Z`), causing the regex to break for date-only IDs. opw-4443780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194176
Original PR description
Before this commit, syncing a Google Calendar that includes an all-day recurrent event—one of which is rescheduled—would fail entirely. This happened because `full_recurring_event_id` only handled events with a specific date-time format (`T...Z`), causing the regex to break for date-only IDs. opw-4443780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194176
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#194734 Forward-Port-Of: odoo/odoo#192048
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#194734 Forward-Port-Of: odoo/odoo#192048
since the pr https://github.com/odoo/odoo/pull/189883, the file updates made are not consistent: 'list<editable="bottom">'. Forward-Port-Of: odoo/odoo#194319
Original PR description
since the pr https://github.com/odoo/odoo/pull/189883, the file updates made are not consistent: 'list<editable="bottom">'. Forward-Port-Of: odoo/odoo#194319
Followup of odoo/odoo#134682 but for code added notably during odoo/odoo@f685e70616e8fe357690cd8e6cfa4543c1d0df24 Also fix the test, as it was not testing the real issue (wrong model used in test). Task-3743525 Forward-Port-Of: odoo/odoo#195301
Original PR description
Followup of odoo/odoo#134682 but for code added notably during odoo/odoo@f685e70616e8fe357690cd8e6cfa4543c1d0df24 Also fix the test, as it was not testing the real issue (wrong model used in test). Task-3743525 Forward-Port-Of: odoo/odoo#195301
In the account move view, since this commit: https://github.com/odoo/odoo/commit/9b47dd1158b2819c74431f30ff137cbb13ce0d4f We made a new column that is status_in_payment but with that we removed the decoration for draft moves task-4497735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194380
Original PR description
In the account move view, since this commit: https://github.com/odoo/odoo/commit/9b47dd1158b2819c74431f30ff137cbb13ce0d4f We made a new column that is status_in_payment but with that we removed the decoration for draft moves task-4497735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194380
Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192246
Original PR description
Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192246
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data
Original PR description
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data-oe-attr="..."></b><p>content</p></div>`. This causes a traceback when trying to access `data-oe` attributes, as they are expected to be in the root element. **Solution**: Convert any `b` elements used as HTML fields to `div` elements before saving. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194872
**Problem**: When adding a table in the chatter and logging/sending, the table is not displayed properly. This issue is same as: https://github.com/odoo/odoo/commit/99c5a73b2ffc9bef6128059c51574c70cdfc6767. Grouped styles like `border`, `padding`, and `border-radius` do not propagate their values to substyles when variables are used in the value. **Solution**: Apply same fix in `convert_inline` of `mail` **Steps to Reproduce**: 1. Open the full composer. 2. Add a table. 3. Log a note
Original PR description
**Problem**: When adding a table in the chatter and logging/sending, the table is not displayed properly. This issue is same as: https://github.com/odoo/odoo/commit/99c5a73b2ffc9bef6128059c51574c70cdfc6767. Grouped styles like `border`, `padding`, and `border-radius` do not propagate their values to substyles when variables are used in the value. **Solution**: Apply same fix in `convert_inline` of `mail` **Steps to Reproduce**: 1. Open the full composer. 2. Add a table. 3. Log a note. 4. Observe that `td` borders are not visible. opw-4483477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194528
Steps to reproduce: ----- - Create a MO - Duplicate it - Change the scheduled date - Confirm Issue: --- This [changes](https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44), is trying to timedelta between str and datetime leading to an error. Fix: --- To fix this the date_start is set as a datetime and removing the conversion later in the code. opw-4489618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Steps to reproduce: ----- - Create a MO - Duplicate it - Change the scheduled date - Confirm Issue: --- This [changes](https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44), is trying to timedelta between str and datetime leading to an error. Fix: --- To fix this the date_start is set as a datetime and removing the conversion later in the code. opw-4489618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194376
Currently, an error occurs when attempting to print and send an invoice that is in a draft state. Step to produce: - Install the `account` module. - Go to Invoicing / Customers / Invoices, Create one invoice without a customer and invoice line, and come to the list view of Invoices. - Select this invoice and click on 'Print & Send'. `AttributeError: 'bool' object has no attribute 'replace'` The issue occurs because the system attempts to replace the name at [1] to generate a PDF fi
Original PR description
Currently, an error occurs when attempting to print and send an invoice that is in a draft state. Step to produce: - Install the `account` module. - Go to Invoicing / Customers / Invoices, Create one invoice without a customer and invoice line, and come to the list view of Invoices. - Select this invoice and click on 'Print & Send'. `AttributeError: 'bool' object has no attribute 'replace'` The issue occurs because the system attempts to replace the name at [1] to generate a PDF file name. But the invoice's name is not available. Link [1]: https://github.com/odoo/odoo/blob/41de88b930e569daea7624ee3655cef218f9136f/addons/account/models/account_move.py#L5739 To resolve this issue, Raise a user error if the user attempts to select the 'Print & Send' action on an invoice that is not in the confirmed state. Sentry-6185757435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192020
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and
Original PR description
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and the PDF appears correctly. The exact problematic value depends on browser and environment, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size Solution ----- Use a maximum canvas size but keep the styling of the canvas element to cover all the PDF viewer. This means a scaling factor needs to be applied to the position of the sign items between which the lines are drawn. opw-4407698 Forward-Port-Of: odoo/enterprise#75765
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-P
Original PR description
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-Port-Of: odoo/enterprise#76072
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged messag
Original PR description
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged message. [this commit]: https://github.com/odoo/enterprise/commit/09f5b35493bee7b63e96e8b28ad741aeb5ee80e5 Forward-Port-Of: odoo/enterprise#77826
Steps to reproduce the bug: - Log in as Mitchel Admin. - Create a storable product with BoM: - Operation: OP1 - Create a Manufacturing order to produce one unit of P1 - Confirm the MO - Assign Mark demo to the OP1 - Validate the MO Problem: The work center productivity record is created using the employee linked to the current user rather than the one assigned to the operation. opw-4416940 Forward-Port-Of: odoo/enterprise#77296 Forward-Port-Of: odoo/enterprise#75900
Original PR description
Steps to reproduce the bug:
- Log in as Mitchel Admin.
- Create a storable product with BoM:
- Operation: OP1
- Create a Manufacturing order to produce one unit of P1
- Confirm the MO
- Assign Mark demo to the OP1
- Validate the MO
Problem:
The work center productivity record is created using the employee linked to the current user rather than the one assigned to the operation.
opw-4416940
Forward-Port-Of: odoo/enterprise#77296
Forward-Port-Of: odoo/enterprise#75900### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 fo
Original PR description
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500…
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 for any worked line. - Click on 'Print' button. - 500 Internal Server Error. ### Solution: - Issue introduced here https://github.com/odoo/enterprise/commit/935b23cfe74741d1168d93add8c7a221b5168021#diff-6133beb42a4aef7b7c8e1a19738d1fd2689e40e98a2e4e34c0ad4bf12eb2e1b3R52 `worked_days.amount/worked_days.number_of_hours` cause a division by zero if `worked_days.number_of_hours` is 0. - I've updated the template to handle the case. so now If the value is 0 or less, it simply returns 0 instead of dividing. opw-4478495 Forward-Port-Of: odoo/enterprise#77869
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button red
Original PR description
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button redirects correctly to the project view. task:4431882 Forward-Port-Of: odoo/enterprise#76321
Purpose ======= Allow managing documents version like it was done in 17.4. We created a new action for it, that will open a dialog in which we can download and delete versions, but also upload new ones. Reorder the actions we can do when selecting documents. Add "Export" and "Insert In Spreadsheet" actions, for consistency with other views, those actions are available only in the list view. Task-4480340 Forward-Port-Of: odoo/enterprise#77327
Original PR description
Purpose ======= Allow managing documents version like it was done in 17.4. We created a new action for it, that will open a dialog in which we can download and delete versions, but also upload new ones. Reorder the actions we can do when selecting documents. Add "Export" and "Insert In Spreadsheet" actions, for consistency with other views, those actions are available only in the list view. Task-4480340 Forward-Port-Of: odoo/enterprise#77327
Missing indexes: - `whatsapp.message.parent_id` is hit during Fkey lookup during unlinking to set the value to null during `whatsapp.message`'s GC. - `marketing.trace.whatsapp_message_id` is the inverse of the One2many `marketing_trace_ids`, index will be hit when the ORM reads the O2m field. `marketing_trace` is usually a large table, a `Seq.Scan` should be avoided. Would also be hit during whatsapp's GC Forward-Port-Of: odoo/enterprise#77907
Original PR description
Missing indexes: - `whatsapp.message.parent_id` is hit during Fkey lookup during unlinking to set the value to null during `whatsapp.message`'s GC. - `marketing.trace.whatsapp_message_id` is the inverse of the One2many `marketing_trace_ids`, index will be hit when the ORM reads the O2m field. `marketing_trace` is usually a large table, a `Seq.Scan` should be avoided. Would also be hit during whatsapp's GC Forward-Port-Of: odoo/enterprise#77907
When changes are made through studio, the view needs to be normalized first which in turn requires the use of `difflib.ndiff` that is notorious for slowness in some cases. Refer to this issue on `difflib` https://github.com/python/cpython/issues/119105 for an analysis of why it is slow. In our case, we only care about added and removed lines, not replaced lines, which means `ndiff` is not needed. Instead `unified_diff` is used which is much faster. This PR adapts the module to use `difflib.un
Original PR description
When changes are made through studio, the view needs to be normalized first which in turn requires the use of `difflib.ndiff` that is notorious for slowness in some cases. Refer to this issue on `difflib` https://github.com/python/cpython/issues/119105 for an analysis of why it is slow. In our case, we only care about added and removed lines, not replaced lines, which means `ndiff` is not needed. Instead `unified_diff` is used which is much faster. This PR adapts the module to use `difflib.unified_diff` over `difflib.ndiff` to speedup `edit_view` requests when making any modifications to the view. |no. diff lines|before | after| ------------------|-----------|------------ |~4670 | ~1.4 minutes | ~2.5 sec| opw-4054294 Original PR: https://github.com/odoo/enterprise/pull/67203 Forward-Port-Of: odoo/enterprise#77688
[FIX] documents: ensure access after upload in Company Otherwise, documents are only accessible by superusers as the document is not shared with anyone and owned by OdooBot. [IMP] documents: improve backend UI Based on users feedback, * partial revert of 78b21e99 regarding the search panel. * Redirect uploads in Recent and All to My Drive. * Increase visibility of record parent folder. Note that this will only occur after the views are updated. Task-4485969 Forward-Port-Of:
Original PR description
[FIX] documents: ensure access after upload in Company Otherwise, documents are only accessible by superusers as the document is not shared with anyone and owned by OdooBot. [IMP] documents: improve backend UI Based on users feedback, * partial revert of 78b21e99 regarding the search panel. * Redirect uploads in Recent and All to My Drive. * Increase visibility of record parent folder. Note that this will only occur after the views are updated. Task-4485969 Forward-Port-Of: odoo/enterprise#77293
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by rem
Original PR description
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by removing the obsolete `firstIdsInGroup` field and adding a condition to ensure that the value being checked is an array, preventing any traceback. no task id Forward-Port-Of: odoo/enterprise#77856
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view.
Original PR description
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view. Task-4437768 Forward-Port-Of: odoo/enterprise#76355
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past. Forward-Port-Of: odoo/enterprise#75150
Original PR description
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past. Forward-Port-Of: odoo/enterprise#75150
Version: - 17.0 Steps to reproduce: - Install the Sign module. - Try to open a sample document. Issue: - An access error occurs when a "Sign User" tries to access a demo sign template. Solution: - Allow internal users to access sample data. task- 4390945 Forward-Port-Of: odoo/enterprise#75522
Original PR description
Version: - 17.0 Steps to reproduce: - Install the Sign module. - Try to open a sample document. Issue: - An access error occurs when a "Sign User" tries to access a demo sign template. Solution: - Allow internal users to access sample data. task- 4390945 Forward-Port-Of: odoo/enterprise#75522
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another
Original PR description
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document…
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another internal user (ie. Mark Demo) and upload the same document as a sign template in the Sign app. 4. set the template's `signed document folder` to the same folder as the document uploaded by Mitchell Admin. 5. attempt to send the document for signing. 6. an access error is raised. ### Solution: - Prior to the fix, the `create` method, relied solely on matching the `checksum` of the `sign_requets` attachment with existing documents which resulted in documents not related to the sign request being set as the `reference document`. - The fix now gets the correct document by searching for documents with the same `attachment_id` as the sign request's template attachment. OPW-4421368 Forward-Port-Of: odoo/enterprise#77520