Daily updates from Odoo
Wednesday, October 23, 2024
86 changes · 18.0
Enhancements to existing features
Italian partners now automatically use FatturaPA as their preferred electronic invoicing format. Spanish partners correctly default to Facturae when a certificate exists, improving invoice setup while avoiding errors when no certificate has ever been configured.
Original PR description
…S/IT Add FatturaPA as the preferred EDI format set by default on Italian partners. Fix the preffered EDI format of Spanish partners to be correctly computed to Facturae. task-no
The manufacturing order overview no longer shows the MO Cost column once a production order is marked as done. This keeps completed production reports focused on relevant information and avoids exposing cost details after completion.
Original PR description
This commit hides the MO Cost column of MO overview report if the underlying MO is done. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale now selects an order line only when a cashier has just added a product, and clears selections when reopening orders from areas such as tables, tickets, or payments. This makes the numpad and order editing behavior more predictable, reducing accidental changes during checkout or restaurant workflows.
Original PR description
-Select order line only when I've just added a product to cart -Ensure that no order line is selected anymore when opening an order (from floorplan, table selector, ticket screen, payment screen) -Adapt tours tests to match this new behavior and limit the use of 'inLeftSide' to avoid going uselessly back and forth to the product list in mobile task-id: 4167563 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 web interface now makes tag editing behave more consistently by limiting this option to form views and giving it priority over color editing when both are configured. Users also get clearer visual feedback through a pointer cursor when tags can be edited.
Original PR description
This commit slightly changes the behavior of the m2m edit_tags option so that it will only be effective in form view (like tag color edition) and also so that it will override color edition when color_field is set. It also adds visual feedback with the pointer style when the edit_tags option is set. task-3961350
Calendar now avoids creating extra settings records for portal users when the needed relationship is not available. If no settings are found, it uses the default privacy from the standard user template, helping keep user data cleaner and behavior consistent.
Original PR description
This commits forbids creating res_users_settings records when the inverse is not defined. During the computation, if the settings are not found, we fallback in the default privacy of the Default User Template. To be discussed with P.O. and Team Leader. task-4260834
The point of sale UrbanPiper integration now creates the store location in Atlas when a user selects Create Store. This reduces manual setup work and helps keep store information aligned between Odoo and Atlas.
Original PR description
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144
Resolved issues and error corrections
This fix restores shared sales logic needed when re-invoicing expenses without the Project app installed. It prevents errors in expense posting flows where costs, such as mileage, are billed back to customers through sales orders.
Original PR description
This fixes issues that arose since 238a41e3 By moving the `_prepare_analytic_account_data` method from sale to sale_project, any call to this method in sale_expense would break as sale_expense doesn't depend on project. Because this method is crucial in the re-invoicing flows we need it in sale. Steps to reproduce: - Install sale_expense without project - Run the sale_expense tests or test the flow manually (create an expense with mileage as a product, add a sale order to reinvoice it on and move forward to post the expense sheet) - _prepare_analytic_account_data is missing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change restores the previous behavior for required selection fields so users are not shown a first option that appears selected but is not actually saved. It prevents confusion and data entry mistakes in forms that rely on required dropdown choices.
Original PR description
This reverts commit eec86a3fda555f3939d6773f4c79ca6b3636228a. This commit introduced an unexpected behaviour where the field seems to select by default the first choice but has no value.
This fixes a display issue where mobile guests joining a public channel saw a broken placeholder instead of the Add a Reaction icon. The reaction button now appears correctly, improving the chat experience for invited public users.
Original PR description
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays correctly. Related enterprise: [enterprise/ #72507](https://github.com/odoo/enterprise/pull/72507) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a sales order with a project-generating service is duplicated, the existing project and related analytic allocation are no longer copied to the new order. This prevents confusion and ensures the correct project is created when the duplicated order is confirmed.
Original PR description
Steps: Activate analytic accounting. Create a SO with a service that creates a project. Confirm. The project that has just been created is now set on the SO. Duplicate. Issue: The project is duplicated too. Yet is doesn't correspond to the the one that will be created upon confirmation. Solution: Simply not duplicated the project upon SO duplication. task-4207182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now change a company’s Chart of Accounts without being blocked by an unnecessary accounting permissions error. This prevents disruption when configuring invoicing for localized companies and keeps setup workflows moving smoothly.
Original PR description
Install account and a localization (i.e. l10n_ar)
Switch to Company "(AR) Exento"
Open Settings>Invoicing
Change current Chart of Account to something else
Save
Error will block the action
This operation is allowed for the following groups:
- Technical/Show Full Accounting Features
Contact your administrator to request access if necessary.
This occurs because the permissions necessary to write on the
AccountReconcileModelLine are loaded when installing module `accountant`
opw-4227071Invoices with early payment discounts remain eligible for the discount when a payment is registered and later matched in bank reconciliation. This ensures the reconciliation suggestion includes the expected discount write-off, reducing manual corrections for accounting users.
Original PR description
Steps to reproduce: - Create an invoice with early payment discount applicable - Register a payment on the invoice (must be without a journal entry associated, done by default) - Open the bank reconciliation widget - Create a statement line with the discounted amount (invoice total - epd amount) - The suggested reconciliation doesn't include a new line with the write-off of the early payment discount Cause of the issue: When registering a payment on the invoice, the invoice payment state switch from 'not_paid' to 'in_payment', which makes this invoice not eligible anymore for early payment discount. task-4237657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saved export templates now reload fields in the same order users originally chose, instead of sorting them by internal field names. This makes repeated exports more predictable and helps avoid confusion or manual reordering when using saved templates.
Original PR description
Issue When loading a template of fields to export, the list of fields is ordered by their technical name and not by their actual position in the list when the template was saved. Cause issue since e3647790830f95de932cb10c39a8232dd97e4221 The `ir.exports.line` are in order of their position in the list at creation in `export_fields`, however `fields_info` sorts the fields by their technical name and may not preserve order https://github.com/odoo/odoo/blob/e3647790830f95de932cb10c39a8232dd97e4221/addons/web/controllers/export.py#L409 opw-4241915
Cloud storage attachments now align with the updated mail upload behavior, preventing upload handling errors when files are stored externally. This helps keep attachment uploads reliable for Azure and Google cloud storage users.
Original PR description
Store now returns `ir.attachment` and not `Attachment` as model name. Note: post kwargs backed-ported fix at https://github.com/odoo/odoo/pull/184506 opw-4260378
This fix prevents a rare crash when Odoo records tax-related changes and the previous logged value is blank. It helps ensure invoice tax updates, including Brazil localization tax scenarios, complete without interrupting users.
Original PR description
In rare cases, the message logging code on account.tax can crash. To reproduce, apply https://github.com/odoo/odoo/pull/184390 and set up a new database with `-i l10n_br_edi,accountant` and then: 1/…
In rare cases, the message logging code on account.tax can crash. To reproduce, apply https://github.com/odoo/odoo/pull/184390 and set up a new database with `-i l10n_br_edi,accountant` and then:
1/ Create a new invoice
2/ Set customer "BR Company Customer Estimated Profit",
3/ Add line with “Regular Consumable Product”,
4/ Switch the fiscal position to Avatax Brazil,
5/ Compute Taxes,
6/ Add line with “Added Taxes Consumable Product”,
7/ Compute Taxes,
Traceback:
```
...
File ".../addons/account/models/account_tax.py", line 423, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File ".../addons/account/models/account_tax.py", line 353, in _message_log_repartition_lines
old_line_values_dict = ast.literal_eval(old_values_str)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../odoo/_monkeypatches/literal_eval.py", line 28, in literal_eval
return orig_literal_eval(expr)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/ast.py", line 66, in literal_eval
node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/ast.py", line 52, in parse
return compile(source, filename, mode, flags,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<unknown>", line 0
SyntaxError: invalid syntax
```
Alternatively, the following shell code reproduces the issue as well on the same database:
```
from odoo import Command
br_company = env['res.company'].search([('name', '=', 'BR Company')])
active_tax = env['account.tax'].search([('name', '=', '3% COFINS')])
move = env['account.move'].with_company(br_company).create({
'move_type': 'out_invoice',
'invoice_line_ids': [
Command.create({
'price_unit': 100,
'tax_ids': [Command.set(active_tax.ids)],
})
],
})
inactive_tax = env['account.tax'].with_context(active_test=False).search([('name', '=', 'ICMS ST Excl.')])
inactive_tax.active = True
env['account.move.line'].with_company(br_company).create({
'move_id': move.id,
'price_unit': 100,
'tax_ids': [Command.set(inactive_tax.ids)],
})
env.cr.flush()
```
opw-4239515This update fixes an internal test setup issue so web JSON tests run correctly when optional demo data is not loaded. It helps keep automated quality checks reliable without changing the product experience for users.
Original PR description
Description of the issue/feature this PR addresses: Need to setup the user and enable the /json route when running tests with nodata because by default the route is not enabled. 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 Manufacturing app now uses the clearer label “Highlight Consumption” instead of “Manual Consumption” on bill of materials components. This prevents confusion for users configuring BOM component consumption settings.
Original PR description
To reproduce: - Create new BOM - In the components tab, enable the column manual consumption Current behavior: 'Manual Consumption' Expected behavior: 'Highlight Consumption' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A purchase order test was corrected to stop using a field that is not available on the purchase order form. This helps keep automated checks reliable and prevents false failures in the purchase workflow validation.
Original PR description
This commit addresses an issue caused by incorrect value assignment to the `incoterm_id` field, which is not present in the purchase order form view. Additionally, the field `incoterm_location` is added from the purchase_stock module, not the purchase module. error :- https://runbot.odoo.com/web#id=75128&view_type=form&model=runbot.build.error&menu_id=405&cids=1
Regular users can now leave a parent discussion that has sub-threads without hitting an access error. This prevents an unexpected crash in team conversations and keeps the leave action working consistently for non-admin users.
Original PR description
This commit fixes the following issue in the sub-thread behavior. Steps to reproduce: - Create a thread as non admin user and add another member - Create a sub-thread - Go to the parent thread and type `/leave` command - You see the access error
This fix updates several automated guided workflow checks so they correctly recognize pop-up windows during key business processes. It helps keep quality testing stable for manufacturing, inventory batch picking, sales product configuration, and main Odoo flows, reducing the risk of regressions reaching users.
Original PR description
In this commit, we fix few steps where .modal is missing. 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
Public channel invitations now open to the welcome page first on mobile devices instead of immediately showing the conversation thread. This gives invited users the intended onboarding experience before they enter the channel.
Original PR description
**Current behavior before PR:** Opening a public channel invitation on mobile showed the thread instead of the welcome page because ui.isSmall triggered the thread to open over it. Before / After <p> <img src="https://github.com/user-attachments/assets/4665efff-3732-4613-a04b-ac78105467d1" width="200px" /> <img src="https://github.com/user-attachments/assets/34225a7b-f07e-42f7-ac8e-f8fdf5f8b710" width="200px" /> </p> **Desired behavior after PR is merged:** This PR ensures that the welcome page is displayed first. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The payment confirmation action now only applies to payments that are still in draft. This prevents users from accidentally moving already paid payments back to an in-process status when confirming multiple selected payments.
Original PR description
This fixes issues that arose since 2609fc2 The confirm button (action_post) on the list view of payments allows to move the payment state one step back from `paid` to `in_process` We now only consider payment in draft when doing so, to keep all other payments mistakenly selected intact Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue where mobile guests joining a public channel saw an empty placeholder instead of the Add a Reaction icon. The change improves the chat experience by making the reaction action clear and usable for invited guests.
Original PR description
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays correctly. Related : [odoo/ #184552](https://github.com/odoo/odoo/pull/184552)
The Timesheets grid view now returns users to their previous scroll position after they switch away and back. This prevents unnecessary scrolling and makes navigation consistent with other views.
Original PR description
Steps to Reproduce: - Open All Timesheets in Timesheets app. - Scroll down in the grid view - Change view using view switcher Issue: - You can see that grid view starts at the top. - It is not the case in other views. Fix: - Adding root reference in useSetupAction Reason: - When a root reference is added it scrolls down the page to its previous state. task-4010043
This fixes an automated barcode test that could fail unpredictably when several serial numbers were scanned too quickly. The change makes the test process those scans in the correct order, improving confidence in stock barcode validation without changing user-facing behavior.
Original PR description
In the `test_serial_product_packaging` tour, we scan 4 different serial numbers without waiting which can cause race condition (in case a scanned SN is finished to be processed before the previous scanned SN.) To fix that, two solutions: - Update each trigger to wait the result of previous scan; - Scan all SN as one single barcode, which force them to be processed in the right order. Second option is used by this commit since it's simplier. runbuild error: 99539
Accounting reports now open correctly even when a company has no journals available. In that case, the journal filter clearly shows "No Journal" and cannot be clicked, preventing confusion and interruptions.
Original PR description
We we tried to open the report with a company without journal and that the report had journal filter set, it would crash. The goal is to set the label of the filter explicitely to "No Journal" and make the filter unclickable when this is the case. task-4267503
The helpdesk portal timesheet table now hides the task column when entries are grouped by task or helpdesk ticket. This prevents mismatched columns and makes grouped timesheet views easier for customers and support teams to read.
Original PR description
### Before this PR: - The task column data was visible even when timesheets were grouped by task_id or helpdesk_ticket_id. - This caused misalignment in the table when grouped by these fields. ### After this PR: - The task column is hidden when timesheets are grouped by task_id or helpdesk_ticket_id. - The table headers is now correctly aligned. task-4184455
The shop floor now shows the 'Install App' button only when choosing which work centers appear in the view. This avoids confusing operators with an unrelated option when they are simply moving a work order to another work center.
Original PR description
To reproduce: - Open shop floor - Go to Assembly 1 and click on the gear icon on a work order card - Select Move to work center Current behavior: The 'Install App' button is displayed. Expected behavior: The 'Install App' button is only displayed when selecting the workcenters that should be shown in the view, not when moving a work order to another workcenter.
Fixed an issue that caused the appointment table preview to crash when users selected the number of people while timezone display was disabled. This keeps the booking flow usable and prevents an unexpected error in the appointment demo and related scheduling pages.
Original PR description
**How to reproduce:** - Go to 'Table' demo data - Select Number of people **Technical reason:** When the 'show timezone' is turned off, code is accessing the value of an undefined element, resulting in a traceback. Introduced by: https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c **After this commit:** The traceback will be resolved. Task-4269449
The manufacturing screen in the barcode app now shows production order cards in a cleaner layout. Quantities appear under the finished product name, making orders easier to read for warehouse and manufacturing users.
Original PR description
To reproduce: - Create MO for 10 units of drawer - Open barcode app - Go to operations > manufacturing Current behavior: Strange layout of the MO card. Expected behavior: Proper layout with qty under the name of the final product.
Features or functions removed from Odoo
This change removes the behavior that copied calendar default privacy settings from the default user template when creating users. It simplifies calendar user setup and avoids potential performance and usability issues that needed further product review.
Original PR description
This PR drops the feature of copying of the Calendar Default Privacy field from the Default User Template in the modules `calendar` (full feature) and `microsoft` (only tests). To be discussed with the PO and Team Leader the drawbacks of keeping it and dropping it. Performance regarding _compute and _invert methods and also usability of the feature. task-4260834
The calendar event page no longer shows a separate "More Options" button because the same action is already available through the standard web menu. This reduces duplicate controls and keeps the appointment experience cleaner for restaurant bookings.
Original PR description
This PR will remove the "More Options" button from the calendar event page, because there is a generic web option that performs the same task. **Technical** As we cannot remove the views in the stable version so this PR will just remove the more option button. The rest of the footer and the inherited calendar event view of pos_restaurant_appointment will be removed from the master Task-4246277
Miscellaneous changes
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184744 Forward-Port-Of: odoo/odoo#184152
Original PR description
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184744 Forward-Port-Of: odoo/odoo#184152
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when us
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be…
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Outlook, it will be correctly synchronized in Outlook as well. This approach will also reduce the possibility of duplicated events in Odoo side (and by transitivity, in Outlook side). task-4261237 Forward-Port-Of: odoo/odoo#184777 Forward-Port-Of: odoo/odoo#183926
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba">
Original PR description
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba"> Desired behavior after PR is merged: <img width="450" alt="Screenshot 2024-10-10 at 11 04 51 PM" src="https://github.com/user-attachments/assets/40f531a8-0d79-4eb6-a3d6-cd80abcb145c"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183280
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#184359 Forward-Port-Of: odoo/odoo#183359
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#184359 Forward-Port-Of: odoo/odoo#183359
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , java
Original PR description
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed…
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , javascript will create it at time 00:00 in the UTC timezone, so for users with negative timezone offset (GMT-x), `formatDate` will print the the date as one day behind. It’s the case for American users for instance. Now, we create the date using `DateTime.fromISO(yyyy-mm-dd)`, it will be created at 00:00 in the local time zone (not the UTC timezone anymore), and printing it with `formatDate` will therefore yield the correct value expected by the user. opw-4116982 Forward-Port-Of: odoo/odoo#184779 Forward-Port-Of: odoo/odoo#182933
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Original PR description
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Steps --- * install `mrp`, `purchase` * create the following products: * P, storable, route = manucfature, bom: * C storable (qty = 1) * K storable, (qty = 1) kit bom: * C (qty = 1) * set the quantiy on hand for C to 1 * create a purchase order for 20 C * create an MO for 5 P > *Confirm* * in the overview we have 2 component line (each for C), but the 2nd line's status is *To Order* even though we already have a PO. if we look at the d
Original PR description
Steps
---
* install `mrp`, `purchase`
* create the following products:
* P, storable, route = manucfature, bom:
* C storable (qty = 1)
* K storable, (qty = 1) kit bom:
* C (qty = 1)
* set the quantiy on hand for C to 1
* create a purchase order for 20 C
* create an MO for 5 P > *Confirm*
* in the overview we have 2 component line (each for C), but the 2nd
line's status is *To Order* even though we already have a PO.
if we look at the details of the first line, we can see the replenishment
for the second line was wrongly assigned to the first.
Cause
---
When matching replenishments to bom line moves, we check if quantity
from the replenishments is enough for the move, if so we go on to the
next move. But when we do this we do not account for pre-reserved
quantity of partially available moves.
opw-4128775
Forward-Port-Of: odoo/odoo#184703
Forward-Port-Of: odoo/odoo#178261Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184069 Forward-Port-Of: odoo/odoo#183566
See the +7 that was italics before Before / After <img width="73" alt="Screenshot 2024-10-21 at 20 55 17" src="https://github.com/user-attachments/assets/3754e36b-5ade-4c28-991c-f3f73cc74d2c"> <img width="61" alt="Screenshot 2024-10-21 at 20 52 36" src="https://github.com/user-attachments/assets/3933af74-8e51-4c0e-8309-2ebbca303bda"> Forward-Port-Of: odoo/odoo#184623
Original PR description
See the +7 that was italics before Before / After <img width="73" alt="Screenshot 2024-10-21 at 20 55 17" src="https://github.com/user-attachments/assets/3754e36b-5ade-4c28-991c-f3f73cc74d2c"> <img width="61" alt="Screenshot 2024-10-21 at 20 52 36" src="https://github.com/user-attachments/assets/3933af74-8e51-4c0e-8309-2ebbca303bda"> Forward-Port-Of: odoo/odoo#184623
Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a defau
Original PR description
Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a default rule, we skip the test if account is not present but hr.timesheet is. runbot-100530 Forward-Port-Of: odoo/odoo#184067
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interac
Original PR description
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 ->…
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interaction will fail which includes: - some payment method callback (Adyen, Vivawallet) - IoT printing requests - chatter messages ... Reasons of the issue: The issue happen as the websocket use a shared workers and certain operation (like here opening self-order), will interupt the current websocket to open a new one on which previously subscribed channel will be missing (explaining why the PoS session won't sync orders). The shared worker decided to interupt the previous websocket and create a new one as the "db" information was missing from the `session_info`, see: https://github.com/odoo/odoo/blob/dfdea9704a13c259cc1d49d6bd3a3fa4d93307b6/addons/bus/static/src/workers/websocket_worker.js#L257 After this commit: PoS orders continue to sync even if the kiosk view is opened on the same browser session opw-4233060 Forward-Port-Of: odoo/odoo#184393 Forward-Port-Of: odoo/odoo#183527
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#184708 Forward-Port-Of: odoo/odoo#183993
Original PR description
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#184708 Forward-Port-Of: odoo/odoo#183993
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and Start the repair - try to end the repair **Problem:** A traceback is triggered: “raise ValueError("Expected singleton: %s" % self) Value Error: Expected singleton: stock.location() “ When the "action_repair_end" is called, a move is created with the kit product, and
Original PR description
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and…
**Steps to reproduce the bug:**
- Create a consumable product “Kit 1” with the following BoM:
- component: X1
- Create a repair order to repair one unit of Kit 1:
- Don’t add any part
- confirm and Start the repair
- try to end the repair
**Problem:**
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“
When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80
Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74
So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94
The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052
If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:
“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“
opw-[3942297](https://www.odoo.com/web#id=3942297&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#173306
Forward-Port-Of: odoo/odoo#168227The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: od
Original PR description
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: odoo/odoo#183446 Forward-Port-Of: odoo/odoo#183180
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetche
Original PR description
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical"…
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetched (no fetching of unnecessary emails) * Email are marked as read after processing and NOT deleted Drawbacks of POP protocol that most end users are not necessarily aware of: * After fetching emails are deleted on the fetched mail server, i.e. no hard copy of the original mail is kept which might be an issue if a bug in Odoo fetches the mail "correctly" (routing succeeded), but a downstream bug creates side effects (attachments deleted, wrong record creted) * Since POP will try to fetch ALL mails in the inbox, if the customer (un)purposely hoards Odoo unrelated emails, these will be always fetched but never routed -> time spend for nothing routing, logs are spammed and percieved delay for fetching new emails (since older ones are processed for nothing over and over again) Proposed solution: Change `default` parameter to `imap` argument. Will not change old records ad-hoc, but preset new incoming email servers. User is free to still change the server type if they feel the need to use the POP protocol. Recent support tickets with related issues: OPW-4206157 OPW-4229682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183712
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`.
Original PR description
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the…
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`. __Description of the fix:__ The `t-nocache` is put directly inside the header templates in order for all subsequent `t-set` to be accessible from its scope. __Example of steps to reproduce the issue on runbot:__ 1. On the website, click on the search button inside the header 2. Type "desk" for example No results are shown below the search box although when hitting ENTER, there are some results. This is due to the fact that the searchbox input lacks the `search_type="all"` attribute. opw-4246129 [1]: https://github.com/odoo/odoo/pull/180548 Forward-Port-Of: odoo/odoo#183465
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#184533 Forward-Port-Of: odoo/odoo#157362
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#184533 Forward-Port-Of: odoo/odoo#157362
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
Original PR description
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
Consider the Inter-Company transit location (which is a 'transit' location with no company set) as either a 'customer' or 'supplier' location for dropship purposes. Both 'supplier' and 'customer' need to be considered as the dropship could be either from Vendor -> Other Company or Other Company -> Customer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184090 Forward-Port-Of: odoo/odoo#183190
Original PR description
Consider the Inter-Company transit location (which is a 'transit' location with no company set) as either a 'customer' or 'supplier' location for dropship purposes. Both 'supplier' and 'customer' need to be considered as the dropship could be either from Vendor -> Other Company or Other Company -> Customer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184090 Forward-Port-Of: odoo/odoo#183190
Prior to this commit, the phone field was used to send SMS, which could be incorrect. Enterprise PR: https://github.com/odoo/enterprise/pull/72449 opw-4273085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184660
Original PR description
Prior to this commit, the phone field was used to send SMS, which could be incorrect. Enterprise PR: https://github.com/odoo/enterprise/pull/72449 opw-4273085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184660
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtua
Original PR description
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtual moves with values and mark them as modified. This causes them to eventually get invalidated and they aren't saved once the update (overwrite) resolves. **Fix:** Don't update virtual moves (records without an _origin). opw-4120108 Forward-Port-Of: odoo/odoo#182606
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-410782
Original PR description
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-4107823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180163
Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
Original PR description
Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component 4 - Create a Mo for one unit of P1 - Confirm the MO - Update the BoM of P1: - Delete Component 2 - Go back to the MO - Refresh the page - Click "Update from BoM" Problem: Only the move for Component 1 is retained. The moves for Compon
Original PR description
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component…
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Components:
- Component 1
- Component 2
- Kit (which has its own BoM)
- BoM of the kit:
- Component 3
- Component 4
- Create a Mo for one unit of P1
- Confirm the MO
- Update the BoM of P1:
- Delete Component 2
- Go back to the MO
- Refresh the page
- Click "Update from BoM"
Problem:
Only the move for Component 1 is retained. The moves for Components 2 (which were deleted) and for Components 3 and 4 (which belong to the kit) are removed, while the kit should be decomposed into its own components (3 and 4) and their moves retained.
The current logic did not handle kit products properly when updating the MO. It only compared the components at the top level of the BoM, ignoring the fact that kits contain their own components. As a result, the moves corresponding to the kit's components were not detected and were deleted when updating the MO.
opw-4247193
Forward-Port-Of: odoo/odoo#184329
Forward-Port-Of: odoo/odoo#183638**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058
Original PR description
**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058770 Forward-Port-Of: odoo/odoo#179639
The code comment says non-internal users should not have access to has_group if it's not for themselves. But the code checked the group of the targetted user, not the current user. Added test failed without fix failed because an AssertError was not raised, and an AssertError was raised when it should not have. note: found when reviewing 18.0 forward-port of d0828eecf60f7c8622d6875b opw-4096073 Forward-Port-Of: odoo/odoo#184561 Forward-Port-Of: odoo/odoo#184207
Original PR description
The code comment says non-internal users should not have access to has_group if it's not for themselves. But the code checked the group of the targetted user, not the current user. Added test failed without fix failed because an AssertError was not raised, and an AssertError was raised when it should not have. note: found when reviewing 18.0 forward-port of d0828eecf60f7c8622d6875b opw-4096073 Forward-Port-Of: odoo/odoo#184561 Forward-Port-Of: odoo/odoo#184207
Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatti
Original PR description
Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatting is applied, but the `.o_default_snippet_text` class remains on the element. 5. Save and re-edit 6. Click on the title -> The text is entirely selected because it's still treated as a default text. This commit ensures the correct behaviour of this feature. task-4147162 Forward-Port-Of: odoo/odoo#183179
Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. St
Original PR description
Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. Steps to reproduce: - Open any page with the web editor. - Add text with part of it formatted as a link. - Try toggling any style (e.g., bold, italic). - The style is applied but cannot be reverted, and the button state remains off. opw-4213717 Forward-Port-Of: odoo/odoo#181793
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Original PR description
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`. Forward-Port-Of: odoo/enterprise#72245 Forward-Port-Of: odoo/enterprise#72169
Original PR description
Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`. Forward-Port-Of: odoo/enterprise#72245 Forward-Port-Of: odoo/enterprise#72169
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archIn
Original PR description
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archInfo.activeActions.edit === true` opw-4272416 Forward-Port-Of: odoo/enterprise#72516
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position. Forward-Port-Of: odoo/enterprise#72511 Forward-Port-Of: odoo/enterprise#71857
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72522 Forward-Port-Of: odoo/enterprise#72468
The span padding is taking too much place and prevent to click on the input above. So we set the correct class to avoid issues. Forward-Port-Of: odoo/enterprise#72573
Original PR description
The span padding is taking too much place and prevent to click on the input above. So we set the correct class to avoid issues. Forward-Port-Of: odoo/enterprise#72573
After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default. It should be set explicitly in the demo data. task-no Forward-Port-Of: odoo/enterprise#72315 Forward-Port-Of: odoo/enterprise#72122
Original PR description
After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default. It should be set explicitly in the demo data. task-no Forward-Port-Of: odoo/enterprise#72315 Forward-Port-Of: odoo/enterprise#72122
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
Original PR description
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72435 Forward-Port-Of: odoo/enterprise#72396
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72435 Forward-Port-Of: odoo/enterprise#72396
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onC
Original PR description
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onClick. task-4204936 Forward-Port-Of: odoo/enterprise#71314
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule. Forward-Port-Of: odoo/enterprise#72532 Forward-Port-Of: odoo/enterprise#72481
Original PR description
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule. Forward-Port-Of: odoo/enterprise#72532 Forward-Port-Of: odoo/enterprise#72481
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71433 Forward-Port-Of: odoo/enterprise#71216
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71433 Forward-Port-Of: odoo/enterprise#71216
Steps to reproduce: - Expenses > New > Mitchell Admin; Paid by employee (to reimburse) - Create report > Submit to Manager > Approve > Report in Next Payslip - Payroll app > Payslips > To Pay > New > Mitchell Admin - Set structure to 'Worker Pay' (Or any other with no expense rule) - Compute sheet > Create draft entry > Journal entry (Draft) button - Post > Traceback The traceback is caused by 'KeyError expense_report_name', this happens because e65511ac69131b048da5d11afd00f3cfe91db474
Original PR description
Steps to reproduce: - Expenses > New > Mitchell Admin; Paid by employee (to reimburse) - Create report > Submit to Manager > Approve > Report in Next Payslip - Payroll app > Payslips > To Pay > New >…
Steps to reproduce: - Expenses > New > Mitchell Admin; Paid by employee (to reimburse) - Create report > Submit to Manager > Approve > Report in Next Payslip - Payroll app > Payslips > To Pay > New > Mitchell Admin - Set structure to 'Worker Pay' (Or any other with no expense rule) - Compute sheet > Create draft entry > Journal entry (Draft) button - Post > Traceback The traceback is caused by 'KeyError expense_report_name', this happens because e65511ac69131b048da5d11afd00f3cfe91db474 changed the move creation process to ease reconciliation of expense compensated on the employee's payslip. We would have previously had access to expense_report_name=move.expense_sheet_id.name, which we do not in saas-17.4 and onwards. This causes the traceback when trying to display the error message which still depends on this inaccessible variable. We instead expect expenses not to be linked when creating payslips with a structure containing no expense rule, and a proper error if the user attempts to add an expense by hand on such a payslip. opw-4222515 Forward-Port-Of: odoo/enterprise#71541
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling
Original PR description
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications. Forward-Port-Of: odoo/enterprise#70697
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of th
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of the Billing Time Target to 100. - Again open the leaderboard in the timesheet. ### Issue 'x/' is displayed without the new target value. ### Cause Due to the wrong regular expression for the value. ### Solution Correct the regular expression. task-3970348 Forward-Port-Of: odoo/enterprise#66825
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#72332 Forward-Port-Of: odoo/enterprise#71860
Original PR description
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#72332 Forward-Port-Of: odoo/enterprise#71860
Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error We filter the subscriptions and handle them separately Forward-Port-Of: odoo/enterprise#72231 Forward-Port-Of: odoo/enterprise#72086
Original PR description
Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error We filter the subscriptions and handle them separately Forward-Port-Of: odoo/enterprise#72231 Forward-Port-Of: odoo/enterprise#72086
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#72441 Forward-Port-Of: odoo/enterprise#58487
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#72441 Forward-Port-Of: odoo/enterprise#58487
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Cu
Original PR description
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration. i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount. opw-4081350 Forward-Port-Of: odoo/enterprise#72406 Forward-Port-Of: odoo/enterprise#72192
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
Original PR description
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
Prior to this commit, the phone field was used to send WhatsApp messages, which could be incorrect. Community PR: https://github.com/odoo/odoo/pull/184660 opw-4273085 Forward-Port-Of: odoo/enterprise#72449
Original PR description
Prior to this commit, the phone field was used to send WhatsApp messages, which could be incorrect. Community PR: https://github.com/odoo/odoo/pull/184660 opw-4273085 Forward-Port-Of: odoo/enterprise#72449
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#72539 Forward-Port-Of: odoo/enterprise#69948
Original PR description
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#72539 Forward-Port-Of: odoo/enterprise#69948
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644 Forward-Port-Of: odoo/enterprise#72054
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be conside
Original PR description
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be considered by that line of the BS. Only affectation must also be considered from within the current fiscal year. Forward-Port-Of: odoo/enterprise#72337 Forward-Port-Of: odoo/enterprise#72021
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` wh
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393 Forward-Port-Of: odoo/enterprise#72425 Forward-Port-Of: odoo/enterprise#70800
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Original PR description
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416