Monday, August 26, 2024
15 changes · 17.0
Resolved issues and error corrections
Spanish TicketBAI electronic invoices now use the delivery date as the operation date when it is available. This ensures the XML sent to the government reflects the actual delivery timing, falling back to the invoice date only when no delivery date is set.
Original PR description
Use the delivery date to fill the `FechaOperacion` and fall back to the invoice date if no delivery date is set. Steps: - Make an invoice with delivery_date != invoice_date != today - Send invoice to gouvernment - Download the xml generated - The field `FechaOperacion` is the invoice date instead of the delivery date opw-4072748
Printed documents now keep the phone marker together with the phone number in contact address blocks. This avoids awkward formatting in purchase orders and other reports when layouts or long phone numbers previously caused a line break after the phone icon.
Original PR description
Currently there might be a line break after the phone marker in the contact widget. It depends on the document layout and the length of the phone number. After this commit the line break does not happen anymore. (In commit cbcda0b222b17312b9e42e23801a330f0030033f line breaks inside phone numbers were removed.) To reproduce: 1. Ensure Purchase app is installed 2. Settings -> Configure Document Layout - layout: boxed - font: Oswald - paper format: A4 3. Edit some partner to have a long phone number (E.g. via Purchase -> Orders (menu) -> Vendors) e.g. use: (870)-931-0505 12 12 12 12 4. Create a request for quotation / purchase order and select the partner from 3 as Vendor 5. Confirm the purchase order 6. Print the purchase order 7. There is a line break after the phone marker in the vendor address opw-3783870 opw-3970768 PR the mentioned commit belongs to: https://github.com/odoo/odoo/pull/166336
This fix adjusts how a Project task list column is hidden so the list view behaves as intended. It helps avoid confusing or inconsistent task list displays for users working in the Project app.
Original PR description
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
Issue ---- POS payment methods that are already translated don't have their translation show up. Steps ----- Go to Point of Sale -> New/Continue Session -> Add something to pay for -> Click on "payment". The listed payment methods are not translated if you chose another language. Cause ----- Although the terms were translated, they were not showing up because the model referral comment wasn't there. opw-3880510
Original PR description
Issue ---- POS payment methods that are already translated don't have their translation show up. Steps ----- Go to Point of Sale -> New/Continue Session -> Add something to pay for -> Click on "payment". The listed payment methods are not translated if you chose another language. Cause ----- Although the terms were translated, they were not showing up because the model referral comment wasn't there. opw-3880510
A spacing issue in the Mexican EDI payment report has been corrected where a space was missing between the VAT label and account information. The fix adds consistent styling to ensure proper spacing between these elements, improving the readability and professional appearance of payment reports.
Original PR description
In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#53722
This fix addresses a performance test failure in the Appointment module where database queries were exceeding expected limits. The issue occurred when the Appointment module was tested in isolation, and the fix ensures consistent test conditions by warming up the cache to prevent unexpected query increases from being missed in future updates.
Original PR description
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment is installed alone, hopefully avoiding to miss the increased query count next time.
Code cleanup and technical improvements
This update reorganizes how stock valuation records are prepared before they are created. It makes the stock accounting code easier for custom modules to adapt, with no expected change to day-to-day user workflows.
Original PR description
Refactor the `_create_out_svl` and `_create_dropshipped_svl` methods in the `stok.move` model to separate the vals list generation from the `create` call. These new methods facilitate overwrites in custom modules. This split is already present for the `_create_in_svl` method.
Miscellaneous changes
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: In Indian government for example, requires audit trail report for private limited companies, so user can't delete journal entries after posting once. Backporting method `_unlink_or_reverse` from 17.0 [1] to be used in the related PR https://github.com/odoo
Original PR description
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: In Indian government for example, requires audit trail report for private limited companies, so user can't delete journal entries after posting once. Backporting method `_unlink_or_reverse` from 17.0 [1] to be used in the related PR https://github.com/odoo/enterprise/pull/68044 [1] https://github.com/odoo/odoo/blob/66bfab54748a56072ed9ff144f4a39366b606a06/addons/account/models/account_move.py#L3772-L3785 opw-4075244 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 Forward-Port-Of: odoo/odoo#176792
* PROPBLEM: The error is raised when user has access to Project Update, but not to Journal Item. * SOLUTION: Add `sudo` when searching `account.move.line` in the method `_get_already_included_profitability_invoice_line_ids`. 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 Forward-Port-Of: odoo/odoo#177150
Original PR description
* PROPBLEM: The error is raised when user has access to Project Update, but not to Journal Item. * SOLUTION: Add `sudo` when searching `account.move.line` in the method `_get_already_included_profitability_invoice_line_ids`. 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 Forward-Port-Of: odoo/odoo#177150
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t
Original PR description
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. opw-3993305 Forward-Port-Of: odoo/odoo#174950
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the docum
Original PR description
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility…
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly. **But when a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then is needed to change "Document Type" field if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility.** --> we introduced this bug on this pr [https://github.com/odoo/odoo/pull/172003](https://github.com/odoo/odoo/pull/172003) **Video showing how to replicate the bug:** https://drive.google.com/file/d/1endivnZ3EEBVn4kzt0hIkR-a5tecYUR7/view **Steps to reproduce:** 1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module. 2. Take position on company "Responsable Inscripto". 3. Go to "Accounting / Vendor / Bills" and create a new vendor bill with vendor "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a journal "Vendor Bills", add an invoice line and confirm it. 4. Reset to draft the vendor bill mentioned in step 3 (now journal and document type are readonly fields), change customer to "Gritti Agrimensura" (this partner has "Responsable Monotributo" AFIP Responsibility) and save. Check that the document type has not changed from "(1) FACTURAS A" to "(11) FACTURAS C" and this is not the desired behavior because is a readonly field now because the invoice was posted before. **Current behavior before PR:** When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does not changes if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility. **Desired behavior after PR is merged:** When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does changes if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility. Ticket Adhoc side: 77058 Task latam: 1242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175855
This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account. - [FIX] website: always set the first carousel slide as the active one - [FIX] website: make the `Carousel` options atomic - [FIX] website: prevent recording sliding of some carousels in history - [FIX] website: add a tour to test the `Carousel` options task-3744613 related to opw-3675019 Forward-Po
Original PR description
This PR fixes issues linked to the fact that the sliding of carousels is an asynchronous operation. Indeed, the options and the history of the carousels were not taking this into account. - [FIX] website: always set the first carousel slide as the active one - [FIX] website: make the `Carousel` options atomic - [FIX] website: prevent recording sliding of some carousels in history - [FIX] website: add a tour to test the `Carousel` options task-3744613 related to opw-3675019 Forward-Port-Of: odoo/odoo#171642 Forward-Port-Of: odoo/odoo#153892
This PR is created in order to sing the odoo CLA and contribute to Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176903
Original PR description
This PR is created in order to sing the odoo CLA and contribute to Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176903
Added modules to load in `odoo.conf` for IoT Box v24.08 compatibility. v24.08 PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) Task: 3947355 Forward-Port-Of: odoo/odoo#176452
Original PR description
Added modules to load in `odoo.conf` for IoT Box v24.08 compatibility. v24.08 PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) Task: 3947355 Forward-Port-Of: odoo/odoo#176452
This commit change the visibility of the payment cancellation button on payment form view, so now users can request for EDI cancellation directly on the payment view. opw-3941384 Forward-Port-Of: odoo/enterprise#66983
Original PR description
This commit change the visibility of the payment cancellation button on payment form view, so now users can request for EDI cancellation directly on the payment view. opw-3941384 Forward-Port-Of: odoo/enterprise#66983