Wednesday, September 18, 2024
16 changes · 17.0
Resolved issues and error corrections
This update fixes several small issues in Odoo's mail and event registration flows. It ensures email recipient settings are respected, strengthens test checks, and prevents access errors for registration desk users when visitor information is involved.
Proforma invoices now use the proper report template, so their attachments are named as proforma documents instead of quotations. This avoids confusion for customers and sales teams when sending or storing invoice files.
Original PR description
Problem: The same `report_template_id` was being used for both standard and proforma invoices, leading to inconsistencies in the attachment naming. Steps to reproduce: - Enable Proforma invoices. - Create a new quotation. - Send a Proforma invoice. - The attachment name starts with "Quotation" instead of "PRO-FORMA." opw-4184863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chilean invoices no longer show a repeated tax totals table when issued in a foreign currency. Duplicate payment term details were also removed, leaving the more complete payment note at the bottom of the document for clearer invoices.
Original PR description
Versions: 17.0, saas-17.1, saas-17.2 Issue: The tax totals company currency table displays repetitive information. Purpose of this PR: To remove the repetitive tax totals table. Steps to Reproduce: - Install l10n_cl_edi - Set up a currency rate for any active foreign currency (different from CLP) (Using USD for the example) - Create an invoice using a foreign currency (USD in the example) opw-4127839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the project form's expandable HTML area so it uses the available space properly when a project form first opens. Users should see the intended layout again after recent design changes caused the field to stop expanding correctly.
Original PR description
Before this commit, since the design changes, the form with html expander no longer works. This commit adapts the code to expand the html field as before to take the remaining height unused by the form view when we first load the form view of `project`. task-3258533
This fixes the default Lao date format so years display as four digits instead of an incorrect short value. It helps Lao-language users see dates consistently and accurately across Odoo.
Original PR description
Description of the issue/feature this PR addresses: The date format in Lao contain a typo: `%d/%m/y` should be `%d/%m/%Y` Desired behavior after PR is merged: The date format should be `%d/%m/%Y` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project administrators can once again reorder projects from the configuration list view. This restores expected behavior and makes it easier to control how projects appear without workarounds.
Original PR description
* STEP TO REPRODUCE: go to configuration -> project -> switch to list view -> can't change sequence of project * REASON: in project.view_project_config we use invisible instead of column_invisible and the default_order in tree are "is_favorite desc, sequence, name, id" not like in v16 are "sequence, name, id" * SOLUTION: Change invisible -> column_invisible and change default_order of project config view to "sequence, name, id" Close https://github.com/odoo/odoo/issues/176961
This fixes follow-up reminders so the SnailMail cost is calculated before sending. Businesses will now see the correct number of stamps needed when a customer has multiple follow-up contacts, helping avoid undercounted mailing costs.
Original PR description
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083
This update removes two empty and outdated fields ("Operation Type" and "Subdivision") from the external trade section of Mexican invoices. These fields were removed from the official Mexican external trade regulations and were appearing as blank cells on printed invoices, causing confusion. The change aligns Odoo's invoice format with current Mexican tax compliance requirements.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Configure external trade according to: https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade - Make sure that USD has up-to-date rates - Create an external trade invoice: * Customer: [a US customer] (e.g. Deco Addict) * Currency: USD * Usage: Without fiscal effects * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Print the invoice **Issue:** In the external trade section of the invoice, there are 2 empty cells: "Operation Type" and "Subdivision". According to https://facture.com.mx/nuevo-complemento-comercio-exterior-2-0/ they both have been removed. opw-4078535 Forward-Port-Of: odoo/enterprise#70178
A broken link in the GST Return (GSTR) report that previously displayed a 404 error has been fixed. Users can now click on the "Checkout our tutorial" link and be directed to the proper Odoo documentation for GST filing, improving the user experience and providing easy access to helpful resources.
Original PR description
Before this commit: whenever user clicked on `Checkout our tutorial` broken url on GSTR report a new page with 404 Not Found opened After this commit: We fix the `Checkout our tutorial` broken url, now when user clicks on the page it redirects user to Odoo documentation of GSTR filing
Miscellaneous changes
* PROPBLEM: When duplicating a picking, the creation date is not updated to latest date (fields.datetime.now) instead it was taken from the copy value. This will be a problem if user try to search for it, they do not know 'creation_date' actually is because it is not present on picking view * SOLUTION: this commit add copy=False to update 'creation_date' when duplicating picking Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is
Original PR description
* PROPBLEM: When duplicating a picking, the creation date is not updated to latest date (fields.datetime.now) instead it was taken from the copy value. This will be a problem if user try to search for it, they do not know 'creation_date' actually is because it is not present on picking view * SOLUTION: this commit add copy=False to update 'creation_date' when duplicating picking 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#179718
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase order with the oldest date_order field. The last_purchase_date field should be set using the purchase order with the most recent date_order field. Purpose: By ordering the purchase orders by date_order desc we will get the purchase order with the most recent date_order field. This will cause the supp
Original PR description
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase…
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase order with the oldest date_order field. The last_purchase_date field should be set using the purchase order with the most recent date_order field. Purpose: By ordering the purchase orders by date_order desc we will get the purchase order with the most recent date_order field. This will cause the supplier’s last purchase date to be the most recent one instead of the oldest one. Steps to Reproduce on Runbot: 1. Create a storable product and create a reordering rule for this product 2. Create a purchase order for this product and set the Order Deadline to a date in the past and then confirm it 3. Create a purchase order for this product and set the Order Deadline to the current date and the confirm it 4. Navigate to this product’s replenishment information 5. Observe that the Last Purchase date is the earlier of the two dates from the purchase orders opw-4113810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180500 Forward-Port-Of: odoo/odoo#177306
When returning a purchase/sale order, we can not create accrued entry for the returned order Steps: - Create a purchase order - Receive product - Create and confirm bill - Set received quantity to 0 - From the action menu, select "Accrued Expense Entry" -> There is no line, it should be a line for the vendor credit not This is because we filter the order lines to get only the lines that have a positive quantity to invoice, in that case the quantity to invoice is negative and should be taken i
Original PR description
When returning a purchase/sale order, we can not create accrued entry for the returned order Steps: - Create a purchase order - Receive product - Create and confirm bill - Set received quantity to 0 - From the action menu, select "Accrued Expense Entry" -> There is no line, it should be a line for the vendor credit not This is because we filter the order lines to get only the lines that have a positive quantity to invoice, in that case the quantity to invoice is negative and should be taken into account opw-4176706 Forward-Port-Of: odoo/odoo#180299
Before this commit, when importing multiple leaves for different employee, the last employee in the list will be set as a follower on all the created leaves. This commit fixes this behavior by checking for the employee assigned to each leave and using its ID when adding the follower. opw-4023073 Forward-Port-Of: odoo/odoo#179872 Forward-Port-Of: odoo/odoo#178994
Original PR description
Before this commit, when importing multiple leaves for different employee, the last employee in the list will be set as a follower on all the created leaves. This commit fixes this behavior by checking for the employee assigned to each leave and using its ID when adding the follower. opw-4023073 Forward-Port-Of: odoo/odoo#179872 Forward-Port-Of: odoo/odoo#178994
Description of the issue/feature this PR addresses: Add translation for the default content Note: I tried adding `_()` within the field, but it didn't work, so I moved it to the default function `_get_default_job_details` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178484
Original PR description
Description of the issue/feature this PR addresses: Add translation for the default content Note: I tried adding `_()` within the field, but it didn't work, so I moved it to the default function `_get_default_job_details` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178484
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176929
The problem occurs because when extracting the time zone and time from the date and using the Date constructor to create a new Date, it results in an incorrect date. Steps to reproduce: - Create a product tracked by lot with expiration dates. - Create a quantity for it. - Create a deliver and reserved the qty. - Opening it in barcode app, the wrong expiration date is showed. opw-4070939 Forward-Port-Of: odoo/enterprise#67794
Original PR description
The problem occurs because when extracting the time zone and time from the date and using the Date constructor to create a new Date, it results in an incorrect date. Steps to reproduce: - Create a product tracked by lot with expiration dates. - Create a quantity for it. - Create a deliver and reserved the qty. - Opening it in barcode app, the wrong expiration date is showed. opw-4070939 Forward-Port-Of: odoo/enterprise#67794