Thursday, November 7, 2024
22 changes
1 change
Resolved issues and error corrections
Belgian payroll now shows the eco voucher action only for the relevant holiday termination payslip batches. When used, the wizard creates or updates the correct monthly payslip structure so eco vouchers are included accurately without disrupting payslip presentation.
Original PR description
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all…
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all payslips have the wrong structure : CP200HOLN. The eco voucher button should generate or regenerate a monthly payslip with the eco voucher inside. Objective ---------- - Display the button for the good structures. - Change the filtered employee in the eco-voucher wizard to match the structs - Use the good struct for payslips generated from eco-voucher wizard : CP200MONTHLY - Add new rule in the structure to display a line in the payslip if an eco-voucher is add as "other fields". (But hide it in the payslip) Solution ---------- - Condition on structure code changed from CP200HOLN and CP200HOLN1 for the visibility of the eco voucher button. - Employees filter changed for the eco-voucher action - Payslip structure changed for payslips generated from the eco-voucher wizard. - New record added in the CP200MONTHLY structure. Test ---------- Python test added to test if an eco-vouchers line is added to payslips in the batch when the user validate the payslip generation from the eco-vouchers wizard. 3 cases are covered : - generated payslips - existing payslips - edited existing payslips (edited with the edit payslip wizard in cogmenu) task-3598939
15 changes
Resolved issues and error corrections
Timesheets linked to a sales order line now fall back to the project’s analytic account when the sales line does not include the required project account. This prevents errors when recording time on sales-created projects with other analytic plans configured.
Original PR description
6 changes
Resolved issues and error corrections
This update ensures Odoo supports the new Brazilian tax regulations requiring a barcode on each line item. This change is being implemented for Odoo 17 and later versions, focusing on EDI processing. It's based on Avalara documentation to ensure accurate tax calculations for Brazilian transactions.
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168Steps to reproduce: ------------------- 1. Install Timesheets and Sales app 2. Create an SO, add an SOL with a service product that creates a project/task (e.g. Junior Architect), confirm the SO 3.…
Steps to reproduce: ------------------- 1. Install Timesheets and Sales app 2. Create an SO, add an SOL with a service product that creates a project/task (e.g. Junior Architect), confirm the SO 3. Remove the analytic account of the 'Project' plan from the SOL's analytic distribution 4. Add an analytic account for another plan such as 'Departments' (Basically, the 'Project' plan shouldn't be set but the distribution shouldn't be empty either) 5. Add a timesheet and link it to the project of the SO and to the SOL that we've just created 6. Error because the SOL doesn't have an account for the 'Project' plan Fix: ------------------- Before this commit, when the timesheet was given an SOL, we were only relying on its distribution to give its analytic accounts to the timesheet at timesheet creation/update (see _timesheet_preprocess_get_accounts()). We now take into account the project's account_id if no account_id was found in the SOL's distribution (see _timesheet_postprocess()). task-4221106 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now ignores certificate subject parsing errors caused by special characters in newer cryptography libraries. This prevents affected customers, such as those with certain Mexico EDI configurations, from being blocked even though the certificates are otherwise valid.
Original PR description
In version 42.0.0+ of the `cryptography` library, which we now use, certain special characters in the subject/issuer fields of certificates may cause parsing errors. While the certificates are recognized correctly, attempting to access a subject or issuer attribute with special characters sometimes throws an exception due to parsing issues. ### Fix This issue appears to be specific to recent versions of `cryptography`, as the same certificate values can be successfully retrieved using `openssl`. Currently, we only access the `commonName` attribute from the subject field, which is not used in any critical way in our application. Given this, and due to the blocking nature of this issue for customers requiring specific EDI setups (e.g., in Mexico), we have opted to bypass such cases for now by ignoring these parsing errors. opw-4295754 opw-4293293
Embedded components in the HTML editor now share the same underlying lifecycle as the main page instead of running separately. This prevents unpredictable crashes when embedded content opens interface elements like popovers, making editing more stable for users.
Original PR description
Context: Every Embedded Component was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to…
Context: Every Embedded Component was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile its template. Issue: Now all pieces together in a problematic example case: Creating a new popover from a Embedded Component involves the `main_components` registry: - Create a OverlayItem (position logic (wrapper)). It is created within the main App through the registry, and its lifecycle is managed by the main App Scheduler. - Fill it with a Custom Component (business logic). It is created within the Embedded Component App, and its lifecycle is managed by the Embedded Component App Scheduler. Issue: Now all pieces together in a problematic example case: A component rendered within the Embedded Component App, and therefore handled by the scheduler of the Embedded Component app is added within a popover through the service, and that popover component is rendered within the main App, and therefore handled by the scheduler of the main App. Both schedulers lifecycle handling are not synchronized, and at some indeterministic point one of the Apps will crash during the manipulation of that popover. Solution: Use the new "subroots" OWL feature instead of using sub-apps, so that all templates are created from the same App, and the scheduler is the same for all components. This also has the advantage of not having to re-compile all templates for every Embedded Component. task-4300215
Manufacturing labour costs now remain on the appropriate work center expense accounts instead of being moved back during final product valuation. This gives businesses clearer and more accurate production cost reporting by preserving where labour expenses were actually incurred.
Original PR description
Since https://github.com/odoo/odoo/pull/169257, we've created separate valuation journal items for MO employee and workcenter costs with items on expense accounts that can be set on a per-workcenter…
Since https://github.com/odoo/odoo/pull/169257, we've created separate valuation journal items for MO employee and workcenter costs with items on expense accounts that can be set on a per-workcenter basis. However, in the final product account move, we move these amounts back to the Cost of Production account as to not have a net impact on the expense accounts after production. This PR leaves the labor costs on the WC expense accounts instead of putting them back on the COP account in the final product account move. **To reproduce:** - Enable automatic accounting with FIFO for all products - Create storable products F and C - Purchase 100 C with unit price 50 and receive the products - Create a BOM for F with component 1 C and 1 WO (60 min, assembly 1) - Create, confirm and produce MO for 1 F - Open accounting and view the newly created journal entries **Current behavior:** - On the entry for F, an expense item is created with a credit value equal to the labor cost. - On the labor entry, an expense item is created with a debit value equal to the labor cost, and a Cost of Production item with matching credit. **Expected behavior:** - The entry for the final product should have no expense entries for labor, only the COP credit and SV debit (final product value). - The entry for labor should have a credit value on the expense item, and a matching debit value on the Cost of Production item. task-4267713
Recruitment officers can now use the “Load Sample data” option without running into an access error. This helps teams set up or test recruitment workflows without needing administrator assistance.
Original PR description
Currently an error was generated when the user with access right `Officer: Manage all applicants` tries to load recruitment data by clicking `Load Sample data` from recruitment. error: `ParseError: while parsing /home/odoo/src/odoo/18.0/addons/hr_rec...` This is because when the user tries to load recruitment data, it tries to create a `Mail Tracking Value` that requires admin rights. This commit allows non-admin users to load the recruitment scenerio and make the `Load Sample data` button visible to the recruitment users. sentry-6042340046
Adds a dedicated accounting entry for Chilean businesses that factor receivable invoices. This supports better handling of invoice transfers to third parties, helping improve cash flow tracking and compliance with Chilean electronic tax requirements.
Original PR description
Description of the issue/feature this PR addresses: This adds a new account for factoring invoices (related to: https://github.com/odoo/enterprise/pull/70696) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an ecommerce issue where shop pages could fail to load when products used custom tax formulas based on product fields. Customers can now browse affected products normally, reducing disruption during online shopping.
Original PR description
Have a tax with Tax Computation set to 'Custom Formula', depending on a product.<product_field> (i.e. product.list_price)
Add that tax to a product shown in website shop
Access Ecommerce
Error
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
ValueError: Expected singleton: product.template(17, 18, 23, 8)
Template: website_sale.products_item
Path: /t/form/div[2]/div[2]/div[2]/span[1]
Node: <span class="h6 mb-0" t-if="template_price_vals[\'price_reduce\'] or not website.prevent_zero_price_sale" t-out="template_price_vals[\'price_reduce\']" t-options="{\'widget\': \'monetary\', \'display_currency\': website.currency_id}"/>
Compiled code:
code = None
template = 'website_sale.products_item'
```
This occurs because we call `compute_all` with multiple product templates
opw-4295796Fixes an issue where frozen and shared spreadsheets could lose formatting and styles on secondary sheets after applying a global filter. This ensures shared spreadsheet links preserve the intended presentation for viewers.
Original PR description
steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - add a global filter - leave the spreadsheet and open it again (to force a snapshot, until bug fix 4299935 is merged - set a value in the global filter - hit the "Freeze & share" button - open the sharing link in an incognito window => formats and style in the second sheet are missing Task: 4300401 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
Frozen and shared spreadsheets now preserve the formatting of Odoo pivot data, such as numbers or values. This prevents shared spreadsheet links from showing raw or incorrectly formatted data, improving readability for recipients.
Original PR description
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - leave the spreadsheet and open it again (to force a snapshot, until bug fix 4299935 is merged - hit the "Freeze & share" button - open the sharing link in an incognito window => formats on values are missing. Bug introduced with https://github.com/odoo/o-spreadsheet/commit/c3c0b45ed1eae582f5ad Task: 4300026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that could prevent UK tax returns from being sent to HMRC. This helps accounting users complete the tax return submission flow reliably after a recent internal field-name change.
Original PR description
Install "l10n_uk"
Accounting / Reporting / Statement Reports / Tax Return
Actions / Send to HMRC
Issue: Traceback will raise
```
ValueError: Invalid field l10n_uk.vat.obligation.currency_table_period_key in leaf ('currency_table_period_key', '=', '18A1')
```
It occurs after e598fcb48b5e4f0126406a4008f175a88528ba85 replaced occurrences of `period_key` with `currency_table_period_key`
opw-4283511Company administrators can now open the Documents app without access errors when documents belong to companies they cannot access. The update also corrects how shared and company document filters determine visibility, improving consistency for multi-company setups.
Original PR description
Reproduce: 1/ Create documents and assign a company an admin (`group_erp_manager`) doesn't have access to 2/ As that admin, open the Documents app 3/ Go to "Home" and expect an Access Error There was a mismatch between `user_permission`'s search and compute methods for admins. We also take the opportunity to fix the SHARED (and clean COMPANY) search panel `CategoryDomain`s as odoobot's ownership wasn't used to make documents visible in COMPANY (therefore not in SHARED) on its own. A test is added. Task-4241620
This fixes an error that could prevent users with Mexican company setups from sending payment receipts by email. The payment process now includes the missing information needed for Mexican electronic invoicing attachments, avoiding an unexpected crash.
Original PR description
With an MX company setup Create a Payment Action > Send receipt by email Traceback will raise ``` KeyError: 'l10n_mx_edi_cfdi_attachment_id' ``` It occurs because the field is not defined on the payment model opw-4298457
Fixed an issue where frozen shared spreadsheets created from pivot views could open as a blank page. The copy process now avoids carrying over outdated edit history when fresh frozen spreadsheet data is used, improving reliability for shared spreadsheet links.
Original PR description
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - hit the "Freeze & share" button - open the sharing link in an incognito window => blank page When the document is copied (using the `copy` method), the frozen data is given as a new value for `spreadsheet_data`. But revisions are still copied even though new data is provided on which the revisions should not apply. Task: 4299935
This update fixes two appointment booking issues that could confuse customers: HTML tags no longer appear in appointment descriptions, and available time slots now stay aligned with the month shown on the calendar. This helps prevent users from accidentally booking a slot for a date outside the calendar view.
Original PR description
1. Hide tags in description when changing appointments in the appointment selection dropdown 2. Make sure slots of previous date shown are in the current month when changing resource / user / tz in the dropdowns. Otherwise, display no slots. Task-4169513
Closing a subscription now also stops any related recurring project tasks. This prevents new tasks from being created after the customer subscription has ended, keeping work lists aligned with active billing.
Original PR description
Steps: Create a product of type service that creates a task. Create a subscription with that product, and confirm. Note that if you set the task's state to done, it creates another one. Close the subscription. Issue: If you set the task's state to done, it still creates another one, whereas it would make sense that the task's recurrence ends with the "invoice recurrence". Cause: Actually, it was first designed that way, and `_set_closed_state` was overridden to unlink the recurrence. But then that method and `set_close` were rethought and the override wasn't called anymore. Solution: Just do the same thing, but in `set_close` i/o `_set_closed_state`. task-4259561
This update corrects a bug in the Spanish tax reporting module (l10n_es_reports) that prevented the 'Type for mod 347' field from automatically setting to the correct default value ('Regular operation'). This ensures invoices comply with Spanish tax regulations, resolving a potential reporting issue for Spanish customers.
Original PR description
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **Solution:** There were a function for the default (_default_mod_349_invoice_type) and an onchange on partner (_onchange_partner_id_set_347_invoice_type). Both of them were checking different conditions. The fix is merging these 2 methods by converting the field into a computed stored field where both conditions are handled. opw-4194030 Forward-Port-Of: odoo/enterprise#72958
This update fixes an issue where tax closing with fiscal positions wasn't working correctly in Odoo reports. The system now correctly handles all fiscal positions when generating reports, and the closing mechanism has been adjusted to align with intended functionality, particularly for versions prior to 18.0. This ensures accurate tax reporting.
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388
This update resolves a bug where the 'packaging' button wasn't visible when adding products via the barcode app during inventory adjustments. This prevented users from efficiently adding quantities of 15 units, impacting the speed and accuracy of stock management. The fix ensures the button appears correctly, streamlining the inventory adjustment process.
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 ---
This update resolves a bug where subscriptions weren't always creating all expected deliveries due to an error in how invoices were processed. Specifically, the system was incorrectly calling a hook function on empty data, leading to incomplete delivery creation. This fix ensures all subscriptions are correctly processed, preventing missed deliveries.
Original PR description
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook…
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled.
However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron.
This often resulted in a situation where only the first subscription was ready for the hook, while the others are not, resulting in only the first delivery created.
---
Test result before fix:
```
2024-11-06 15:41:52,210 35880 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_cron_product_multiple_delivery_creation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 501, in test_cron_product_multiple_delivery_creation
self.assertTrue(bool(move_1))
AssertionError: False is not true
```
OPW-4166852This update resolves an issue where the barcode app incorrectly displayed a single unit count (1/1) after editing a delivery order. The fix ensures that the system accurately reflects the remaining quantity (0/4) when returning to the record, maintaining data consistency for barcode scanning.
Original PR description
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by…
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by clicking the external link arrow next to the location). - Come back to the record #### > The line now displayed a 1/1 but does not records what remains: 0/4. ### Cause of the Issue: Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update its quantity. However, when you leave the barcode, even thought it will save these change, it will not split the move in 2 for the barcode app to be able to rely on the backend data to generate a correct sate of the record. Threfore, when you come back to the record, the main component will be regenerated from the backend values of the `get_barcode_data`: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L76-L80 And will onlydisplay the "1/1" line that was reported fromt he back end. ### Fix: The `split_uncompleted_moves` method taking care of splitting the moves for barcode data compatibility: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/models/stock_move.py#L9-L11 is already called when you exit the barcode via the exit button: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L228-L231 https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/models/barcode_picking_model.js#L762-L765 These were added by commit 2eb6465e4f18c701efdf28ea4b8f95f3119d3db8 However, it should IMO be called every time you leave the app that is just before destroying the component. Furthermore, note that it will only split the moves if a save happend (which is the expacted behavior). opw-4232106 ---