Daily updates from Odoo
Thursday, April 10, 2025
40 changes · 18.0
Security fixes and vulnerability patches
The Attendance Gantt view no longer shows employee names that a user is not allowed to access. This prevents misleading schedule displays and helps protect employee information from unauthorized visibility.
Original PR description
### Issue: - In the Attendance Gantt view, users can see all employees in the company, including those they are not allowed to manage or view. -While access rules prevent users from seeing attendance records for these employees, the employees' names still appear in the Gantt view. -This creates a misleading user experience and potentially exposes restricted information (employee names). ### Steps To Reproduce: 1. Log in as Marc Demo. 2. Open the attendance App. 3. Observe that all employees are shown as group headers. ### Solution: - this PR adds a test to check that the Gantt view only shows employees that the user has access to. community fix: https://github.com/odoo/odoo/pull/205031 opw-4570867
Enhancements to existing features
Selection menus can now use customized filtering rules instead of relying only on the visible option label. This helps users find and display relevant choices even when extra search information is not shown on screen.
Original PR description
Purpose: allow customizing how options are filtered. In documents, we chose to limit the amount of information present in the `label` of `choice`s, but we should still be able to display all our fetched options, even those that do not match what is in the `label`, and is fixed in the related PR. Task-4656596
When a company’s GSTIN or API credentials are changed, Odoo now clears the related India e-invoicing and e-waybill connection tokens so new ones can be generated. Users also receive a warning that API connections must be re-established after changing the GSTIN, reducing the risk of failed compliance submissions with outdated credentials.
Original PR description
This **PR** refines the API token management system for l10n_in by introducing a dependency on the GSTIN number and on API's credentials. Consequently, whenever the GSTIN number or API's credentials are updated, all associated tokens and their validity are reset. New tokens must then be generated to ensure continued functionality. As part of this **PR** following will be affected: 1) edi_token used for E-Invoicing. 2) auth_validity of E-Waybill authentication. Additionally, a warning is added on GSTIN change, notifying users that re-establishing the connection for the APIs is required after updating the GSTIN. **task**-4430663 **IAP PR**: https://github.com/odoo/iap-apps/pull/971 **Enterprise PR**: https://github.com/odoo/enterprise/pull/76373
The customer statement button will now appear only when there is actual statement content for the selected customer, reducing confusing empty reports. Draft-entry warnings will also appear only when the selected customer has draft accounting entries, helping users focus on relevant alerts.
Original PR description
Description of the issue this commits addresses: The Customer Statement button is shown too often and leads to empty customer statements in some scenarios. The banner warning the user that some entries are draft is also shown too often and should only appear if the selected partner(s) have draft entries. --- Desired behavior after this commit is merged: The button only shows when the customer statement it will lead to has values to show. This means both making sure the partner has moves to show on the customer statement but also that the customer statement actually shows them. Same for the draft entries warning banner. It will only be shown when the selected parter(s) has(have) draft entries. --- task-4680249
Resolved issues and error corrections
This fixes an issue where stock accounting entries could be assigned the wrong direction when multiple stock move lines were processed together. The correction helps keep inventory valuation and related accounting records accurate.
Original PR description
### Description: The commit b15bdb6 introduces a bug causing the `account.move.line` to be broken. This is caused by the fact that rather than looping over the move_line_ids of one move, it does it on all of them, causing the moves to all have the same direction, even if the move lines have different directions. ### Fix: Changing the `self` to `record` should fix the issue. ### Reference: b15bdb65b11b3772c1d288b8b65e48f0cb221d24
This fix avoids posting extra purchase order messages when quantities are effectively unchanged but look slightly different due to decimal rounding. It reduces confusing chatter updates for users working with unit conversions such as kilograms to tons.
Original PR description
To reproduce: Use a product that has a purchase uom in kg and a base uom in tons. Create a purchase order and deliver 1656 kg of the product. This will save as 1.6560000000001 due to python arithmetic. If you save the value again, another message will be posted even though the value does not change. To fix this, I changed the condition for posting a new message from using a '!=' operator to using float_compare which circumvents the issue. OPW-4631076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where clicking at the start of a formatted link in the HTML editor could cause an error. Users can now place the cursor before formatted links normally, making text editing more reliable.
Original PR description
**Current behavior before PR:** - Clicking at the start of a link which has some format applied on it would trigger a traceback error. **Desired behavior after PR is merged:** - Now, Clicking at the start of the formatted link will now correctly display the cursor before the link. task:4699778
The download link for Quote Builder PDF examples now points to the correct Odoo 18.0 file. This prevents users from seeing a 404 error when downloading example files from quotation templates.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open a quotation template; 2. open the Quote Builder tab; 3. click "Download examples". Issue ----- 404 not found Cause ----- For product: - When commit 3e58523 updated the versions of documentation links from 17.0 to 18.0, it overlooked changing the hash part of the url for `pdfquotebuilderexamples.zip`. For sale_pdf_quote_builder: - The version in the url gets added by the `documentation_link` widget, but it doesn't update the hash part of the download link. Solution -------- Change it so it links to https://www.odoo.com/documentation/18.0/_downloads/c2c6ce32294dfddffcfefcf2775f7a09/pdfquotebuilderexamples.zip opw-4680248
Reference fields now display long selection values without overlapping the related field next to them. This improves readability and prevents confusing visual overlap when users edit records such as Marketing Card recipients.
Original PR description
This commit fixes a miss-alignment between the first select and the following many2one field in a reference field. When choosing a longer value in the first select, it overlaps with the many2one field. Steps to reproduce: - Open Marketing Card app - Click to open a record - Choose a longer value in the first select in the Recipients field => overlap between the select's value and the following many2one field task-4387904 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 fix restores a validation check to ensure spreadsheet data attachments are saved as valid JSON files. It helps prevent invalid spreadsheet data from being accepted, reducing the risk of errors when users open or work with spreadsheets.
Original PR description
In https://github.com/odoo/odoo/pull/188792 we mistakenly removed the check that ensured the spreadsheet_data attachment was a valid JSON file. Task-4657990 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
Restaurant point-of-sale users can now refund paid floating orders even when the floor has no tables configured. The fix prevents an error by creating the refund as a floating order instead of looking for a table that does not exist.
Original PR description
Steps to reproduce: ------------------------ - Install pos_restaurant. - Open a restaurant session without any table on the floor. - Create an order from floating order & pay it. - Go to orders apply paid filter and try to refund the order. Issue: -------- - We will have a tb on clicking on refund. Cause: ---------- - We were trying to access the orders of the selected table (order's table or the first table of the restaurant). Fix: ----- - We will check if table exists or not if not than it will create a floating refund order without any tb. Task - 4658258
Fixed an issue where printing a delivery order could fail for kit products whose bill of materials used a product template and packaging quantity. This prevents an error message and allows warehouse documents to print correctly in that scenario.
Original PR description
When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity…
When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity from the product's UoM to the order line's UoM. This happens because the product's UoM is not defined.
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- set only the product template field (not the product_id)
- 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 an undefined uom
```
Error while render the template
UserError: The unit of measure Units defined on the order line doesn't
belong to the same category as the unit of measure False 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.
```
opw-4619140The New Zealand localization now reports GST-only import taxes in Box 13 instead of Box 11, aligning with IRD GST reporting rules. This helps businesses avoid misclassified GST return figures for customs-billed import GST.
Original PR description
Current set up under the tax concerned is "BOX 11" which is incorrect as according to the IRD GST report, BOX 11 excludes the amount of imported goods. The tax in consideration is used when the NZ Customs bills the user only for the GST amount based on the purchase value of the goods. Therefore, the tax grids for this tax need to changed to "BOX 13". task-3926151
When a chatbot forwards a conversation to a live chat operator, the chat is now correctly shown as unread and needing attention. This prevents operators from missing new customer conversations handed over by the bot.
Original PR description
Before this PR, the operator was not notified after being forwarded by a bot. This happened because the notification was posted as the operator. Messages are automatically marked as read when a user posts them. As a result, nothing in the UI indicated that the chat was new or required the operator's attention. This PR resolves the issue by posting the message as the chatbot. It both makes sense from a UX perspective (displaying something like "Bot invited the operator to the user") and ensures the chat is properly flagged for the operator. task-4689496 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 fix restores the expected secondary color styling for table headers in report layouts. It keeps report tables visually consistent with previous versions and improves readability for users viewing generated documents.
Original PR description
Before version 18.0, the secondary color was applied to `<thead><th>`. However, after this commit https://github.com/odoo/odoo/commit/d492a35b3d070c997ceb9ba4a9d9617eb11fa21d, the secondary color was not applied properly for layouts. Current visual result: | Before fix | After fix | | --- | --- | | | | - OPW: 4649140 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
Odoo Studio no longer shows the Colombian Daily Journal report in its report editor, preventing an error when users open it from customer invoices. This avoids a confusing crash for businesses using Colombian accounting reports while keeping the report available through the intended accounting reporting flow.
Original PR description
**Step to reproduce** 1. createdb with installing l10n_co_reports in 18.0 2. and install web_studio 3. open studio in customer invoice menu and tap on Daily Journal report **Below mentioned traceback…
**Step to reproduce**
1. createdb with installing l10n_co_reports in 18.0
2. and install web_studio
3. open studio in customer invoice menu and tap on Daily Journal report
**Below mentioned traceback is rasing**:
for fixing it adding in blacklist report so it won't show in studio as I have checked in this [commit](https://github.com/odoo/enterprise/commit/e7efdb09742c434f1f72ec9c8f619038c470b464) the purpose this report to show the report using accounting report
```
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 1963, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/odoo/odoo/18.0/odoo/service/model.py", line 156, in retrying
result = func()
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 1930, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 2178, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/18.0/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/enterprise/18.0/web_studio/controllers/report.py", line 499, in load_report_editor
report_qweb = self._get_report_qweb(report)
File "/home/odoo/odoo/enterprise/18.0/web_studio/controllers/report.py", line 636, in _get_report_qweb
render_context = report_safe_cr._get_rendering_context(report_safe_cr, [0], {"studio": True})
File "/home/odoo/odoo/enterprise/18.0/web_studio/models/ir_actions_report.py", line 44, in _get_rendering_context
ctx = super()._get_rendering_context(report, docids, data)
File "/home/odoo/odoo/odoo/18.0/addons/account/models/ir_actions_report.py", line 94, in _get_rendering_context
data = super()._get_rendering_context(report, docids, data)
File "/home/odoo/odoo/odoo/18.0/odoo/addons/base/models/ir_actions_report.py", line 1105, in _get_rendering_context
data.update(report_model._get_report_values(docids, data=data))
File "/home/odoo/odoo/enterprise/18.0/l10n_co_reports/report/libro_diario_report.py", line 17, in _get_report_values
report = self.env['account.report'].browse(options['report_id'])
TypeError: 'NoneType' object is not subscriptable
```
opw-4608924
upg-2733166This fix restores the reconnect option for disconnected credit card journals that already have transactions. It helps users resume online synchronization without manual workarounds, reducing disruption in credit card reconciliation.
Original PR description
Currently, when a credit card journal gets disconnected, and has some transactions, the reconnect button won't appear. This is caused by the condition for `display_connect_bank_in_dashboard` added in ae3ec22b6ec64f4600b5a11db2ffda5256bb75fd to omit the 'credit' type journal. Changing this condition to account for 'credit' type journals allows the reconnect button to appear on credit journals that have transactions. opw-4654051
Fixes an issue that could cause errors when retrieving contact details from a point-of-sale order in the WhatsApp POS integration. This keeps the existing standard behavior and helps avoid interruptions in related messaging workflows.
Original PR description
Before this commit, calling `_mail_get_partners` on a `pos.order` record would raise an error due to the missing `introspect_fields` argument in the overridden method. Additionally, overriding this method was unnecessary, as the parent implementation already provides the correct behavior. opw-4713552
Subscription portal payments now correctly save payment details when the payment amount matches the expected amount. This prevents customers from losing the ability to reuse payment methods for future subscription billing.
Original PR description
After https://github.com/odoo/enterprise/pull/8209 we stopped tokenize when the amount match. It is an error.
Users can now find existing contacts by typing part of their email address when sharing documents. This makes it easier to select the right recipient and avoids failed sharing attempts when the contact name does not match the email being searched.
Original PR description
Reproduce: 1. Create a partner with name "TEST" and email "bob@there.com". 2. Try to share a document using "bob" to find the partner. 3. It doesn't show up, you can't select them. Partners should be findable by their email when trying to share documents with them. Task-4656596
Shared document links can now be previewed by public users instead of always forcing a download. This makes externally shared files easier to review directly in the browser and adds test coverage to prevent the issue from returning.
Original PR description
Steps to reproduce: 1. Share a file with the outside world and grab the link. 2. Paste it incognito. 3. Hit the preview button. 4. It opens the os finder to download it. Currently, public users cannot preview shared documents; instead, the documents are always downloaded. Technical Reason: 1. In an override of the route handling document content retrieval, the argument that determines whether the document should be displayed or downloaded is lost in a `super()` call. 2. Added 'post_install' tag to ensure the test also runs after installation, so it can catch changes from other modules like 'documents_account'. After this Commit: Shared documents will be reviewable. Task-4689525
Public users opening shared document links can now preview supported files, such as PDFs and images, instead of having them downloaded automatically. This improves the sharing experience and ensures document previews work consistently when accounting document features are installed.
Original PR description
Currently, public users cannot preview shared documents; instead, the documents are always downloaded. ### Steps to reproduce 1. Install `documents_account`. 2. Share a previewable document (e.g., an image or a PDF) with a link that allows public viewing. 3. Open the share link in an incognito window. 4. Click "Preview file." The file is downloaded instead of being previewed. ### Cause In an override of the route handling document content retrieval, the argument that determines whether the document should be displayed or downloaded is lost in a `super()` call. ### Tests While the base `documents` module includes tests for this behavior, they are tagged with `at_install`, meaning they only validate the functionality at the time of the module's initial installation. This does not account for potential overrides in extension modules like `documents_account`. To address this, the test class is now tagged `post_install`. opw-4490958
Guest customers booking a paid appointment will no longer create two separate contact records during checkout. The appointment and related sales order now use the same customer details, reducing duplicate data and backend cleanup.
Original PR description
To reproduce: ============= - without sign-in, book a paid appointment - you will be asked for name/email/phone - then at checkout you will be redirected to fill address and asked for name/email/phone again - fill the form and submit - on backend you will find two contacts created one with SO and one with appointment Problem: ======== when we fill the form for appointment, a partner is created but it's not set on the appointment's sale order, that's why another partner is created when we fill the address form. Solution: ========= - set the partner on the appointment's sale order when creating it opw-4668838
Features or functions removed from Odoo
This change removes an obsolete checkDelay setting that is no longer used after a previous update. It simplifies the code and test tours without changing expected user-facing behavior.
Original PR description
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. 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 change removes an obsolete delay configuration that is no longer used after a related platform update. It simplifies the codebase and test setup without changing customer-facing behavior.
Original PR description
In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged.
Miscellaneous changes
Imperial UoM can sometime create a discrepancy in between the demand and the actual quantity move, this is mostly expected. However, when the user force set the quantity manually, a ValidationError could be raised because Odoo tried to create a new stock.move.line with the difference. This test ensure that a move line with a product uom quantity of 0 does not impact the Quants reserved quantity. https://github.com/user-attachments/assets/661c23e2-2de1-4328-aad8-b4e6d80e0500 # HOW TO R
Original PR description
Imperial UoM can sometime create a discrepancy in between the demand and the actual quantity move, this is mostly expected. However, when the user force set the quantity manually, a ValidationError…
Imperial UoM can sometime create a discrepancy in between the demand and the actual quantity move, this is mostly expected. However, when the user force set the quantity manually, a ValidationError could be raised because Odoo tried to create a new stock.move.line with the difference. This test ensure that a move line with a product uom quantity of 0 does not impact the Quants reserved quantity. https://github.com/user-attachments/assets/661c23e2-2de1-4328-aad8-b4e6d80e0500 # HOW TO REPRODUCE - Create Product P, with oz uom - Set available quantity to 10 oz - Create delivery transfer for 150g of P > Confirm > Assign - -> Reserved quantity is 149.97 g (expected) which is 5.29 oz - Set Quantity to 150 g - => ValidationError: "Quantity or Reserved Quantity should be set." - Unreserve > Set Quantity to 150g == No problem ... OPW-4659565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205255 Forward-Port-Of: odoo/odoo#203765
Improve references computation, notably when message history consists mainly in note-like messages (tracking with subtypes, ...). After odoo/odoo#197127 threads are split in email readers are references are missing. Task-4677717 Forward-Port-Of: odoo/odoo#204227 Forward-Port-Of: odoo/odoo#203739
Original PR description
Improve references computation, notably when message history consists mainly in note-like messages (tracking with subtypes, ...). After odoo/odoo#197127 threads are split in email readers are references are missing. Task-4677717 Forward-Port-Of: odoo/odoo#204227 Forward-Port-Of: odoo/odoo#203739
Issue ----- When in a branch company, products from the parent company are not visible in the catalog. Steps to reproduce ----- - Install "Sales" app - Go to Settings > Users & Companies > Companies - Create the "Main Company" Company - Add Branches to "Main Company" - Switch companies to "Main Company" - Create a product "A" and set the company to "Main Company" - Switch to one of the branch companies - Create a new Quotation -> The product is displayed from the dropdown li
Original PR description
Issue
-----
When in a branch company, products from the parent company are not visible in the catalog.
Steps to reproduce
-----
- Install "Sales" app
- Go to Settings > Users & Companies > Companies
- Create the "Main Company" Company
- Add Branches to "Main Company"
- Switch companies to "Main Company"
- Create a product "A" and set the company to "Main Company"
- Switch to one of the branch companies
- Create a new Quotation
-> The product is displayed from the dropdown list but not in the Catalog
Cause
-----
Branches have a different id from their parent company. The search domain only includes the current companies but not its' parents.
We can simply include the parent company in _get_product_catalog_domain (of the product_catalog_mixin class).
-----
Ticket:
opw-4472464
Forward-Port-Of: odoo/odoo#200520
Forward-Port-Of: odoo/odoo#197620Description of the issue/feature this PR addresses: **Description:** > - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line **Steps:** > - Install the "website_customer" module. > - Create a "Website Tag" from the Contacts app-> Configurations. > - Add the tag to any partner's "Website Tags" field (inside the "Sales & Purchase" page). > - Go to the website and open the "Customers" menu(from url). Current behavior before PR: Before F
Original PR description
Description of the issue/feature this PR addresses: **Description:** > - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line **Steps:** > - Install the…
Description of the issue/feature this PR addresses:
**Description:**
> - When we open the 'Customers' menu on the website, the 'tags' are displayed in a single line
**Steps:**
> - Install the "website_customer" module.
> - Create a "Website Tag" from the Contacts app-> Configurations.
> - Add the tag to any partner's "Website Tags" field (inside the "Sales & Purchase" page).
> - Go to the website and open the "Customers" menu(from url).
Current behavior before PR:
Before Fix:
After Fix:
Desired behavior after PR is merged:
- All Tags are appropriately shown after my fix
- The issue comes in version 17.0, 18.0, saas~18.1, and saas~18.2
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#203772After https://github.com/odoo/odoo/pull/144586, the modules other than base localization module should not have the `countries` key defined in their manifest. The issue happens because `countries` key works similar to auto-install and it can lead to unwanted installation of the module. As there was no check implemented, for some modules this key was used accidentally and caused issues with auto-install. This commit removes this field from the manifest of the modules that could have this
Original PR description
After https://github.com/odoo/odoo/pull/144586, the modules other than base localization module should not have the `countries` key defined in their manifest. The issue happens because `countries` key works similar to auto-install and it can lead to unwanted installation of the module. As there was no check implemented, for some modules this key was used accidentally and caused issues with auto-install. This commit removes this field from the manifest of the modules that could have this problem to avoid the issue. Also in https://github.com/odoo/odoo/pull/201526 a linting test is proposed to avoid having the same issue in the future. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201610
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If the cookie is present, check if it is valid (request opening cursor in next test) - Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next) - custom expected cookie for browser js to avoid allowing a request after w
Original PR description
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If…
Partial backport of #202835 Nicer strategy for stable to avoid braking all existing clients tests This should catch most case without introducing a lock and a mandatory allowance of the request. - If the cookie is present, check if it is valid (request opening cursor in next test) - Check if the test cursor was opened in the same test as the execute/rollback (request started in previous test executing in next) - custom expected cookie for browser js to avoid allowing a request after wait_remaining_requests All message could be silenced to kill the transaction without braking the test if it is a better strategy. Some design choices: - current_test is passed to Testcursor to avoid to add an import to odoo modules in sql_db, only impacts test logic. Parameter is optional. - test cursor checks current_test before each operation (execute, commit, rollback). - http_request_key is the test itself (between setup and cleanup), only exception is for browser js to avoid request executing during the end of the test (once browser is closed). It is the most common case. Forward-Port-Of: odoo/odoo#205487 Forward-Port-Of: odoo/odoo#205190
When a purchase order is created with a positive and negative quantity of the same product but different unit prices, the read_group runs into a division by zero error as the `SUM('purchase_report'.'qty_ordered')` is zero. To prevent this exception, we NULL the denominator if it's 0. **Example PO that would cause issues when adding "Average Cost" as a measure in the purchase report:**  opw-4684787
Original PR description
When a purchase order is created with a positive and negative quantity of the same product but different unit prices, the read_group runs into a division by zero error as the `SUM('purchase_report'.'qty_ordered')` is zero.
To prevent this exception, we NULL the denominator if it's 0.
**Example PO that would cause issues when adding "Average Cost" as a measure in the purchase report:**
opw-4684787
Forward-Port-Of: odoo/odoo#204674In Modelo 390 section 1, the value for [33] and [34] are wrong. - For [33], the balance of [27] and [29] are missing in the sum expression. - For [34], the balance of [28] and [30] are missing in the sum expression. By fixing those two expressions, the total match the Modelo 303 totals. opw-4520183 Forward-Port-Of: odoo/odoo#205403
Original PR description
In Modelo 390 section 1, the value for [33] and [34] are wrong. - For [33], the balance of [27] and [29] are missing in the sum expression. - For [34], the balance of [28] and [30] are missing in the sum expression. By fixing those two expressions, the total match the Modelo 303 totals. opw-4520183 Forward-Port-Of: odoo/odoo#205403
Fixes ``` File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end self._process_end_unlink_record(record) File "/home/odoo/src/odoo/addons/website/models/ir_model_data.py", line 35, in _process_end_unlink_record return super()._process_end_unlink_record(record) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2576, in _process_end_unlink_record record.unlink()
Original PR description
Fixes ``` File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end self._process_end_unlink_record(record) File…
Fixes
```
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/addons/website/models/ir_model_data.py", line 35, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2576, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 612, in __getitem__
return self.registry[model_name](self, (), ())
~~~~~~~~~~~~~^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/modules/registry.py", line 240, in __getitem__
return self.models[model_name]
~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'my.custom.model'
```
To reproduce:
* add a model with a tracked field to a module
* create a record and update field value to create a tracking message
* remove the model from the module and update the module
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204978**Problem:** On a repair order, if the user is changed it changes the location (and recycled parts destination location) to the default one. Additionally, when the order is confirmed, there is no way to change manually the location. The problematic use case is that if you first confirm the RO and then change the user, it will trigger a change of the location that you won't be able to revert manually. **Steps to reproduce:** - enable location in DB - create a new repair order - change the
Original PR description
**Problem:** On a repair order, if the user is changed it changes the location (and recycled parts destination location) to the default one. Additionally, when the order is confirmed, there is no way…
**Problem:** On a repair order, if the user is changed it changes the location (and recycled parts destination location) to the default one. Additionally, when the order is confirmed, there is no way to change manually the location. The problematic use case is that if you first confirm the RO and then change the user, it will trigger a change of the location that you won't be able to revert manually. **Steps to reproduce:** - enable location in DB - create a new repair order - change the location and recycled parts destination location - confirm the repair order - change the responsible user **Current Behavior:** The location and recycled parts destination location fields values are changed to the default value for this operation type. **Expected Behavior:** The values of those fields shouldn't change after the repair order is confirmed. **Cause of the issue:** The _compute_picking_type_id depends on "user_id" and is therefore triggered when the user is changed https://github.com/odoo/odoo/blob/1445d5adabf8eabe83e842c214655a74434bad4d/addons/repair/models/repair.py#L196 This triggers the _compute_location_id and _compute_recycle_location_id methods because they depend on "picking_type_id" https://github.com/odoo/odoo/blob/fa41c1d50f10ebab08437557ee863348a63de2c0/addons/repair/models/repair.py#L204 This happens regardless of whether the repair order has been confirmed. Because the list of compute methods to be triggered when user_id is changed is computed all at once before running them, adding an if statement at the beginning of _compute_picking_type_id (preventing the change of value of picking_type_id if the state is not "draft") would not prevent _compute_location_id and _compute_recycle_location_id to run. Putting an if statement at the beginning of _compute_location_id and _compute_recycle_location_id to prevent the change when the state is not in "draft" is not a good fix either. That's because we wouldn't know if the computation is triggered by a change of user or a change of picking_type_id (in which case we want the computation to run) **Fix:** I removed the 'user_id' dependency on _compute_picking_type_id opw-4555293 Forward-Port-Of: odoo/odoo#202227
Description of the issue/feature this PR addresses: As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generat
Original PR description
Description of the issue/feature this PR addresses: As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the…
Description of the issue/feature this PR addresses:
As a result of the following commit 9a6b8fec280ccf63b14d3fdafdd39f534c54c646 normal users attempting to print invoices in SA company where the invocie has been ZATCA verified, are getting errors if they have insufficient access rights; for instance a normal user who has POS User access and Accounting/Billing is unable to generate PoS orders as they are forced to have the invoice checkbox set in the `l10n_sa_pos` and when the invoice is generated it is giving the following Traceback.
Current behavior before PR:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/api.py", line 1013, in get
cache_value = field_cache[record._ids[0]]
KeyError: 415613
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1161, in _get_
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/odoo/api.py", line 1020, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'account.edi.document(415613,).attachment_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1187, in _get_
recs._fetch_field(self)
File "/home/odoo/src/odoo/odoo/models.py", line 3230, in _fetch_field
self.check_field_access_rights('read', [field.name])
File "/home/odoo/src/odoo/odoo/models.py", line 2986, in check_field_access_rights
raise AccessError(_(
odoo.exceptions.AccessError: The requested operation can not be completed due to security restrictions.
Document type: Electronic Document for an account.move (account.edi.document)
Operation: read
User: 40
Fields:
• attachment_id (allowed for groups 'Administration / Settings')
```
Desired behavior after PR is merged:
To Fix the issue and sudo() the access to the edi attachment
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204912This commit changes a test that checks that we cannot remove a specific member from an article. The issue was that the parameter provided didn't respect the function's signature by giving a `res.users` instead of a `knowledge.article.member`. By chance, it always worked as those model share the field partner_id that represent the same data. But it is updated so that it better represents the correct use of the method. Forward-Port-Of: odoo/enterprise#83024
Original PR description
This commit changes a test that checks that we cannot remove a specific member from an article. The issue was that the parameter provided didn't respect the function's signature by giving a `res.users` instead of a `knowledge.article.member`. By chance, it always worked as those model share the field partner_id that represent the same data. But it is updated so that it better represents the correct use of the method. Forward-Port-Of: odoo/enterprise#83024
After https://github.com/odoo/odoo/pull/144586, the modules other than base localization module should not have the countries key defined in their manifest. The issue happens because countries key works similar to auto-install and it can lead to unwanted installation of the module. As there was no check implemented, for some modules this key was used accidentally and caused issues with auto-install. This commit removes this field from the manifest of the modules that could have this pro
Original PR description
After https://github.com/odoo/odoo/pull/144586, the modules other than base localization module should not have the countries key defined in their manifest. The issue happens because countries key works similar to auto-install and it can lead to unwanted installation of the module. As there was no check implemented, for some modules this key was used accidentally and caused issues with auto-install. This commit removes this field from the manifest of the modules that could have this problem to avoid the issue. Also in https://github.com/odoo/odoo/pull/201526 a linting test is proposed to avoid having the same issue in the future. Runbot Errors: https://runbot.odoo.com/odoo/error/159875 https://runbot.odoo.com/odoo/error/159877 Forward-Port-Of: odoo/enterprise#81178
adding missing access rule (read permission to the group_purchase_user) for the test that checks it build_error-70728 Forward-Port-Of: odoo/enterprise#82753
Original PR description
adding missing access rule (read permission to the group_purchase_user) for the test that checks it build_error-70728 Forward-Port-Of: odoo/enterprise#82753
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should
Original PR description
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the…
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418 Forward-Port-Of: odoo/enterprise#80594