Thursday, November 7, 2024
15 changes · 18.0
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
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.…
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