Thursday, December 12, 2024
11 changes
2 changes
Resolved issues and error corrections
This fix prevents the Point of Sale from repeatedly asking staff to choose a loyalty program when adding products tied to multiple programs. The selection prompt now appears only for gift card or eWallet cases where the choice is actually useful, making checkout smoother.
Original PR description
When clicking on a product that is linked to multiple loyalty programs you are prompted to select one of them everytime you add one item via the ui. Steps to reproduce: ------------------- * Create 2 loyalty programs activated when buying a certain product * Open PoS and click on the product > Observation: You will get a prompt everytime you click on the product Why the fix: ------------ The variable `selected_program` is actually only usefull if the program selected is gift card or an eWallet program. So we filter it before and only prompt when the output will be usefull. opw-4187037
Expense reports with taxes forced to be included in the price now round tax amounts consistently. This prevents valid expense reports from failing with an “Unbalanced Entry” error in specific tax and global rounding setups, such as Canadian GST/QST.
Original PR description
In expenses, we want to keep the tax included in price. Even if the tax is defined as not included in price we force the computation to be price included. However, with specific combination of price…
In expenses, we want to keep the tax included in price. Even if the tax is defined as not included in price we force the computation to be price included. However, with specific combination of price and tax amount, the computation result in amount not rounded correctly. As result, users trying to post journal entry from expense report may face an "Unbalanced Entry" error. Steps to reproduce: - With Canadian accounting set up in Canadian company - Set rounding method to "Round globally" - Create an expense: - Add total: 77.87 CAD - Use tax: 14.975 GST+QST - Paid By: Company - Create Report > Submit to manager > Approve Error will raise ``` The move (Draft Entry (test)) is not balanced. The total of debits equals 77.87 $ and the total of credits equals 77.87 $. You might want to specify a default account on journal "Bank" to automatically balance each move. ``` In this specific configuration, we get tax values from unrounded computations, i.e. we set `amount_currency` to 67.72776690584911, that will be stored as 67.73. However, from the expense report we compute a (correct) balance of 67.72, when the move line is created the balance will be updated from this amount (currency is company currency), so the move balance will be off, raising the error opw-4148134
7 changes
Resolved issues and error corrections
This update fixes an issue where scanning a product barcode in the self-ordering flow caused an error. It also improves the product details popup so quantity changes are shown only when appropriate for combo or configurable products.
Original PR description
Before this commit, scanning a product barcode would result in an error. Additionally, the product info popup did not check for combo and configurable correctly to show the quantity change option. opw-4393761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update fixes an issue where users were seeing work orders assigned to other employees, even when using the 'My Work Orders' filter. The problem stemmed from incorrect cache handling after a PIN code was entered. Now, users will only see work orders assigned to their own account, ensuring accurate shop floor visibility.
Original PR description
Job applications from the same email address now reuse an existing candidate instead of creating a separate duplicate candidate each time. This helps recruitment teams keep applicant records cleaner and avoid confusion when reviewing multiple applications from the same person.
Original PR description
In 18.0 multiple job application from the same email address would create a new candidate for each email received. This PR aims to prevent this by only creating candidates if one does not already exist for the given email address. task-4397959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where Firefox users could lose the last typed character when pressing backspace after a space. Backspace now removes only the intended space, reducing accidental text loss while editing content.
Original PR description
Steps to reproduce: - Open Firefox. - Type a few characters. - Add a space after the characters. - Press backspace. - Observe that both the space and the last visible character are removed.…
Steps to reproduce: - Open Firefox. - Type a few characters. - Add a space after the characters. - Press backspace. - Observe that both the space and the last visible character are removed. Description of the issue/feature this PR addresses: - In Chrome, pressing space inserts a ` ` (non-breaking space, `U+00A0`), which is treated as a visible character by `isVisibleChar`. Thus, only the whitespace is removed when backspace is pressed. - In Firefox, pressing space inserts a regular space (`U+0020`), which `isVisibleChar` identifies as invisible. As a result, the backspace action incorrectly calculates the range and removes both the space and the preceding character. Character details: - Chrome: `char.charCodeAt(0).toString(16)` → `U+00A0` - Firefox: `char.charCodeAt(0).toString(16)` → `U+0020` Desired behavior after PR is merged: - In Firefox, pressing backspace after a whitespace removes only the invisible character without affecting the preceding visible character. task-4363847
This fixes an error that prevented Hungarian companies from printing customer invoices issued in currencies other than HUF. The invoice report now consistently includes the required VAT amount in HUF, while preserving the correct handling for refunds and credit notes.
Original PR description
Problem --------- 1 - Open Odoo 18.0 2 - install l10n_hu_edi 3 - switch to "HU Company" 4 - create an outgoing normal invoice with other than HUF currency 5 - put items, taxes, select partner, etc. 6…
Problem --------- 1 - Open Odoo 18.0 2 - install l10n_hu_edi 3 - switch to "HU Company" 4 - create an outgoing normal invoice with other than HUF currency 5 - put items, taxes, select partner, etc. 6 - print the invoice -> KeyError: 'formatted_total_vat_amount_in_huf' The issue occurs because, in multi-currency, the method `_l10n_hu_get_invoice_totals_for_report` is expected to add `total_vat_amount_in_huf` to the tax dictionary as required by the invoice template. However, currently, the said method only adds `total_vat_amount_in_huf` for credit notes / refunds, in other cases, it stops early and does not add the required key-value pair in the dictionary. Solution --------- Make sure the method always adds `total_vat_amount_in_huf` to the tax dictionary, while making sure that it only reverses the tax values when it is rendering a credit note / refund like before. task-4391659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when shoppers use product comparison with product specifications shown in an accordion. It avoids a naming conflict so eCommerce product pages and comparison features work reliably together.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. go to a product with attributes; 3. open the editor; 4. set specification to display in accordion; 5. enable "Compare" option on Cart.…
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. go to a product with attributes; 3. open the editor; 4. set specification to display in accordion; 5. enable "Compare" option on Cart. Issue ----- > 500: Internal Server Error > Error while render the template > TypeError: tuple indices must be integers or slices, not product.public.category > Template: website_sale_comparison.specifications_table Cause ----- The `categories` value set in this template contains an ordered dict with `product.attribute.category` records as keys, and `product.template.attribute.line` records as values. When inserting its logic into the `website_sale` template, its variable name conlficts with the `categories` value returned by the `WebsiteSale` controller, which contains `product.public.category` records. The issue occurs when it tries to use a `product.attribute.category` record to index a `product.public.category` recordset. Solution -------- Rename the `categories` variable to `attrib_categories` in the `website_sale_comparison` template. opw-4356669
This fixes invoice accounting totals when Avalara returns multiple distinct taxes that Odoo displays under the same short tax name. Instead of replacing one tax amount with another, Odoo now adds them together so invoice totals match the journal entries.
Original PR description
In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.: ``` Charleston Co Educational Capital Improvements Tax (Special) at 1%…
In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.: ``` Charleston Co Educational Capital Improvements Tax (Special) at 1% Charleston Co Tt (Special) at 1% ``` But `find_or_create_tax()` maps both of them to SC SPECIAL 1%. This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets overwritten instead of added to. This leads to the total on the invoice not matching the sum of debits/credits in the journal items tab. Fix it by adding to the summary total instead of overwriting it. PS. An alternative solution is to create unique tax names by incorporating the jurisCode and possibly other relevant fields. This approach would enhance the accuracy of tax representation on invoices. However, historically, we have prioritized brevity over accuracy [1]. [1] https://github.com/odoo/enterprise/pull/68549
SEPA credit transfer XML files now include the required country code in postal address details. This helps ensure batch vendor payment files meet banking format expectations and avoids validation issues caused by missing address information.
Original PR description
### Steps to reproduce: - Install 'account_iso20022' - Accounting > Vendors > Payments - Create a new payment with "SEPA Credit Transfer" as the payment method, confirm - Duplicate it and confirm - Back to the payment list view, select the two and click "Create Batch Payment" - Validate and check the generated XML - `Ctry` is missing in the `PstlAdr` ### Cause: The ´_get_PstlAdr´ method in `account_journal_sepa_ct.py` is returning the whole `PstlAdr` element but the country code is missing. Previously the country code was always added (https://github.com/odoo/enterprise/blob/saas-17.4/account_sepa/models/account_journal.py#L322-L329), this is no longer the case in this situation. ### Solution: Add the country to the list of fields to add. opw-4287100
### Steps to Reproduce * Navigate to the Employees app and set a PIN code for Mark Demo * In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin * Open the Shop Floor…
### Steps to Reproduce * Navigate to the Employees app and set a PIN code for Mark Demo * In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin * Open the Shop Floor interface, adding Michael Admin and Mark Demo as active employees * Click on the My WO filter and select Michael * Switch to Mark Demo and enter his PIN code ### Current Behavior * The work orders assigned to Michael are displayed for Mark, even with the My WO filter enabled. ### Expected Behavior Only the work orders assigned to Mark should be displayed ### Reason This issue occurs when a PIN is activated for an employee. When the PIN validation pop-up is displayed, the cache cleanup is performed for the previously logged-in user rather than the newly connected user. Consequently, the old user's workorders remain visible because the cache is not refreshed correctly. ### Fix Ensure that the cache is cleared only after the PIN is successfully validated and the user is connected. Additionally, verify that the My WO filter corresponds to the newly connected user before updating the cache. This will ensure that only the relevant work orders are displayed. opw-4256568
This update fixes an issue where the kitchen display incorrectly prioritized display lines when reducing product quantities in POS orders. Now, the system correctly sorts display lines based on their stage (e.g., 'To Cook', 'Ready'), ensuring the most relevant line is updated first. This improves the efficiency of order preparation.
Original PR description
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line…
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage). Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines. Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. opw-4354093