Friday, November 1, 2024
19 changes
6 changes
Miscellaneous changes
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185972 Forward-Port-Of: odoo/odoo#185419
Original PR description
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185972 Forward-Port-Of: odoo/odoo#185419
Description of the issue/feature this PR addresses: - allow inheriting modules to define own logic about how sale lines should create projects/tasks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185934
Original PR description
Description of the issue/feature this PR addresses: - allow inheriting modules to define own logic about how sale lines should create projects/tasks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185934
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#185943
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argenti
Original PR description
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send…
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argentinian localization. 2. If the tax group was already removed, it will show a useful error message when it can't be found and redirect the user to the settings where they can reload their chart template in order to reinstall the tax group. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3685073](https://www.odoo.com/odoo/all-tasks/3685073) ## [FIX] account: fallback on company data when loading chart template Currently when loading a chart template for a company which is referencing some records by XML ID, we look for these records in the database. This could fail in some cases, like this: - We have a company set up with a CoA and delete one of its default accounts in the company settings and replace it by another account. - We try to create a branch company under the former one. When trying to save the branch company, we try loading the chart template on it, setting also the default accounts. We look in the database for the right reference, but since the parent company deleted the original account, the process fails and the branch can't be created. In this commit we provide a sensible fallback. If the record referenced in the chart template can't be found, we try looking what was already set on the company or its root. As such, we will be able to create the branch successfully and the user can always adapt the defaults later. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3677061](https://www.odoo.com/odoo/all-tasks/3677061) [opw-3681481](https://www.odoo.com/odoo/all-tasks/3681481) [opw-3681456](https://www.odoo.com/odoo/all-tasks/3681456) [opw-3672507](https://www.odoo.com/odoo/all-tasks/3672507) [opw-3669164](https://www.odoo.com/odoo/all-tasks/3669164) [opw-3694606](https://www.odoo.com/odoo/all-tasks/3694606) [opw-3705870](https://www.odoo.com/odoo/all-tasks/3705870) [opw-3704826](https://www.odoo.com/odoo/all-tasks/3704826) Forward-Port-Of: odoo/odoo#183609
**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
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
5 changes
Miscellaneous changes
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. Forward-Port-Of: odoo/enterprise#73199
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. Forward-Port-Of: odoo/enterprise#73199
8 changes
Resolved issues and error corrections
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
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
Steps to reproduce: - Install invoicing enterprise (but not accounting) - Register a payment on an invoice - open the form view of the payment When opening the payment form view, if the payment is associated with a journal entry, which can be accessed with the smart button. However, with invoicing enterprise, this button doesn't make sense because the user will only see the "other info" tab of the journal entry. We therefore limit the access to the button only for accounting users. t
Original PR description
Steps to reproduce: - Install invoicing enterprise (but not accounting) - Register a payment on an invoice - open the form view of the payment When opening the payment form view, if the payment is associated with a journal entry, which can be accessed with the smart button. However, with invoicing enterprise, this button doesn't make sense because the user will only see the "other info" tab of the journal entry. We therefore limit the access to the button only for accounting users. task-4224553 Forward-Port-Of: odoo/enterprise#73036
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#73111Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept. This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title. task-3378510 Forward-Port-Of: odoo/enterprise#54052
Original PR description
Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept. This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title. task-3378510 Forward-Port-Of: odoo/enterprise#54052
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