Daily updates from Odoo
Friday, March 14, 2025
68 changes · 18.0
New functionality added to Odoo
A new Belgian payroll module lets companies export payroll work entry data for the Prisma social secretariat. This reduces manual handling when preparing payroll submissions and helps Belgian employers share the required payroll information more efficiently.
Original PR description
Create a new module to export payroll data for Prisma. task-3750799
Brazilian POS users can now issue NFC-e fiscal receipts directly from the point of sale using Avatax. Sales continue even if electronic submission fails, with staff notified and able to retry later while providing a non-fiscal receipt fallback.
Original PR description
This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice. The calculated taxes…
This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice. The calculated taxes will never change the order total. NFC-e mandates taxes to always be included in the price so we don't need any additional RPC call before payment. One way of achieving this was through l10n_br_edi, forcing every pos.order to be invoiced and then following the implemented flows on account.move. We decided against it because: - It leads to a large amount of mostly unnecessary invoices, - It's conceptually strange to the user, NFC-e "invoices" resemble POS receipts more than they do invoices, - The flow in the POS is simpler, we handle tax calculation and EDI in one atomic step. We therefore chose to re-implement EDI for pos.order. The downside of this approach is that we temporarily need to copy some code from l10n_br_edi. In master this code can be consolidated in a common mixin. The integration tries to never block POS sales. You're allowed to retry EDI later. When EDI fails, the POS user is informed and we fall back to the standard receipt (marked as a "receipt without fiscal value"). For refunds we still go through account.move, as NFC-e doesn't support refunds (must be NF-e, which is what we already support for account.move). task-3564171
Enhancements to existing features
Stock transfers involving many serial numbers now validate much faster by avoiding repeated checks during inventory valuation. This reduces waiting time for warehouse and purchasing workflows, especially for large batches.
Original PR description
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change will reduce the time taken by each `_account_entry_move` and remove unnecessary calls. ### Benchmark (in 18): | # of moves | Before | After | |---------------------|----------|---------| | 8 (with 1000 each) | 13:57 | 3:46 | | 3 (with 1489 each) | 8min | 2:53 | | 1 (with 1489) | 2:47 | 36s | ### Reference: opw-4550348
This update improves how messaging interface components are loaded so they wait for their required background services to be ready. It reduces the chance of timing-related crashes when chatter or discussion features are loaded on demand.
Original PR description
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we…
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo/odoo#201504 Related to: odoo/enterprise#81462
This update prepares the Point of Sale system for a new Brazilian electronic invoicing localization by adding integration hooks that other modules can use. It does not change current user behavior, but it makes future country-specific POS capabilities easier to add and maintain.
Original PR description
[IMP] web: eslint the new l10n_br_edi_pos module task-3564171 ---- [IMP] point_of_sale: add some hooks for l10n_br_edi_pos This doesn't change behavior, only adds a way to modify the behavior from other modules. task-3564171
This update allows background color highlighting rules to be accepted on fields in list views. It removes a validation gap so existing visual styling options can be used reliably without being rejected.
Original PR description
The current validation only allows decoration-color attributes on fields on list views. The decoration-bg-color attributes are working as expected but are not in allowed in the rng yet. Adding the attributes to the rng.
This update changes how Studio registers key interface elements so they are only activated after the services they rely on are ready. This reduces the risk of timing-related crashes when parts of the interface, such as chatter-related features, load in the background.
Original PR description
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we…
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo/enterprise#81327 Related to : odoo/odoo#201771
Resolved issues and error corrections
Fixes a typo in the Romanian electronic invoicing workflow so failed invoice sending is recorded with the correct status. This helps ensure failed submissions are detected and handled consistently instead of being missed due to an invalid status name.
Original PR description
It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D (for more info see `ciusro_document.py`, the `state` selection field) task-None
Fixed an issue where manufacturing orders could miss operations and byproducts tied to product options that do not create separate variants. This ensures production plans correctly reflect the selected product configuration, reducing manual corrections and production errors.
Original PR description
Steps to reproduce: - Create a Product with an attribute that 'Never' create variants, with two attributes - Create a Bom for that product that has: - 2 components, one restricted to the first variant - 2 operations, one restricted to the first variant - 2 byproducts, one restricted to the first variant - Set that product to MTO/Manufacture - Create a sale order for that product, and pick the first variant - Confirm the sale order and check the linked MO. Issue: Both the operation and byproduct set for that specific variant won't be in the Manufacturing Order, despite the variant-specific component being properly added. Since the requirements to skip the bom/operation/byproduct line is the same, regardless of the model, extract it and use it in the three `_skip` methods so we handle it in each case. opw-4636956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printing a delivery order for a kit no longer fails when the kit uses one unit of measure and its component uses another, such as units and kilograms. This prevents an error screen and lets warehouse users produce delivery documents as expected.
Original PR description
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- 1 Kg of P1
- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print
Problem:
A traceback is triggered because we try to convert 1kg to unit:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the
template
UserError: L'unité de mesure kg définie sur la ligne de commande
n'appartient pas à la même catégorie que l'unité de mesure unités
définie sur le produit. Veuillez corriger l'unité de mesure définie
sur la ligne de commande ou sur le produit, elles doivent appartenir à
la même catégorie.
Template: stock.stock_report_delivery_has_serial_move_line
```
opw-4619140Fixes a document layout issue where invoice titles could wrap onto two lines when using the Bubble template for Indian companies. This keeps printed invoices cleaner and more professional-looking without changing invoice content.
Original PR description
### Steps to reproduce: - Install "l10n_in" and switch to an Indian company - Settings > Document Layout > Configure Document Layout and select the "Bubble" layout - Create a customer invoice and print it - The title is on two lines ### Cause: Adding a `t-field` for the journal name seems to break the layout. ### Solution: Add `text-nowrap` on the layout_document_title to force the display on one line. opw-4496715
This fix ensures manufacturing labor cost entries are posted only once when a production order is validated. It prevents duplicate accounting entries in cases where extra confirmation steps, such as overconsumption warnings, appear before final validation.
Original PR description
By overriding `button_mark_done` to post labor entries, multiples entries could be posted in case of action returned (overconsumption wizard for instance) before the actual validation. This commit change the override by `_post_inventory()` which is called only once per validation. opw: 4571535 opw: 4532096 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
Spanish TicketBAI identification now correctly treats NIE numbers starting with X, Y, or Z as freelancer IDs. This helps avoid misclassifying freelancers as companies when processing Spanish electronic invoicing data.
Original PR description
In order to determine if the vat provided is for an autonomo (freelancer) or a juridical person (company), we checked 8 digits and a letter for the freelancer, but NIEs that start with X/Y/Z are also freelancers, so we added that option in the regex. opw-4616635 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
Invoices for Spanish freelancers using TicketBAI now show a clear warning when the required epigrafe tax activity code is missing. This prevents users from reaching submission only to receive a confusing XML schema error from TicketBAAI/Bizkaia, making the issue easier to understand and resolve before sending.
Original PR description
Previously, the epigrafe validation error was only triggered for non-'is_sale' documents. As a result, invoices without a defined epigrafe failed silently until submission to TicketBAI, causing an unclear TicketBAI error.
This fix ensures that the user error appears for invoices as well, preventing the misleading "El XML no cumple el esquema" error.
Steps to reproduce:
- Set up a Spanish freelance company
- Change tax agency to Bizkaia
- Try to send an invoice
The TicketBAi error `B4_1000001: El XML no cumple el esquema.[Linea:17 Columna:5] Error:cvc-complex-type.2.4.b: The content of element 'Ingreso' is not complete. One of '{Renta}' is expected.`
opw-4559069This fix prevents access errors when opening contacts whose billing settings depend on a related commercial partner in another company. It helps multi-company users continue viewing accessible contacts without being blocked by behind-the-scenes invoice format calculations.
Original PR description
Relevant conversation: https://github.com/odoo/upgrade/pull/7113 The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id…
Relevant conversation: https://github.com/odoo/upgrade/pull/7113
The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id has a company_id that is different from the user's current company, causing an issue here:
https://github.com/odoo/odoo/blob/18.0/addons/account/models/partner.py#L643
```
File "/home/odoo/src/odoo/18.0/addons/account_edi_ubl_cii/models/res_partner.py", line 190, in _compute_invoice_edi_format
super()._compute_invoice_edi_format()
File "/home/odoo/src/odoo/18.0/addons/account/models/partner.py", line 643, in _compute_invoice_edi_format
if partner.commercial_partner_id.invoice_edi_format_store == 'none':
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4058, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4101, in fetch
raise self.env['ir.rule']._make_access_error('read', forbidden)
odoo.exceptions.AccessError: Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Omar Ahmed Omar Al Himyari (id=2) doesn't have 'read' access to:
- Contact (res.partner)
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: Overseas Warehouse Management.
```
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-prUsers without Time Off management rights can now search by leave name in the Time Off overview without encountering an access error. This fixes a permission issue that blocked normal overview searches for regular employees.
Original PR description
Before this commit, making a search on name in the overview of the Time Off application without Time Off rights would give an access error. To reproduce: - Connect with a user without Time Off rights (Marc Demo for example) - Go on Time Off > Overview - Make a search on the name - An access error is raised while it shouldn't This commit changes the _search_name method by removing the explicit call to `leave_id` in the domain part not restricted to officers.
This fixes a small typo that could prevent the phone validation fallback from working when the preferred import is unavailable. It helps keep phone number region detection reliable in edge cases without changing normal user workflows.
Original PR description
Before this commit, since the introduction of the `phone_get_region_data_for_number` function (2d027ad), there was a fallback in case the import failed. However, the fallback method had an incorrect name.
Fixed an issue where POS session reports could show the counted card payment amount incorrectly after closing adjustments. This ensures business users see accurate expected versus counted payment totals when reviewing register sessions.
Original PR description
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the…
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the session report, the difference in the card payment is not displayed correctly. It shows the expected amount as 100 and the counted amount as 100, whereas it should be expected at 100 and counted at 80. Commit https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892#diff-143d17de807d23650088a8c12f0a5b5cc2246b1b51e0bb7634e85247b6e535ea made journal entry optional for payments and removed the `synchronize_from_moves` method from `account_payment`. This mean that there is no longer a synchronization between account_payment and its potential journal entries. The source (here pos_session) is now responsible for creating and linking the moves to the payment. The amount field of account_payment, which is used to construct the session report and created in `_create_combine_account_payment` was not updated with the new balance created in `_apply_diff_on_account_payment_move`. opw-4494656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an export error that could occur when users exported fields from grouped lists, such as Lots / Serial Numbers grouped by Location. The export process now passes the expected field information correctly, preventing a traceback and allowing the export to complete.
Original PR description
**Problem**: When exporting, the field dictionary is expected to have a `type` key. However, when adding `parent_field`, the `type` value is stored in `field_type` instead of `type`, causing issues. **Solution**: Ensure that `parent_field` creates a `type` key in the dictionary. **Steps to Reproduce**: 1. Go to **"Lots / Serial Numbers"**. 2. Group by **"Location"** (or any other field). 3. Select any item from the list. 4. Open the **Export** modal. 5. In the modal: - Add **"Product/External IDs"** to the fields to export. - Click **Export**. 6. **Issue**: A traceback occurs. **opw-4563055** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event follow-up emails set to go out after registration were previously delayed until after the event had started. This fix ensures those messages are sent at the intended time, improving communication with attendees.
Original PR description
Until now, the after_sub are only sent after the start of the event
This fixes a point-of-sale loyalty issue where changing a product quantity in a specific way could fail to update the number of free products. The correction helps ensure loyalty rewards are calculated consistently during checkout.
Original PR description
This commit fixes an undeterministic behavior error in POS. Changing the number of products with "⌫", "8" does not recalculate the number of free products. To recalculate, you must type "⌫", "⌫", "1", "8". 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
Branch company users can now find and select products assigned to their parent company when using Barcode inventory counts. This fixes a product lookup issue that blocked inventory adjustments in multi-company branch setups.
Original PR description
Issue ===== When logged in a branch company, it is not possible, in the Barcode app inventory adjustment, to select a product with its `company_id` set on the parent company. How to reproduce ================ 1. Create a branch company; 2. Create a product and set its company field on parent company; 3. Select the branch company as the current user company; 4. Go to Barcode > Inventory Count > Add Product; 5. In the product field, search the parent company's product -> Nothing found. Cause of the issue ================== There was a domain on the `product_id` field who restrain products only to the current company (both for quants and stock move line.) [OPW-4603831](https://www.odoo.com/odoo/project/49/tasks/4603831)
Fixed an issue that prevented users from scanning lot numbers from the barcode kanban view. This ensures inventory teams can identify and process tracked products correctly even when lots are not tied to a specific company.
Original PR description
It doensn't work to scan a lot in the kanban view of stock.barcode. It's not recognize since the company_id is not required on the lot since 18.0 but the domain was not adapt and expect it. opw-4626206
Documents created inside a company-specific folder now automatically use that same company, restoring the expected behavior. When a folder's company is changed, the update is also applied to accessible child documents so company ownership stays consistent.
Original PR description
Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333
Users working in a child company can now open the General Ledger without being blocked by access errors tied to the parent company. This improves day-to-day accounting access in multi-company and multi-branch setups for non-admin users.
Original PR description
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222
Fully discounted invoices using external tax services can still require tax, but the related accounting tax lines were sometimes missing. This fix creates the needed tax lines so journal entries better match the externally calculated tax amount and invoice total.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. We handle this case by manually creating the omitted tax lines. This is only a rough approximation but should hopefully be enough to handle these special cases. opw-4493544 [1] https://github.com/odoo/odoo/blob/9201c60f6a3a9ab6546f190cec0293eea273ce60/addons/account/models/account_tax.py#L2405-L2413 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80097.
The barcode app no longer shows the Sign button when working with batch delivery orders, because batch pickings cannot be signed. This prevents users from hitting an error during validation and keeps the workflow clear.
Original PR description
Steps to reproduce the bug: - Enable “Signature” option in inventory settings - Go to barcode → delivery orders > batch: - select any batch: - settings: - Operations > sign: - Sign and validate Problem: A traceback is triggered: “ValueError: Invalid field 'signature' on model 'stock.picking.batch'” Solution: It is not possible to sign a batch picking, so the button should not displayed. opw-4610471
This fixes an issue where paying multiple invoices by SEPA direct debit could create separate payments instead of one grouped payment. Keeping eligible payments grouped helps avoid unnecessary bank transaction fees and preserves the user’s chosen payment option.
Original PR description
…sepa Steps to reproduce: - have EU loca (l10n_be) - activate sepa - activate a mandate for a customer - create two invoices for this customer - in invoice list view, select the two invoices > click on pay > select sepa and group payment > create payments Issue: Two separate payments are being created, which significantly increases transaction fees. Cause: A write operation on line_ids triggers a chain of computations that deactivates group_payment. Solution: To minimize unnecessary writes, we prevent modifications when wizard.line_ids.partner_id consists of partners with valid mandates. Additionally, we explicitly include the current group_payment state in the write operation. This ensures that if multiple partners are selected—some with valid mandates and some without—the group payment setting remains correctly applied. opw-4551825
This fixes an error that could stop users from validating UK BACS Direct Debit Instructions. The change updates the accounting lookup to use the correct stored payment information, restoring the expected workflow for BACS direct debit setup.
Original PR description
### Steps to reproduce: - install "l10n_uk_bacs" - Go to Accounting > Customers > BACS Direct Debit Instruction and create a new one - Fill necessary values and validate - Traceback ### Cause: This [commit](https://github.com/odoo/enterprise/commit/54965c8d62301ba1fa8409709a1a1fd77150f722#diff-e00ec661d761679265d152ef44c96f9f1bb896e7dc148ea8ad7ce94cd3c28e11) changed the field `bacs_ddi_id` in `account.move` to a computed field and moved the storage to `account.payment`. But it did not change `_compute_from_moves` which was using SQL queries with `move.bacs_ddi_id`. So the method crashes because the table account_move does not have a column named bacs_ddi_id anymore. ### Solution: Adapt the SQL queries to use `payment.bacs_ddi_id`. opw-4593098
Commission report details now include sales that do not have a sales team, such as many POS sales, so salesperson commissions are visible consistently. Team-based commission calculations for subscriptions were also corrected to better reflect the right salespeople and teams.
Original PR description
Sales made without a team (like in POS by default) did not show up in the commission report "details". This commit backports the change made in later versions. **Steps to reproduce** - Create a commission plan for a Salesperson. - Create an invoice from a sale in POS. - The commission appears in the `sale.commission.report`, but not in the details (`sale.commission.achievement.report`) if there are other invoices for that period with a team set. opw-4488615
The Colombian reports now correctly expand all report lines when users choose the unfold all option. This prevents missing detail in reports and makes it easier for users to review complete Colombian reporting data.
Original PR description
The unfold all options wasn't working correctly in the colombian reports since we added the line, and we only checked if the line was unfolded manually. Now we also check if the unfold all options is activated opw-4621274
Service sale confirmations can now create project documents correctly in multi-company setups, even when a shared documents folder is linked to another company's website. This avoids blocking sales order confirmation with an access error during automated project setup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates…
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` has to match the website's `company_id`; - OR the website's `company_id` has to be in `self.env.companies`. The Projects folder was created without `website_id`, but was assigned company 1's website by the `_compute_website_id` method. When a document gets created by the sale order, it inherits the `website_id` of the Projects folder. Hence having a shared folder between companies can lead to access errors if the website's `company_id` isn't selected in the company selector. Solution -------- Bypass the constraint when in sudo mode, so you don't have to enable the website's company in the company selector when setting up a sale order. opw-4548619
The signing workflow now waits for document pages using the correct page area, preventing an automated HR contract signing check from crashing. This improves reliability for sign-related HR contract processes without changing user-facing functionality.
Original PR description
In this commit, we fix the following error that can occurs in tour hr_contract_salary_tour_hr_sign.
```
AssertionError: The test code "odoo.startTour('hr_contract_salary_tour_
hr_sign', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false,
"startUrl": "/", "delayToCheckUndeterminisms": 0})" failed
UncaughtTypeError: Cannot read properties of null
(reading 'querySelector')
```Miscellaneous changes
During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount. Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201774
Original PR description
During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount. Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201774
Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201591
Original PR description
Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201591
## Versions: 16.0+ ## Issue: When changing the website language from the cart page, the product description is not translated while all other elements of the page are. ## Steps to reproduce: Install at least 2 languages available on website; From the shop, add a product (e.g. "Customizable Desk") to cart; Move to the cart and change language. ## Cause: Description is retrieved without being recomputed with selected language. opw-4485686 Forward-Port-Of: odoo/odoo#201250 Forwar
Original PR description
## Versions: 16.0+ ## Issue: When changing the website language from the cart page, the product description is not translated while all other elements of the page are. ## Steps to reproduce: Install at least 2 languages available on website; From the shop, add a product (e.g. "Customizable Desk") to cart; Move to the cart and change language. ## Cause: Description is retrieved without being recomputed with selected language. opw-4485686 Forward-Port-Of: odoo/odoo#201250 Forward-Port-Of: odoo/odoo#198073
Scenario: - create marketing email in 17.0 or above - use the Cover widget - change the cover image to get a base64 endoded image - send the mail Result: no image is sent Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue when parsing the CSS because of having inside a CSS value eg. url("data:image/webp;base64,..."), then when the CSS was modified, the background image would be broken (with a :undefined after the value). Fix: instead of replacing all the style to change t
Original PR description
Scenario:
- create marketing email in 17.0 or above
- use the Cover widget
- change the cover image to get a base64 endoded image
- send the mail
Result: no image is sent
Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue
when parsing the CSS because of having inside a CSS value eg.
url("data:image/webp;base64,..."), then when the CSS was modified, the
background image would be broken (with a :undefined after the value).
Fix: instead of replacing all the style to change the border-style,
update it with regex.
opw-4613524
Forward-Port-Of: odoo/odoo#201685
Forward-Port-Of: odoo/odoo#201394Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201683 Forward-Port-Of: odoo/odoo#195395
Original PR description
Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201683 Forward-Port-Of: odoo/odoo#195395
Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacu
Original PR description
Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Ideally, it shouldn't be run before old assets are discarded. So maybe the cron should be triggered after some little delay. task-3970360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197128
As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law. source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/ opw-4531928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201214
Original PR description
As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law. source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/ opw-4531928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201214
### Steps to reproduce: - In the settings enable purchase > dropshipping - Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its password. - Create a product FP tracked by SN, "BOB" as vendor and a bom of type subcontracting: 1 x COMP (tracked by SN), subcontracted by "BOB" - On COMP, check the routes "Buy" and "Dropship Subcontractor on Order" and set a vendor price list. - Create and confirm a purchase order for 2 units of
Original PR description
### Steps to reproduce: - In the settings enable purchase > dropshipping - Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its…
### Steps to reproduce: - In the settings enable purchase > dropshipping - Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its password. - Create a product FP tracked by SN, "BOB" as vendor and a bom of type subcontracting: 1 x COMP (tracked by SN), subcontracted by "BOB" - On COMP, check the routes "Buy" and "Dropship Subcontractor on Order" and set a vendor price list. - Create and confirm a purchase order for 2 units of FP for BOB - A dropship Purchase Order is created for 2 units of COMP > confirm it - In the Portal view, as BOB, return to the MO related to FP - Click on the "burger" icon of the move and try to change the qty_producing or set a SN for the finished product. #### > you trigger and access right error. ### Cause of the issue: Changing the qty_producing or the serial number of the finished product triggers a call of the `_set_qty_producting`: https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L793-L796 During this call, the pickings linked to the MO will be fetchded to determine if the MO is waiting for components to arrive or if the reservation can already be done. https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L1223-L1224 However, the portal user does not have the access right to read this record and you are not saved by the `Stock Pickings Subcontractor`, `ir.rule` as this is a dropdhip. ### Note: It was not possible to trigger the issue in 17.0 because prior to: https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L466 The dropshipping picking was not linked to the MO and hence we didn't try to access the values of any record we didn't have access to. opw-4485186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198814
Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on an empty recordset returns False. This PR fixes that by first searching on the categories before filtering using the domain --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201542
Original PR description
Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on
an empty recordset returns False.
This PR fixes that by first searching on the categories before filtering using the domain
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#201542If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset. When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible. task-4643664 Forward-Port-Of: odoo/odoo#201586
Original PR description
If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset. When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible. task-4643664 Forward-Port-Of: odoo/odoo#201586
Steps to reproduce: ------------------- - Install 'Project' module - Create a new project - Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default) - Open the Odoo instance in a new incognito browser (or erase cache) - Login and open the created tasks in kanban view Issue: ------ Kanban view is slow to load. Cause: ------ Retrie
Original PR description
Steps to reproduce: ------------------- - Install 'Project' module - Create a new project - Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default) - Open the Odoo instance in a new incognito browser (or erase cache) - Login and open the created tasks in kanban view Issue: ------ Kanban view is slow to load. Cause: ------ Retrieving the covers in their original quality/size. Solution: --------- Hardcode the image height and width in the call of the route so that the retrieved image is cropped/resized. opw-4438965 Forward-Port-Of: odoo/odoo#199395
**Issue** Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation. **Cause** The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail. **Solution** Ensure the table is empty after uninstall. **Steps
Original PR description
**Issue** Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation. **Cause** The `project_share_wizard_res_partner_rel` table for the…
**Issue** Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation. **Cause** The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail. **Solution** Ensure the table is empty after uninstall. **Steps to reproduce** - Project Kanban View > 3 dots > Share - Add a recipient and Send: this should add a row to the `project_share_wizard_res_partner_rel` table. - Uninstall Project shortly after (before the row is deleted by the auto-vacuum). - Try to re-install Project: ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Unknown (unknown) Constraint: project_share_wizard_res_partner_r_project_share_wizard_id_fkey ``` opw-4593125 Forward-Port-Of: odoo/odoo#200984 Forward-Port-Of: odoo/odoo#200555
Add some logic to check the partner fields of models when formatting numbers based on a specific record. This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess. task-4199766 Forward-Port-Of: odoo/odoo#200245 Forward-Port-Of: odoo/odoo#195686
Original PR description
Add some logic to check the partner fields of models when formatting numbers based on a specific record. This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess. task-4199766 Forward-Port-Of: odoo/odoo#200245 Forward-Port-Of: odoo/odoo#195686
Before this commit, the field matching of the pivots was changed in place instead of using `this.history`, which caused issues with the undo/redo. Task: 4646822 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#201599
Original PR description
Before this commit, the field matching of the pivots was changed in place instead of using `this.history`, which caused issues with the undo/redo. Task: 4646822 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#201599
When importing an xml invoice, we display a generic error in case of Exception. This is useful from a technical point of view but this is obscur for the user. With this commit, in case of a UserError, we add the error message in the chatter. Let's assume a wrong configuration and steps like this: - Belgian demo company, `account_peppol` installed and activated - Make sure there are no moves in `Vendor Bills` journal - On the account 600000, set `Allowed Journals` to be any journal different
Original PR description
When importing an xml invoice, we display a generic error in case of Exception. This is useful from a technical point of view but this is obscur for the user. With this commit, in case of a…
When importing an xml invoice, we display a generic error in case of Exception. This is useful from a technical point of view but this is obscur for the user. With this commit, in case of a UserError, we add the error message in the chatter. Let's assume a wrong configuration and steps like this: - Belgian demo company, `account_peppol` installed and activated - Make sure there are no moves in `Vendor Bills` journal - On the account 600000, set `Allowed Journals` to be any journal different from `Vendor Bills` - From the journal dashboard, vendor bills journal, click on `Fetch from peppol`, then go to the bil that has been created -> In the chatter you will see the error message: "Error importing attachment '2_demo_vendor_bill' as invoice (decoder=_import_invoice_ubl_cii)" This is because we raise the constrains `account_move_line._check_constrains_account_id_journal_id`, but the user will never know until we display the UserRrror message in the chatter. opw-4513344 Forward-Port-Of: odoo/odoo#201566 Forward-Port-Of: odoo/odoo#200694
To reproduce: - Install delivery_fedex (for example) and sale_management. - Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example). - New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO. Current behaviour: Estimated cost on SO line description is not rounded according to the currency conventions. Expected behaviour: Estimated cost on SO line description is rounded, according to the curre
Original PR description
To reproduce: - Install delivery_fedex (for example) and sale_management. - Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example). - New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO. Current behaviour: Estimated cost on SO line description is not rounded according to the currency conventions. Expected behaviour: Estimated cost on SO line description is rounded, according to the currency conventions. opw-4543605 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201572 Forward-Port-Of: odoo/odoo#201510
This commit fixes a malformed CSS rule (introduced in commit [1]) trying to define the `font-size` of the mentions. In a nutshell, the `rfs()` Bootstrap's mixin has two arguments: - the first is the base size - the second is the property to apply the calculated size to In this case, it generated the following malformed rule: `0.8125rem: 0.8125rem;`. As this rule isn't applied anyway and the visual result is OK, this commit simply removes it. [1]: https://github.com/odoo/odoo/pull/1
Original PR description
This commit fixes a malformed CSS rule (introduced in commit [1]) trying to define the `font-size` of the mentions. In a nutshell, the `rfs()` Bootstrap's mixin has two arguments: - the first is the base size - the second is the property to apply the calculated size to In this case, it generated the following malformed rule: `0.8125rem: 0.8125rem;`. As this rule isn't applied anyway and the visual result is OK, this commit simply removes it. [1]: https://github.com/odoo/odoo/pull/170765 Forward-Port-Of: odoo/odoo#201517
Versions -------- - 16.0+ Steps ----- 1. Have a product with a "No variant" or customer attribute; 2. add product to a sales order. Issue ----- There is a blank line between the product name & attribute descriptor. Cause ----- The `_get_sale_order_line_multiline_description_variants` method returns either an empty string, or a string that starts with 2 newlines. Solution -------- Start with only 1 newline. opw-4585174 Forward-Port-Of: odoo/odoo#201486 Forward-Port-Of:
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a product with a "No variant" or customer attribute; 2. add product to a sales order. Issue ----- There is a blank line between the product name & attribute descriptor. Cause ----- The `_get_sale_order_line_multiline_description_variants` method returns either an empty string, or a string that starts with 2 newlines. Solution -------- Start with only 1 newline. opw-4585174 Forward-Port-Of: odoo/odoo#201486 Forward-Port-Of: odoo/odoo#201011
…CIG or CUP is present **Issue:** When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete. **Steps to Reproduce:** 1. Install the Accounting app 2. Install the l10n_it_edi module 3. Navigate to Accounting > Customers > Invoices 4. Select or create an invoice 5. Choose a customer with a PA index 6. Open the Electronic Inv
Original PR description
…CIG or CUP is present **Issue:** When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the…
…CIG or CUP is present **Issue:** When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete. **Steps to Reproduce:** 1. Install the Accounting app 2. Install the l10n_it_edi module 3. Navigate to Accounting > Customers > Invoices 4. Select or create an invoice 5. Choose a customer with a PA index 6. Open the Electronic Invoicing tab 7. Fill in either the CIG or CUP field, but leave the Origin Document Type empty 8. Click Send & Print 9. No error is displayed and the e-invoice XML can be sent Expected Behavior: An error should be triggered, preventing the e-invoice from being sent if the Origin Document Type is missing, even when only one of CIG or CUP is present. Actual Behavior: The system allows sending the e-invoice despite missing critical information, leading to incomplete data submission. **Root Cause** The existing validation only checks if both CIG and CUP are missing, but it does not account for cases where only one is filled while the Origin Document is still absent. **Fix** The condition has been updated to trigger an error whenever the Origin Document Type is missing, even if only one of CIG or CUP is present. Opw-4590205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198758
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Description of the issue/feature t
Original PR description
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 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#198606
- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510
Original PR description
- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510
We faced a [warning](https://github.com/odoo/odoo/pull/186467/files#diff-f4c0e9f9d6736a6c5313479e63a48eee140d0e3249932cdcf82d69d0bb7865b1R144) 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). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 Regarding the changes in this PR related to Registry: https://github.com/odoo/odoo/pull/186467 see: https://gi
Original PR description
We faced a [warning](https://github.com/odoo/odoo/pull/186467/files#diff-f4c0e9f9d6736a6c5313479e63a48eee140d0e3249932cdcf82d69d0bb7865b1R144) 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). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 Regarding the changes in this PR related to Registry: https://github.com/odoo/odoo/pull/186467 see: https://github.com/odoo/odoo/pull/191749 upg-2436225 **Reference Image**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201096
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:
Original PR description
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation…
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue: The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced. https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332 opw-4583573 Forward-Port-Of: odoo/enterprise#81285 Forward-Port-Of: odoo/enterprise#80802
- Fix access rights (again) on employee view for wage statements - Fix condition on ACC rule that prevents manual edition of payslip lines Forward-Port-Of: odoo/enterprise#81317
Original PR description
- Fix access rights (again) on employee view for wage statements - Fix condition on ACC rule that prevents manual edition of payslip lines Forward-Port-Of: odoo/enterprise#81317
Steps fo reproduce : - create a product (in the inventory tab, the route should be 'Manufacture') - click on the smart button 'bill of materials' - create a BOM for this product with at least one operation - in the quality app navigate to Quality Control/Control Points - create a new control point - in the field product select the product that you created - in the operations field select "YourCompany: Manufacturing" - in the work order operation field select the operation that you wrote
Original PR description
Steps fo reproduce : - create a product (in the inventory tab, the route should be 'Manufacture') - click on the smart button 'bill of materials' - create a BOM for this product with at least one…
Steps fo reproduce : - create a product (in the inventory tab, the route should be 'Manufacture') - click on the smart button 'bill of materials' - create a BOM for this product with at least one operation - in the quality app navigate to Quality Control/Control Points - create a new control point - in the field product select the product that you created - in the operations field select "YourCompany: Manufacturing" - in the work order operation field select the operation that you wrote in the BOM you created (if multiple operations with the same name make sure that you selected the one linked with the BOM) - in the type field select "Measure" - in the norm field enter a unit of measure with at least an upper case - create a manufacturing order for this product - open the shop floor app and on the manufacturing order you created select the quality check point Current Behavior: The unit of measure appears in lower case. This could change its meaning for instance form MW (mega-watt) to mw (mili-watt) Expected Behavior: The unit of measure string should respect the letter case wrote by the user Cause of the issue: In the xml file, inside the <span> tag the class was "text-lowercase" Fix: I removed this class from the span https://github.com/odoo/enterprise/blob/43e7aec36ddee8a3ff3de8793427a183dfd29b30/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.xml#L47 opw-4584509 Forward-Port-Of: odoo/enterprise#81274
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone f
Original PR description
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone formatter should be able to guess the country of a record based on the country of its partner task-4199766 Forward-Port-Of: odoo/enterprise#80704 Forward-Port-Of: odoo/enterprise#70608
If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318
Original PR description
If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318
Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test). This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user. Forward-Port-Of: odoo/enterprise#
Original PR description
Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test). This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user. Forward-Port-Of: odoo/enterprise#81309
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1
Original PR description
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. -…
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1e857e1534c86495cd4934c1adb8ae9597/project_enterprise/views/project_views.xml#L12 **Solution** A hack is to add in the model metadata the `colorField` key used by the gantt renderer to color the pills: https://github.com/odoo/enterprise/blob/28f2fba988b1b225c97d15729020962ed4dee73b/web_gantt/static/src/gantt_renderer.js#L778 It is normally set when parsing the view here: https://github.com/odoo/enterprise/blob/dfe2795b820527a8226d8cf1afa5bf7ac8fcb53d/web_gantt/static/src/gantt_arch_parser.js#L194 This avoids trying to read the field if the user doesn't have the necessary `project.group_project_stages` group. Note: some missing views are also added in this commit, they were missing when the project stage feature wasn't enabled. opw-4592110 Forward-Port-Of: odoo/enterprise#81179 Forward-Port-Of: odoo/enterprise#79968
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the pr
Original PR description
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP -…
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." ### Cause of the issue: When processing an MO from the barcode app and adding a component the method `_getNewLineDefaultContext` will be called to set the default context of that new line before creation: https://github.com/odoo/enterprise/blob/83268aa3a5a7afdc8c09b0ac9bbee2b673fd25e9/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L367-L372 However, in this flow, `this.record` is an `mrp.production` and its `product_uom_id` is the product_uom_id of FP. In particular, the `default_product_uom_id` key will be used to alter the vals_list used in the create of our stock move line and an error will be raised since the unit category of COMP2 is Weight and is not compatible with the default product uom set by the context. opw-4527706 Forward-Port-Of: odoo/enterprise#80987 Forward-Port-Of: odoo/enterprise#79266
**Steps to reproduce:** 1.Go to Documents > Configuration > Settings: -Enable Accounting (Centralize accounting files and documents) -Open Journals and synchronize a chosen journal with a workspace 2.Create a new activity type with: `action`: `Upload Document` `folder_id`: The same workspace we set in the settings 3.Create a journal entry in the journal you chose 4.Add the new activity to the journal entry. 5.Upload a document. **Issue:** The attachment is up
Original PR description
**Steps to reproduce:** 1.Go to Documents > Configuration > Settings: -Enable Accounting (Centralize accounting files and documents) -Open Journals and synchronize a chosen journal with a workspace…
**Steps to reproduce:**
1.Go to Documents > Configuration > Settings:
-Enable Accounting (Centralize accounting files and documents)
-Open Journals and synchronize a chosen journal with a workspace
2.Create a new activity type with:
`action`: `Upload Document`
`folder_id`: The same workspace we set in the settings
3.Create a journal entry in the journal you chose
4.Add the new activity to the journal entry.
5.Upload a document.
**Issue:**
The attachment is uploaded, but we get a Missing Record error for an `ir.attachment` record, and the activity isn't set to done
**Cause:**
This commit was meant to prevent this issue: https://github.com/odoo/enterprise/commit/6c4bbf2fe0577fe1f4fc9f6a408c5904eb1cf92b
What it is meant to do is to add a `no_document` flag to prevent the creation of two documents when an attachment is uploaded to an activity, since the second one will by unlinked, along with the attachment. See:
https://github.com/odoo/enterprise/blob/a46594b2d3529d86a40a1567e0e4e0207399a3a8/documents/models/mail_activity.py#L41
But a particular case was not included:
- if the attachment fits at least one of these criteria:
- attachment of a misc operation
- first attachment of an invoice
- xml file after it has been succesfully registered as move attachment
- if the journal in which the entry was created is synchronized with the activity's workspace
In this case, a second document is created, since we don't check for the flag `no_document` in this flow.
see:
https://github.com/odoo/enterprise/blob/28b6a5d30274f4265c978433b8d02b758d9a032e/documents_account/models/ir_attachment.py#L24
and:
https://github.com/odoo/enterprise/blob/85c139237015a7c3f1233eb9d977ead126b7d7d6/documents_account/models/account_move.py#L87
**Solution:**
Added a check for the `no_document` flag before calling `_update_or_create_document`
opw-4547561
Forward-Port-Of: odoo/enterprise#80662Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company Task: 4625747 Forward-Port-Of: odoo/enterprise#81428 Forward-Port-Of: odoo/enterprise#80740
Original PR description
Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company Task: 4625747 Forward-Port-Of: odoo/enterprise#81428 Forward-Port-Of: odoo/enterprise#80740
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour:
Original PR description
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x…
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour: Ideally, a correctly validated picking with generated return labels. However, this appears to currently not be supported by the FedEx REST API... (multi-package single-shot return shipments of print label type) We compromise and will create the outgoing shipment as usual, but not the return shipment in case of multi-package shipments. A helpful message informing the user of this limitation will be put in the chatter of the picking instead of the generated return label in this specific case. opw-4556415 Forward-Port-Of: odoo/enterprise#81326
When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation. Forward-Port-Of: odoo/enterprise#81203
Original PR description
When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation. Forward-Port-Of: odoo/enterprise#81203
Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710'). However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions. This commit proposes to use sanitized_acc_number from mandate partner bank account. opw-4536189 Forward-Port-Of: odoo/enterprise#81238
Original PR description
Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710').
However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions.
This commit proposes to use sanitized_acc_number from mandate partner bank account.
opw-4536189
Forward-Port-Of: odoo/enterprise#81238