Monday, January 27, 2025
36 changes · 18.0
New functionality added to Odoo
Products can now store an Amazon ASIN directly in Odoo. This prepares the system for future Amazon Bulk and DF app work by keeping Amazon product identifiers available on product records.
Original PR description
By default, Odoo does not have an Amazon ASIN field on either of the product models. That is something that needs to be custom-added. I will need this for future work on the Bulk and DF apps, so I've created this module with the sole purpose of adding those fields.
This pull request adds a new Foresta HN SAR submodule to the repository. It appears to introduce a separate component or integration area, but the provided description does not specify the business process or user-facing benefit.
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
Enhancements to existing features
This update adds database optimizations that help WhatsApp message cleanup and related marketing tracking run more efficiently. It reduces the chance of slowdowns when processing large volumes of marketing automation and WhatsApp data, without changing user-facing features.
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
Resolved issues and error corrections
This fix stops an extra dialog from appearing in Point of Sale when the same register session is already being closed. It helps cashiers avoid confusion during the closing process and keeps the workflow smoother.
Original PR description
check commit message for description.
Miscellaneous changes
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#185699
This fixes the status display for draft accounting entries so they once again appear with the expected blue badge. The change helps users quickly distinguish draft moves in accounting lists after a recent view update accidentally removed that visual cue.
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
Fixes an issue where tables added to chatter messages could lose visible cell borders after being logged or sent. This helps users share formatted information more clearly and reliably in discussions.
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
Users are now shown a clear warning when they try to use Print & Send on an invoice that has not yet been confirmed. This prevents a confusing system error caused by draft invoices not having a final invoice number for the PDF filename.
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
This fixes an issue where users could not edit the description of a newly added service line on a confirmed sales order. The change keeps order line descriptions editable when appropriate, reducing friction when updating confirmed orders.
Original PR description
Steps: - Install sale_project - Create a service type product - Create a SO and confirm it - In the confirmed order add a SOL with the new product Issue: - cannot edit the description of the new SOL Cause: - readonly for the SOL is set based on product_updatable and product_updatable is set false when product type service even for new order line Fix - Updated the readonly condition to account for new lines opw - 4473488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order combo items now allow users to update the delivered quantity, not just the description and taxes. This fixes an editing limitation so delivered amounts can be corrected directly when needed.
Original PR description
Previously, only the description and taxes could be edited on combo item SOLs. However, the delivered quantity should also be editable. opw-4454205
The Sign app now sends users back to the project they came from after completing a signature request. This avoids opening an unnecessary new wizard and makes the workflow smoother for project users.
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
Changing the date in the duplicate transaction finder no longer causes an error when results appear after an empty state. This makes the bank synchronization workflow more reliable for users reviewing potential duplicate transactions.
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
Financial report rows and columns will now keep the intended order automatically during database upgrades. This prevents reports from appearing in an unexpected sequence if the underlying report definitions change, reducing manual maintenance and upgrade risk.
Original PR description
Having no manual sequence on report lines/columns might be problematic in case of DB upgrade, if the line order changed in the xml files, as the report won't adapt and update the sequence field. Setting auto_sequence will ensure that this won't ever be a problem anymore (and avoid the tedious task of manually setting the sequence on each line/column)
Tax closing messages now show a clickable link to the related main closing entry instead of displaying raw HTML text. This makes it easier for accounting users to navigate between dependent tax closing entries and their parent entry.
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
Reconciled batch payments no longer appear as available options during bank reconciliation. This prevents users from accidentally seeing or selecting payments that have already been matched, keeping the reconciliation workflow clearer and more accurate.
Original PR description
### Steps to reproduce: - In Accounting, create a new Customer invoice - Create a payment for this invoice - In Customer > Batch Payments create a new batch payment - Select the payment you created - In the Dashboard click on the three dots of the "Bank" block and click on transactions - Create a new transaction with the same amount as the invoice - Click "Match" on the right - In the "Batch Payments" tab select the Batch payment previously created - Validate - Back in the Dashboard, click on the reconcile button of the Bank block - In the "Batch Payments" tab the batch payment is still here even if it is reconciled ### Cause: There are no domain to filter the batch payments. ### Solution: Add a domain to check the state of the batch payments, do not display if it is "reconciled". opw-4461341
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 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#191529One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Original PR description
There is already a placeholder image displayed when an image fails to load. opw-4419565 Forward-Port-Of: odoo/odoo#194011 Forward-Port-Of: odoo/odoo#193825
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could
Original PR description
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of…
Scenario: - have two res.partner with ir.property with res_id and without company_id (eg. by editing the ir.property and removing it) - merge these partners => UniqueViolation error because of unicity of (fields_id, company_id, res_id) constraint of ir_property table Why: The query merging property doesn't take NULL into account for company_id when checking if the destination partner already has this property. Also a savepoint was used, without ignoring the error so the import could not be done if an error happened. Fix: Take the case where both records have NULL company_id into account. Also ignore error and log a warning when a legitimate error happens because of duplicate ir.property in source records. Note: This issue should only happen when: - modifying ir.property directly - after a migration with a res.partner field becoming company_dependent field, the partners without company would get an ir.property without company_id Without the fix, the added test would fail because of an error at each _merge call. opw-4300572 opw-4030442 Forward-Port-Of: odoo/odoo#194942 Forward-Port-Of: odoo/odoo#188673
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 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#190214
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is m
Original PR description
### Description of the issue/feature this PR addresses: - The [_get_plan_available_base_domain()](https://github.com/odoo/odoo/blob/18.0/addons/mail/wizard/mail_activity_schedule.py#L330) method is built and `self.ensure_one()` is placed in it but it is called in `_compute_plan_available_ids()` with `self` which can have multiple records ### Current behavior before PR: - The error `ValueError: Expected singleton: mail.activity.schedule(1, 2)` occurred ### Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194338
This commit makes the same fix as [1] but it does t for kanban views instead of list views. We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0 [1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad [2]: opw-4370092 Task: opw-4370092 Forward-Port-Of: odoo/odoo#194941 Forward-Port-Of: odoo/odoo#194859
Original PR description
This commit makes the same fix as [1] but it does t for kanban views instead of list views. We discovered in task [2] we were developing for the master branch that we needed this fix and that we wanted to fix it from 17.0 [1]: ecc0a38a1d3b04f854d761fd498b120a4dfef5ad [2]: opw-4370092 Task: opw-4370092 Forward-Port-Of: odoo/odoo#194941 Forward-Port-Of: odoo/odoo#194859
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
Original PR description
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193994
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#193987
Original PR description
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#193987
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] st
Original PR description
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback…
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] starting from Odoo version 18.0). This is not compatible with the older browsers mentioned above. The bug only appears in version 18. However, we already fixed this in 16.0 in case potential customizations had added the ":is" pseudo-class to the same selector. [1]: https://github.com/odoo/odoo/commit/65a85009800dfa45526ebdc41d3a0a808b2e9f6d [2]: https://github.com/odoo/odoo/commit/e0fc83760f991fa2fea39763bb2709d9e0182316 opw-4494945 Forward-Port-Of: odoo/odoo#194908 Forward-Port-Of: odoo/odoo#194676
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#194426 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#194426 Forward-Port-Of: odoo/odoo#192048
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#195014 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#195014 Forward-Port-Of: odoo/odoo#194801
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider i
Original PR description
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python…
Description of the issue/feature this PR addresses: The method werkzeug.http.parse_www_authenticate_header has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the requirements.txt specifies werkzeug 3.0.1. This results in a misleading error stating that auth_signup is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed. Desired behavior after PR is merged: The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected. Fixes #194002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194484
When creating a new mass mailing from an event, the default domain retrieved when switching mailing type is missing the event id filter Steps to reproduce (mass_mailing_sms required): - Open an event with attendees - Click 'Contact Attendees' - Take note of the mailing domain - Switch Mailing Type from Email to SMS Issue: Domain is missing the event_id This does not occur when opening the form view because the default mailing domain is given via context opw-4337256 Forward-Port-
Original PR description
When creating a new mass mailing from an event, the default domain retrieved when switching mailing type is missing the event id filter Steps to reproduce (mass_mailing_sms required): - Open an event with attendees - Click 'Contact Attendees' - Take note of the mailing domain - Switch Mailing Type from Email to SMS Issue: Domain is missing the event_id This does not occur when opening the form view because the default mailing domain is given via context opw-4337256 Forward-Port-Of: odoo/odoo#194809 Forward-Port-Of: odoo/odoo#189317
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#172820 Forward-Port-Of: odoo/odoo#157028
Original PR description
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#172820 Forward-Port-Of: odoo/odoo#157028
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. Also add `pos_urban_piper_enhancements` to be translated since it was apparently added into stable without being marked to be translated.
Original PR description
One had a duplicate msgid (i.e. broke the sync) and needed to be re-exported, so re-export them all to fix all other out of date pot files. Also add `pos_urban_piper_enhancements` to be translated since it was apparently added into stable without being marked to be translated.
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_ext
Original PR description
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and…
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_extract/models/hr_expense.py#L21 An expense is muted when this field is set to `True`: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/hr_recruitment_extract/views/hr_applicant_views.xml#L67 Solution: We override `iap_extract` method https://github.com/odoo/enterprise/blob/2e3113562309bf4d440e12ab09eaf94d0b302f1f/iap_extract/models/extract_mixin.py#L69 If the expense is not in draft, it indicates that the process continued without waiting for the extraction process to complete (values were manually entered). To ensure a consistent extraction state, we extend the "Check OCR Status" logic to prevent an infinite waiting_extraction status. fw note: force_write paramater cleaned up in https://github.com/odoo/enterprise/pull/63717 AS FROM 18.0: It appears that the check_ocr_status extension is 'dead code'. In fact, the cron checking the ocr status calls `check_all_status` and not directly `check_ocr_status`. The domain used excludes our case https://github.com/odoo/enterprise/blob/c4a0a4a06b46ba4173024cb07f4666d466306bb9/iap_extract/models/extract_mixin.py#L376-L378 And so `_try_to_check_ocr_status` will not be called. Therefore `_check_ocr_status` will not be called either. `check_ocr_status` is only called when you click 'refresh' on the banner. This banner disappeard because `extract_can_show_banners` is set to `False` when the record is not in draft. And the route will not solve the issue either becasue it filters out non draft records.https://github.com/odoo/enterprise/blob/b34c06c34c7fdaa55d9dbc5cf87fcfaa6f0a7602/hr_expense_extract/controllers/main.py#L8-L14 opw-4239404 X-original-commit: https://github.com/odoo-dev/enterprise/commit/3cfb6517220ae252d633bb9debc5010a0f14efbe
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75770
Original PR description
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75770
Currently, an error occurs when attempting to insert field `template_autocomplete_ids` into planning slot list view using studio mode. Step to produce: - Install the `sale_planning` and `web_studio` modules (with demo data). - Open the 'My Planning' list view. - Add the `template_autocomplete_ids` field to the list view using 'studio'. - Error generated at the backend. `ValueError: Expected singleton: planning. Slot(5, 7)` The error occurs because the system attempts to access a
Original PR description
Currently, an error occurs when attempting to insert field `template_autocomplete_ids` into planning slot list view using studio mode. Step to produce: - Install the `sale_planning` and `web_studio` modules (with demo data). - Open the 'My Planning' list view. - Add the `template_autocomplete_ids` field to the list view using 'studio'. - Error generated at the backend. `ValueError: Expected singleton: planning. Slot(5, 7)` The error occurs because the system attempts to access a single value of fields from multiple records at [1]. [1] - https://github.com/odoo/enterprise/blob/5a9d3be9fb65d780ce92c437600220b8a0e95023/planning/models/planning.py#L410-L414 To resolve this issue, use an iteration(for loop) to iterate records one by one. Sentry-6217013028 Forward-Port-Of: odoo/enterprise#77318
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
Original PR description
The aim of this commit is passing correctly the debug mode in the URL params to the bank sync iframe. It allows to debug the iframe during the development. no task id Forward-Port-Of: odoo/enterprise#77501
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718
Original PR description
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 Forward-Port-Of: odoo/enterprise#70718