Wednesday, November 13, 2024
18 changes · 17.0
Resolved issues and error corrections
Editable list views now show the Save and Discard buttons correctly on small screens. This lets mobile users finish or cancel record edits without getting stuck when the New button is replaced.
Original PR description
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: reported during the mobile tests conversion to HOOT in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deleting a newly created customer no longer triggers an audit trail error when audit trail is not active for any related company. The check now only blocks deletion when the customer has journal entries in a company where audit trail is enabled, preventing unnecessary errors for accounting users.
Original PR description
To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet quarter filters now return standard quarter labels (Q1 to Q4) even when the user's language translates the letter Q. This prevents finance dashboard formulas from breaking in translated interfaces, such as French.
Original PR description
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where export options in a report dropdown could slip behind the report header after being clicked, preventing the selected action from running. This ensures users can reliably choose options such as XLSX or PDF exports from report dropdown menus.
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the button has been clicked, the dropdown menu disappears behind the header of the report. **Cause:** The buttons in the dropdown menu have z-index:1000 and the thead of the report has the z-index:999, which displays the buttons in front the header of the report. However, when clicked, the button becomes active and its z-index falls to 2, putting it behind the header. opw-4265087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employees can now change the payment method/provider when registering customer payments. This removes an access-rights blocker that prevented normal payment entry workflows when online payment providers were configured.
Original PR description
**Issue:** An employee can't modify a `Payment Method` (other than "Manual" on a new payment entry). **Expected:** An employee should be able to change the payment provider to register a customer payment. **Steps to reproduce:** - Activate Accounting app and go to Configuration > Online Payments > Payment Providers; - Install any of these providers, configure it, activate the test mode and publish it; - Go to Customers Payments > Payments; - Open or create a payement record; - Try to change the Payment Method field for . **Cause:** No rights have been given to users on the payment provider data lookup. https://github.com/odoo/odoo/blob/18.0/addons/payment/security/ir.model.access.csv **Fix:** Give temporary rights on payment provider token lookup. opw-4270781 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swiss QR invoice reports now display the current bank partner name next to the QR code instead of an outdated account holder value. This prevents invoices from showing an old company name after the company name has been changed, reducing customer confusion and document inaccuracies.
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to the Swiss company - In the Accounting settings activate the QRcodes on invoices - Change the name of the Swiss company - Create an invoice - The old company name is still displayed next to the QR code ### Cause: The field displayed is the field `account_holder_name` which is not updated when changing the company name. Solution: As the field `account_holder_name` is not supposed to be shown anymore in 18.0, we can display directly the partner name. opw-4273688
The mail app now removes the “is typing” indicator from the previous conversation when a user switches to another thread. This prevents stale typing messages from lingering and improves clarity in chat discussions.
Original PR description
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product replenishment now calculates the expected date reliably when using purchase or manufacturing routes, regardless of the database language. This ensures vendor lead times are applied correctly for non-English users, improving planning accuracy.
Original PR description
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when…
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time. - Change the language of the database to a different language. - Repeat the replenish process. - Observe that the schedule date is not calculated correctly. ## Solution: - Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons.. opw-4199660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale ticket invoice requests now find matching orders even when the store's local date differs from the UTC date stored by the system. This prevents customers or staff from seeing “No sale order found” for valid receipts created later in the day in some time zones.
Original PR description
Steps to reproduce: [point_of_sale] - activate "Generate a code on ticket" option in PoS settings. - have a PoS session in GMT-6 and create an order after 6pm local time. - go to /pos/ticket, enter the order information and the date that appears on the ticket - ** No sale order found ** Cause The `date_order` of the sale order is stored in UTC while the date displayed on the ticket is in local time. Change This commit makes the search domain bigger to account for orders made in different timezones. opw-4311152
Users can now edit an event's short description directly from the Events page using the website editor. This removes an unnecessary editing limitation and helps teams update event listings more quickly without navigating elsewhere.
Original PR description
Steps to reproduce the issue: 1. Navigate to the Events page. 2. Activate the Web Editor. 3. Attempt to edit the Event's short description. Issue: The short description of the event was previously not editable directly from the Events page. the reason behind that is they have used `t-out` instead of `t-field` in template. `t-out` lacks the necessary attributes to enable field updates. Solution: This PR adds the necessary attributes to the short description element, making it editable from the Events page. Updated the tour functionality to test the latest changes of Event's short description. task-4014153
This fixes cases where manufacturing work orders could stay stuck in a waiting state after related production was completed. It also prevents an error loop during status recalculation, improving reliability for manufacturing workflows.
Original PR description
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a rare setup issue where EU OSS tax mapping could fail if a country-specific localization module was not installed. Odoo now skips missing tax references in that case, preventing an unnecessary crash during tax configuration.
Original PR description
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat number for a specific country, it means they have a tax report to fill and thus must have installed the related localization either as main CoA or as a foreing fiscal position. 2) This was spotted through a runbot single l10n build error. Nevertheless, it is something that is possible and thus should be working smoothly. runbot-100532
This update addresses a minor constraint issue that triggered when resetting customer payments in older versions of Odoo. The fix, originally implemented in 17.4, has been reverted for previous versions due to limitations in applying the same solution. This ensures stability across all Odoo releases.
Original PR description
This reverts commit 4d548d2240c85eebe004595cd65e0fbb6a76a39b. To reproduce the issue: 1. Create a customer payment and post it 2. Create a customer batch payment 3. Asociate that payment to the batch and validate it 4. Reset payment to draft ====> A constraint on the batch is triggered. In 17.4, we solved it by removing that check from the constraint, since the same check was done at batch validation: 3e307ec2fa5191fcc657316a125dae208975f82b . In lower versions, the validation does not do that, so we can't apply the same fix. Since the dependency issue can only be annoying in case of customizations, we make the choice to live with it for old versions. Forward-Port-Of: odoo/enterprise#73495
This update corrects a misconfiguration within the Ecuadorian localization (l10n_ec_edi) module, specifically the default account for purchase journals. The fix ensures accurate financial reporting for businesses using the EC localization, resolving a previous error. This improves the reliability of financial data for Ecuadorian clients.
Original PR description
We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#69561
This update resolves a stability issue in the Knowledge module's Behavior system. Previously, conflicting scheduler lifecycles caused crashes when creating popovers. By using a new 'subroots' feature, all templates are now managed from a single App, eliminating this synchronization problem and improving overall system stability.
Original PR description
Context: Every Behavior in Knowledge 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…
Context: Every Behavior in Knowledge 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 Behavior App involves the `main_components` registry: - Create a PopoverController (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. 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 Behavior. task-4300215 Forward-Port-Of: odoo/enterprise#73224
This update resolves a validation issue with Quadrum, a key certification provider, preventing failed CFDI invoice submissions. The problem stemmed from rounding discrepancies during payment rate calculations in USD, leading to incorrect payment amounts. This fix ensures accurate CFDI validation for Quadrum users, improving compliance and avoiding disruptions to invoicing.
Original PR description
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC…
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one of the payments, click 'Force CFDI' Issue: Validation will fail with error Note: This does not occur with other providers (Solucion Factibles) ``` Code : CRP20275 Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado, convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto. ``` This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance opw-4314798
This update ensures that a new employee's payslip basic salary is set to zero when no work hours are recorded, addressing a discrepancy in the salary configuration. This prevents incorrect wage calculations for provisional contracts and aligns with best practices for employee compensation.
Original PR description
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab >…
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure. We can't just set it to 0 though: This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0. This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach. opw-4266880
This update resolves a display issue within the Barcode app where both 'Add By-Product' and 'Validate' buttons were visible when viewing by-product move lines. This change ensures a cleaner user interface and prevents confusion for users working with by-product inventory.
Original PR description
Before this commit, the buttons "Add By-Product" and "Validate" are both visible when the user is in a by-product move line form view from the Barcode app. This should not happen.