Daily updates from Odoo
Navigate
Branch
Friday, January 10, 2025
47 changes
12 changes
Resolved issues and error corrections
The website project form now translates the "Email" label in the chatter message when a task is created. This improves localization consistency for users working in languages other than English.
Original PR description
- add translation for `Email` in chatter message when task create from website form. task-4295363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail. In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested
Original PR description
The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail. In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested on pre- production) opw-4438259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193000
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb. While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it. Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(s
Original PR description
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb. While technically it was always…
Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb.
While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it.
Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(self._info, DictionaryObject)` as a type narrowing and trusts the developer, thus does not report the type mismatch... and the assertion ends up blowing in the user's face at runtime with a simple
>>> r = pypdf.PdfReader(some_pdf_document)
>>> w = pypdf.PdfWriter()
>>> w.clone_reader_document_root(r)
>>> w.add_metadata({"/foo": "bar"})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "lib/python3.12/site-packages/pypdf/_writer.py", line 1622, in add_metadata
assert isinstance(self._info, DictionaryObject)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
This is rather inconsiderate, so monkeypatch `add_metadata` to handle the case where `_info` exists and is `None`.
Most of the credit goes to juwu for uncovering the issue.
opw-4372052
opw-4426881
Fixes #185673
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#193086**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory
Original PR description
**Current behavior:** The global lead days system parameter may be counted in the lead days breakdown in the replenishment report when: A) product has manufacture route and, B) WH manufacture steps is not 1-step **Expected behavior:** The parameter is counted once. **Steps to reproduce:** 1. Create a product with a simple BoM and the manufacture route 2. Enable 2 or 3 step manufacturing in WH 3. Create an out move for the product 4. Open the replenishment report in inventory 5. Click the (i) in the orderpoint line for the product -> see the global vis. days are counted 2x **Cause of the issue:** Like the issue solved by 38d8e77 In some instances the `_get_lead_days()` must be called a second time to capture some additional lead time (in this case because we have > 1-step manufacturing). **Fix:** Use the context added in the referenced similar commit to ignore the global days in the second call. opw-4410790 Forward-Port-Of: odoo/odoo#190808
The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI. Steps to reproduce the bug * create child company CHILD 1, with an invoice $100 * Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity) * make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal * click reconcile fr
Original PR description
The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI. Steps to reproduce the bug * create child company CHILD 1, with an invoice $100 * Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity) * make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal * click reconcile from the dashboard, on CHILD 2 bank journal => you get an access error because Odoo is trying to match invoice from CHILD 1 and bank transaction from CHILD 2 ticket-4384481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192507
User of a branch company may change accounts configuration product categories, but currently this settings is ignored, as accounts are fetched from the main company instead Steps to reproduce: - Create a branch company - Open a product category [CATEG] (i.e. Office Furniture) and set - 'Inventory valuation': 'Automated' - 'Stock Input Account': [Account] - Assign product category [CATEG] to a product [PROD] - Create a Vendor bill with [PROD] and Save - Check Journal items tab
Original PR description
User of a branch company may change accounts configuration product categories, but currently this settings is ignored, as accounts are fetched from the main company instead Steps to reproduce: - Create a branch company - Open a product category [CATEG] (i.e. Office Furniture) and set - 'Inventory valuation': 'Automated' - 'Stock Input Account': [Account] - Assign product category [CATEG] to a product [PROD] - Create a Vendor bill with [PROD] and Save - Check Journal items tab Issue: Product line account is not [Account] but it is taken from the main company settings This occurs due to a fix [1] done to have `stock_account` in sync with the base method in `account`. However, the forced company in base method was changed in a refactor [2] [1] https://github.com/odoo/odoo/commit/0b07210fe1f1c451eb648deff74c3ab37c8c09bd [2] https://github.com/odoo/odoo/commit/d8d47f9ff8554f4b39487fd2f13c153c7d6f958d opw-4297203 Forward-Port-Of: odoo/odoo#191349
__Current behavior before commit:__ In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore. Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`. In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should
Original PR description
__Current behavior before commit:__ In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore. Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`. In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should use. Ultimately leading to this error: ``` psycopg2.errors.AmbiguousColumn: column reference "end_type" is ambiguous LINE 22: ... WHEN cal.recurrency AND end_type =... ``` __Description of the fix:__ Remove the ambiguity by explicitly specifying `rrule`, the alias of the `calendar_recurrence` table. opw-4406814 [1]: https://github.com/odoo/odoo/commit/a27afdb [2]: https://github.com/odoo/odoo/commit/f6df418 Forward-Port-Of: odoo/odoo#192946
This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. runbot-error: 111437 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#192831
Original PR description
This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. runbot-error: 111437 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#192831
**Steps to reproduce:** - Install account_accountant, sale_management and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create a payment term: * Description on the Invoice: [anything] * Display terms on invoice: [checked] * Terms: [add many lines] - Create a SO: * Customer: [any] * Payment Terms: [the created payment term] * Order lines: [anything] - Confirm the SO - Create an invoice from the SO - Confirm the invoice - Generate the invoice **Issue:
Original PR description
**Steps to reproduce:** - Install account_accountant, sale_management and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create a payment term: * Description on the Invoice: [anything] * Display terms on invoice: [checked] * Terms: [add many lines] - Create a SO: * Customer: [any] * Payment Terms: [the created payment term] * Order lines: [anything] - Confirm the SO - Create an invoice from the SO - Confirm the invoice - Generate the invoice **Issue:** The description of the payment term is displayed on the invoice but the terms are not displayed as it is the case in any other localization. **Cause:** "report_invoice" is replaced by the Arabic/English invoice in l10n_gcc_invoice module. However, the logic to display the terms has not been added in the template for Arabic/English invoice. opw-4291232 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188456
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.5.3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193192
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.5.3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193192
Before this commit: When a user duplicates a server action, the new action retains the exact same name as the original. After this commit: Duplicated server actions are assigned a name with the suffix "(copy)" to differentiate them from the original action. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190383
Original PR description
Before this commit: When a user duplicates a server action, the new action retains the exact same name as the original. After this commit: Duplicated server actions are assigned a name with the suffix "(copy)" to differentiate them from the original action. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190383
**Specifications:** When the domain is specified, helper in crm helper should display an extra line, which explains that any email sent to alias@domain will create a lead. **Technical reason:** A code was added in `crm.lead` which checks for the company, but in data file company was already specified as `False`. Hence, the missing line. **After this PR:** If the custom email domain is set, crm helper will display an extra line. Task-4377574 Forward-Port-Of: odoo/odoo#190936
Original PR description
**Specifications:** When the domain is specified, helper in crm helper should display an extra line, which explains that any email sent to alias@domain will create a lead. **Technical reason:** A code was added in `crm.lead` which checks for the company, but in data file company was already specified as `False`. Hence, the missing line. **After this PR:** If the custom email domain is set, crm helper will display an extra line. Task-4377574 Forward-Port-Of: odoo/odoo#190936
34 changes
Enhancements to existing features
Field service users can now return directly from the product catalog to the task they came from. This reduces navigation friction and helps teams move between task details and related products more efficiently.
Original PR description
In field service, on task form, there is a stat button "n products". Clicking on it leads to the products catalog. In this PR, we add a button on that view to return to the task's form. task-4295982
WhatsApp account settings now show a read-only phone number once the account successfully connects to the API. This helps support teams and users verify incoming message setup more quickly, while hiding the number again if account configuration changes.
Original PR description
### Purpose: Having a Phone Number field in Whatsapp Account Configuration would allow Support Team to test the receiving of messages a lot faster, because this is something the clients struggle a lot with during the set-up of their account. It's also useful for users if they want to test the incoming messages flows. ### After this PR: Added a Read-only 'Phone Number' field, which will be hidden until we successfully connect to the API(Either from 'Sync Templates' button or 'Test Connection' button). This field will became invisible if we change any configuration in the account. Task-4110445
The mobile project side panel now shows its caret more clearly, making it easier for users to notice and use the panel controls. Related project dashboard and task actions were also aligned across connected project modules for a more consistent experience.
Original PR description
Made the mobile Right side panel caret being barely visible. task-4190761
Rental schedule statuses now use distinct colors for late pickups and reserved orders. This makes it easier for users to quickly spot overdue pickups without confusing them with reservations.
Original PR description
Before this commit: - The colors assigned to late pickup and reserved status orders were the same, leading to confusion. After this commit: - Distinct colors have been assigned for late pickup and reserved status orders. Task-4154459
Odoo can now receive webhook notifications from OdooFin when important account synchronization information changes. This helps keep customer databases more up to date, starting with faster updates for authorization expiry dates.
Original PR description
… and OdooFin Adds webhook event support on Odoofin. With this addition, we can now update user's database in real-time when relevan, therefore drastically reduce the cases where Odoo and OdooFin are not synchronized or when data are not up-to-date. For now the only supported type is `update_auth_exp_date` which notify the Odoo clients that they need to fetch their authorization expiring date. task-3822526
Documents now reopen in the last view mode each user selected, either kanban or list, making daily document work feel more consistent. On mobile, the experience continues to default to kanban for usability.
Original PR description
Keeping the user preferred view mode (only kanban or list) to view their documents. The preferred mode is set to be the last one selected via the view switcher. Not applied in mobile environments (defaults on "kanban"). Task-4305989
Point of sale users in Chilean and Ecuadorian electronic invoicing can now keep browsing partner lists without manually triggering more results. This makes it easier to find customers in large databases and keeps the checkout workflow smoother.
Original PR description
Load new partner when scroll reach the bottom of the list Taskid: 4028885
Helpdesk email-related tests have been reorganized into a dedicated area and enhanced to better verify generated email content and flows. This makes future changes to helpdesk email handling safer and easier to validate, with no direct user-facing behavior change.
Original PR description
Just to have them a bit more standard and in a specific file. This is going to ease future changes.
Resolved issues and error corrections
Restaurant staff will now see the correct booking time on the point-of-sale floor screen instead of an "Invalid time" message. This helps teams manage table reservations more accurately during service.
Original PR description
Steps:
===
- Install the pos_restaurant_appointment module.
- Open a session for the restaurant.
- Create a booking for a table.
- Open the floor screen and check the booked table.
- It shows "Invalid time" instead of the correct booking time.
Fix:
===
- Replaced deserializeDateTime(date) with direct date.toFormat("HH:mm") to correctly format and display the booking time.
To Be:
===
- Ensure that the booking time are displayed accurately on the floor screen.
task-4438700Recruitment reports now identify duplicate applications using the same email or phone matching rules as candidate records. This makes the “Exclude Duplicates” filter more accurate by keeping only the most recent application for matching candidates and also fixes duplicate report record identifiers.
Original PR description
The "Exclude Duplicates" filter used to mark applications as duplicate if they are of the same candidate.
The logic is now changed to match the _get_similar_candidates_domain() that is used in the hr.candidate.
Candidates that have the same email or phone are considered duplicates. The filter will show only the recent application among those marked as duplicate.
I also fixed an issue with the query assigning duplicate IDs for the hr.recruitment.stage.report records.
[Task-4437824](https://www.odoo.com/odoo/project.task/4437824)Code cleanup and technical improvements
Mail-related flows now use a shared approach to find or create contacts from email addresses, reducing duplicated behavior across apps. This should make suggested recipients and customer contact creation more consistent in areas like Helpdesk, Appointments, Documents, Sign, HR, and Studio.
Original PR description
In order to unify methods searching or creating partners, let us create yet another one. Introducing '_partner_find_from_emails' that should act as the main find, sort and create partner record-based tool method. This leads to cleaning various mail methods, notably some often inherited in modules like '_get_customer_information' and '_message_get_suggested _recipients'. See community PR for more details. Task-4332797 [mail] Partner from emails 3.0 Prepares Task-4273479: [mail] Email-like recipients
The point-of-sale IoT payment terminal integrations have been reorganized so each provider is handled separately. This makes the system easier to maintain and reduces the risk of provider-specific changes affecting other terminals.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/190853 Upgrade PR: https://github.com/odoo/upgrade/pull/6943 Before this PR, `pos_iot` contained the Worldline and Ingenico payment providers. A further module `pos_iot_six` contained the Six payment provider. On the JS side, there was a long chain of inheritance: `PaymentSix` extends `PaymentWorldline` which extends `PaymentIngenico` which extends `PaymentInterface`. This made it difficult to reason about the code that was actually being run for each payment terminal. After this PR, each payment provider is in a separate module: - `pos_iot` provides the framework but doesn't add any payment providers - `pos_iot_ingenico` - `pos_iot_worldline`, - `pos_iot_six` The JS code has undergone a refactor at the same time as they no longer inherit from each other. task-4398016
Miscellaneous changes
Before this commit: Post including long links were not truncated and will extend beyond the kanban card. This happen as the display CSS property is set to `inline` by default due to the <field> tag being transformed into a <span> tag in the HTML. <div> default display is `block` while <span> are `inline`. After this commit: The link truncate as intended with "..." Before: ![Screenshot from 2025-01-08 15-44-37](https://github.com/user-attachments/assets/b056e615-5ca7-4312-8211-2d11f65d4
Original PR description
Before this commit: Post including long links were not truncated and will extend beyond the kanban card. This happen as the display CSS property is set to `inline` by default due to the <field> tag being transformed into a <span> tag in the HTML. <div> default display is `block` while <span> are `inline`. After this commit: The link truncate as intended with "..." Before:  After:  opw-4446906 Forward-Port-Of: odoo/enterprise#76719
Steps to reproduce: 1.) Create a trial db 18.0 2.) Install website and helpdesk 3.) Create a second company (two companies, one website, may have to delete a website) 4.) Navigate to a Team in 'Helpdesk / Teams' with company B 5.) Enable 'Website Form' 6.) Use 'Go to Website' smart button 7.) We get an access error - Remove multi_website group and add conditional to stat button Forward-Port-Of: odoo/enterprise#76268
Original PR description
Steps to reproduce: 1.) Create a trial db 18.0 2.) Install website and helpdesk 3.) Create a second company (two companies, one website, may have to delete a website) 4.) Navigate to a Team in 'Helpdesk / Teams' with company B 5.) Enable 'Website Form' 6.) Use 'Go to Website' smart button 7.) We get an access error - Remove multi_website group and add conditional to stat button Forward-Port-Of: odoo/enterprise#76268
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in th
Original PR description
### Before this PR: - The `Search in Sales Order` and `Sales Order` options were always visible in the Helpdesk ticket portal search bar, regardless of the configuration of the `use_helpdesk_sale_timesheet` field in the Helpdesk Team. - This led to confusion for users who did not utilize sales orders in their helpdesk workflows. ### After this PR: - The `Search in Sales Order` and `Sales Order` options are now only displayed when the `use_helpdesk_sale_timesheet` field is set to true in the Helpdesk Team configuration. task-4224818 Forward-Port-Of: odoo/enterprise#76850 Forward-Port-Of: odoo/enterprise#71516
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priorit
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priority before this commit: partner email > parent partner email > partner DTE email > parent partner DTE email ### Solution: Change the order to display the DTE email if possible: Order of priority after this commit: partner DTE email > parent partner DTE email > partner email > parent partner email opw-4288781 Forward-Port-Of: odoo/enterprise#76600 Forward-Port-Of: odoo/enterprise#75917
Scenario: - Install l10n_pe_edi and switch to "PE Company" - Create a product with "Withhold Percentage" 20% - Create an invoice with operation type "[1001] Operation Subject to Detraction", the created product and USD currency. - Print the invoice as PDF => The "Withholding amount" in the PDF is correctly shown in the company currency, but the currency symbol is the one of the invoice ($) Issue: Amount is always in the company currency, and currency is the invoice currency th
Original PR description
Scenario: - Install l10n_pe_edi and switch to "PE Company" - Create a product with "Withhold Percentage" 20% - Create an invoice with operation type "[1001] Operation Subject to Detraction", the created product and USD currency. - Print the invoice as PDF => The "Withholding amount" in the PDF is correctly shown in the company currency, but the currency symbol is the one of the invoice ($) Issue: Amount is always in the company currency, and currency is the invoice currency that might be different. Fix: currency_id gotten from account.move()._l10n_pe_edi_get_spot is only used in this location where the amount should always be the company currency: so we modify it to be the company currency. opw-4292774 opw-4338728 Forward-Port-Of: odoo/enterprise#76334
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
Original PR description
steps: - create an invoice with a customer that has the `ref` set to some value - send this invoice to DIAN -> We get an error back saying the xml is incorrect Solution: Although DIAN accepts eInvoices based on UBL 2.1, it throws an error when it receives an xml file with a cbc:BuyerReference tag. To fix this we now just leave out the tag from the xml file ticket: 4367849 Forward-Port-Of: odoo/enterprise#76548
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76749 Forward-Port-Of: odoo/enterprise#76557
Original PR description
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76749 Forward-Port-Of: odoo/enterprise#76557
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have
Original PR description
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have the correct year. We also took the time to replace the usage of Date of plain javascript with DateTime of the luxon library. Forward-Port-Of: odoo/enterprise#76645 Forward-Port-Of: odoo/enterprise#76606
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forw
Original PR description
Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forward-Port-Of: odoo/enterprise#76660 Forward-Port-Of: odoo/enterprise#76524
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the
Original PR description
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would…
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the top. Which means that for certain resolutions the element selected is the whole body instead of the correct paragraph/text node. Now, the coordinates are computed so that we are indeed at the center of the rect. ## [FIX] knowledge: avoid opening new comments on click This commit fixes an issue with the knowledge comments small UI. When you create a comment in small UI and click on the overlay in the body of the article, the newly created comments open its popover. This behavior shouldn't happen in any circumstances except when in readonly mode. task-4463401 Forward-Port-Of: odoo/enterprise#76709
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684 Forward-Port-Of: odoo/enterprise#76064
Original PR description
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684 Forward-Port-Of: odoo/enterprise#76064
…to load Open a pivot view via an "anonymous" action, that is via a method of a model or something else. Open studio Close Studio Before this commit, we ended up with just an empty studio screen, obviously broken. This is the aftermath of odoo/enterprise@78599bd1b564fe0c64210ebcb90803b75f55755a where some use cases were left untreated. After this commit, use cases like this one fallback to either the closest action that has a chance to work -- this logic is driven by the action_serv
Original PR description
…to load Open a pivot view via an "anonymous" action, that is via a method of a model or something else. Open studio Close Studio Before this commit, we ended up with just an empty studio screen, obviously broken. This is the aftermath of odoo/enterprise@78599bd1b564fe0c64210ebcb90803b75f55755a where some use cases were left untreated. After this commit, use cases like this one fallback to either the closest action that has a chance to work -- this logic is driven by the action_service -- or to the home menu if really we did not guess hard enough. Forward-Port-Of: odoo/enterprise#76651
…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by
Original PR description
…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by simply returning early when the asset's residual amount is zero. A test is also added to cover this use case. opw-4411877 Forward-Port-Of: odoo/enterprise#76733 Forward-Port-Of: odoo/enterprise#76555
Adapt the `get_limited_partners_loading` method to the new API. Forward-Port-Of: odoo/enterprise#76821
Original PR description
Adapt the `get_limited_partners_loading` method to the new API. Forward-Port-Of: odoo/enterprise#76821
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Original PR description
In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality checks are filtered using “search_default_lot_id = active_id”, which means only quality checks linked to th
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality checks are filtered using “search_default_lot_id = active_id”,
which means only quality checks linked to the “search_default_lot_id”
are displayed. However, in this usecase, the "lot_id” is not set.
Instead, the "finished_lot_id" is used, causing the quality checks to be
hidden unless the filter is removed.
Solution:
the domain is properly prepared so no longer needs this filter: https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L23-L27
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L20-L21
https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_mrp_workorder/models/stock_lot.py#L10-L13
opw-4361358
Forward-Port-Of: odoo/enterprise#76376After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'accoun
Original PR description
After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'account.fiscal.position' object has no attribute 'filter_multi_company'` opw-4376837 Forward-Port-Of: odoo/enterprise#76492
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.ht
Original PR description
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.html#LOCKING-ROWS See https://github.com/odoo/enterprise/pull/74078#discussion_r1873729342 taskid: 4391755 Forward-Port-Of: odoo/enterprise#76619
In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758 Forward-Port-Of: odoo/enterprise#73886
Original PR description
In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758 Forward-Port-Of: odoo/enterprise#73886
The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3 Forward-Port-Of: odoo/enterprise#76558
Original PR description
The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3 Forward-Port-Of: odoo/enterprise#76558
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment. Forward-Port-Of: odoo/enterprise#76809
Original PR description
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment. Forward-Port-Of: odoo/enterprise#76809
In this commit: - After accepting a delivery order, a countdown timer appears, indicating the preparation time. This timer counts down, providing the user with a timeline to prepare the order within the allotted time.  task-4049465 Forward-Port-Of: odoo/enterprise#76721 Forward-Port-Of: odoo/enterprise#73620
Original PR description
In this commit: - After accepting a delivery order, a countdown timer appears, indicating the preparation time. This timer counts down, providing the user with a timeline to prepare the order within the allotted time.  task-4049465 Forward-Port-Of: odoo/enterprise#76721 Forward-Port-Of: odoo/enterprise#73620
1 change
Enhancements to existing features
This update expands the ability to automatically create tasks and projects linked to sales orders. Previously, these were only generated for the entire order. Now, the system can generate them on a line-by-line basis within the order, offering greater flexibility for managing subscription services.
Original PR description
This allows to customize the ability to generate a task and/or project per sale.order.line instead of per order only.