Friday, November 1, 2024
9 changes · 18.0
Resolved issues and error corrections
Worldline payment updates now use the stable payment ID from the notification instead of a checkout-only field. This helps Odoo correctly match payments received through webhooks, reducing failed or incomplete payment reconciliation.
Original PR description
Description of the issue/feature this PR addresses: 'hostedCheckoutSpecificOutput' is not a valid key when passing through the webhook as it's only available when returning from checkout. Using the id key instead as its left part is the exact unique payment id we want to save.
Users who can view a record but cannot edit it will no longer be shown an option to add a log note in the chatter. This prevents them from running into an error after trying an action they are not allowed to complete, improving the experience and reducing confusion.
Original PR description
Currently, a user without access rights can attempt to post a log note in various chatters. This will trigger a NotFound() error after their access rights are denied which leads to poor user experience. To avoid this I have adapted logic from the Send Message Button to also apply to the log note button for users with read access but not write access. OPW-4280451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes automated checks for Mexican electronic invoicing so they no longer fail simply because the calendar month changed. It helps keep development and release validation stable without changing customer-facing invoicing behavior.
Original PR description
The test started failing during the next month. This commit follows the same guideline as the other test files of the module by using `__ignore__`, not using `freezegun` or other options.
Miscellaneous changes
Steps: - enable lots & serials - enable 'Use Existing ones' in operation type 'Receipts' - create a product A tracked by lot - create a receipt operation, add product A, add quantity, mark as todo - open burger menu, add a new lot number, select 'Create' (not 'Create and edit...') Issue: `default_product_id` missing in the context because of `getFieldContext` in utils.js filtering it out. Due to that, Odoo will open a new popup as if we selected 'Create and edit...'. Fix: Remove th
Original PR description
Steps: - enable lots & serials - enable 'Use Existing ones' in operation type 'Receipts' - create a product A tracked by lot - create a receipt operation, add product A, add quantity, mark as todo - open burger menu, add a new lot number, select 'Create' (not 'Create and edit...') Issue: `default_product_id` missing in the context because of `getFieldContext` in utils.js filtering it out. Due to that, Odoo will open a new popup as if we selected 'Create and edit...'. Fix: Remove the lot line in pick_from.js, it is not needed and there's another lot_id in the xml to use. opw-4064895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174496
**Current behavior:** Creating an import file with enough blank rows to require import via batches will cause duplicate records from previous batches. **Expected behavior:** No duplicates. **Steps to reproduce:** *E.g., `-i contacts`* 1. Create a csv file with a partner record on row 1 (or 2 if using headers, just the name is enough for `res.partner`) and another record on row 2002 or higher 2. From contacts action button, select import records, upload the csv from step 1, import
Original PR description
**Current behavior:** Creating an import file with enough blank rows to require import via batches will cause duplicate records from previous batches. **Expected behavior:** No duplicates. **Steps to…
**Current behavior:** Creating an import file with enough blank rows to require import via batches will cause duplicate records from previous batches. **Expected behavior:** No duplicates. **Steps to reproduce:** *E.g., `-i contacts`* 1. Create a csv file with a partner record on row 1 (or 2 if using headers, just the name is enough for `res.partner`) and another record on row 2002 or higher 2. From contacts action button, select import records, upload the csv from step 1, import 3. See that the 2 records were imported 2x each **Cause of the issue:** When the `file_length` (literal number of lines) is big enough to require batches, but the actual number of rows with data is not, the upload mechanism will try to (in the case described here) upload 2 batches of records. But because there isn't actually a full batch of records, the second batch will just be the same as the first (second batch starts from row 0 "bookmark", because all the data rows were processed in their entirety in the first batch). **Fix:** Make `file_length` returned by the server to client the length of the actual data rows parsed from the file, as opposed to the literal number of lines. opw-4271105 Forward-Port-Of: odoo/odoo#185634
Importing bills was a planned feature that got scrapped due to limitation of the government api. The endpoints that should allow that have a warning asking to not use them for that purpose at the moment. By mistake, the field stayed when the feature was removed. We will remove it from the view for now, and evaluate later on if we should simply remove it, or if the feature may be added later on. This also iron out some small issues that went through with the original pr. --- I confi
Original PR description
Importing bills was a planned feature that got scrapped due to limitation of the government api. The endpoints that should allow that have a warning asking to not use them for that purpose at the moment. By mistake, the field stayed when the feature was removed. We will remove it from the view for now, and evaluate later on if we should simply remove it, or if the feature may be added later on. This also iron out some small issues that went through with the original pr. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186072 Forward-Port-Of: odoo/odoo#185943
Consider the case that "Predict vendor bill product" is activated in the settings and we upload / import a vendor bill with a single line. In case the product on the line could not be determined by the import function it is predicted afterwards (since the setting is enabled). But changing the product triggers i.e. a recompute of the unit price (`price_unit`) and taxes (`tax_ids`) based on the new product information. This is not what we want since the aforementioned values should be det
Original PR description
Consider the case that "Predict vendor bill product" is activated in the settings and we upload / import a vendor bill with a single line. In case the product on the line could not be determined by…
Consider the case that "Predict vendor bill product" is activated in the settings and we upload / import a vendor bill with a single line. In case the product on the line could not be determined by the import function it is predicted afterwards (since the setting is enabled). But changing the product triggers i.e. a recompute of the unit price (`price_unit`) and taxes (`tax_ids`) based on the new product information. This is not what we want since the aforementioned values should be determined by the import even in case the product is not found. After this commit we protect the unit price and taxes fields during any (product) prediction in case they are set. (We do update the unit price and tax if it is 0 or there are no taxes.) Reproduce 1. Activate "Predict vendor bill product" in the settings 2. Create Customer OpsWay * country = Poland * VAT = PL8992922295 3. Create 3 Vendor Bills manually * date in the past * customer = OpsWay * single invoice line: with product "Commissions" * Confirm 4. Import the PDF attached on the task in Vendor Bills. * It has a single line with quantity 1 and unit price 1,322.40 5. A bill with a single line is created: product = "Commissions" unit price = 0.0 total = 0 task-4279931 Forward-Port-Of: odoo/enterprise#73191 Forward-Port-Of: odoo/enterprise#72625
Description of the Issue/Feature Addressed by This PR: The current system sets the default document type to e-Ticket, regardless of the partner's identification type. However, for usability purposes, if the identification type is RUT/RUC, the document type should default to e-Factura, as this is the correct choice in 95% of cases. Current Behavior Before PR: The default document type is always set to e-Ticket, irrespective of the identification type. Desired Behavior After PR: The syste
Original PR description
Description of the Issue/Feature Addressed by This PR: The current system sets the default document type to e-Ticket, regardless of the partner's identification type. However, for usability purposes, if the identification type is RUT/RUC, the document type should default to e-Factura, as this is the correct choice in 95% of cases. Current Behavior Before PR: The default document type is always set to e-Ticket, irrespective of the identification type. Desired Behavior After PR: The system will automatically select the appropriate document type (either e-Factura or e-Ticket) in the account.move module, based on the partner's identification type (RUT/RUC or other). This will reduce the need for manual adjustments. Users will still have the flexibility to select other document types to account for any exceptions. Latam-task: 1273 Adhoc-side-task: 44194 Forward-Port-Of: odoo/enterprise#73122 Forward-Port-Of: odoo/enterprise#72305
As of today, the action_account_asset_compute_depreciations server action allows to recompute the board on posted assets by calling compute_depreciation_board. There is two issues with that: - compute_depreciation_board shouldn't be called on assets that could already have moves without providing a date - This action should reflect what can be done on the form view (only applies to draft) The easy fix is to update the action to only affect draft entries. Task id # 4297606 For
Original PR description
As of today, the action_account_asset_compute_depreciations server action allows to recompute the board on posted assets by calling compute_depreciation_board.
There is two issues with that:
- compute_depreciation_board shouldn't be called on assets that could already have moves without providing a date
- This action should reflect what can be done on the form view (only applies to draft)
The easy fix is to update the action to only affect draft entries.
Task id # 4297606
Forward-Port-Of: odoo/enterprise#73111