Daily updates from Odoo
Wednesday, June 12, 2024
19 changes
4 changes
Resolved issues and error corrections
Duplicating website pages now gives each copy a unique internal identifier, preventing errors when users open or edit the original or duplicated pages. This improves reliability for website managers who create pages by copying existing ones.
Original PR description
When a user duplicates a view of a website page and then attempts to open either the original or duplicated view and click on ``edit``, a traceback will appear. Steps to reproduce: - Install the…
When a user duplicates a view of a website page and then attempts to open either the original or duplicated view and click on ``edit``, a traceback will appear. Steps to reproduce: - Install the ``website`` module - Website > Site > Pages - Create one new page > Actions > Duplicate - Repeat 2-3 times - Click on the newly created page or a duplicated one > ``Edit`` Traceback : - ``Expected singleton: ir.ui.view(2224, 2225)`` When duplicating a website page view, we encounter an issue where the ``key`` value remains unchanged, leading to an error. This occurs because, after calling the super in the ``copy_data`` method, the ``key`` is already set on the fields that are being copied to the new record, and ``website.page`` delegates some of its fields to the ``ir.ui.view`` that it holds. This commit will fix the above error by calling the ``copy`` method instead of ``copy_data``. sentry - 4991676595 opw-3936237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders now keep component quantities that users manually enter instead of recalculating them from the bill of materials when using Produce All. This prevents unexpected changes to recorded material consumption and helps keep production records accurate.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM consuming 1 unit of a product COMP - Create and confirm a MO for 1 unit of FP using the BOM - Set the consumed quantity of COMP to 2 and tick…
### Steps to reproduce: - Create a product FP with a BOM consuming 1 unit of a product COMP - Create and confirm a MO for 1 unit of FP using the BOM - Set the consumed quantity of COMP to 2 and tick consumed - Save and "Produce All" #### > the consumed quantity of COMP was updated to 1 according to the BOM ### Cause of the issue: Clicking on "Produce All" will trigger the `pre_button_mark_done` that will update the qty_producing according to the bom proportions because of these lines: https://github.com/odoo/odoo/blob/86f977f8f4b9859790ad77af3a40234c8eb374e9/addons/mrp/models/mrp_production.py#L1217-L1227 However, this update should be bypassed if the quantity was set on the move. This is the role of these lines: https://github.com/odoo/odoo/blob/86f977f8f4b9859790ad77af3a40234c8eb374e9/addons/mrp/models/mrp_production.py#L1218-L1220 The issue does not appear in 17.0 because, thanks to commit https://github.com/odoo/odoo/commit/5bb0f96f1973fa7e19b6701944b4a29577f3314f the `manual_consumption` field of the stock moves related to a manufacturing order is set to be True as soon as the quantity is changed because of these lines: https://github.com/odoo/odoo/blob/9a11717c17b860ec2f1b2e228517c0d3945c474a/addons/mrp/static/src/widgets/mrp_consumed.js#L25-L27 However, this js file was removed in saas-17.2 by commit https://github.com/odoo/odoo/commit/e143345193577442ffd1f46272a09d7a5801d567. opw-3934942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Signatures now keep their intended size on high-resolution displays, including 4K screens with scaling enabled. Automatically generated signatures are also better centered, making signed documents look more consistent and professional.
Original PR description
Before this commit, when a 4K screen was used with devicePixelRatio > 1, the signature svg size was divided by the devicePixelRatio value. We would have small automatic signature shrinked. taskid: 3971056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where website live chat replies could fail for visitors whose browser language was not installed in the database. Notifications are now sent without depending on the visitor's session language, so operators' responses reach guests reliably.
Original PR description
Use case: On a database that has only the "English (US)" (`en_US`) language installed, 1. A visitor having set his browser prefered language to `fr_FR` browse the website, open the livechat and ask a question. 2. A livechat operator pick-up and respond 3. The visitor never see the reponse On the server we see an error: ```odoo.addons.bus.websocket: Invalid language code: fr_FR``` That crash prevent sending the operator response back to the guest (website visitor). As we don't need the language at all to dispatch bus notification, set it to `None`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
The shop floor screen now shows the 'no content' message only in the relevant disabled work order area instead of covering the whole display. This keeps the employee panel visible and avoids clutter on smaller screens.
Original PR description
Before this commit, the 'no content' message was showing in the entire display, taking the employee panel account. Now, it is fixed, the message just stay at the disabled workorders, and when the screen is less than md, the message is hidded. rebased branch: https://github.com/odoo/enterprise/pull/64435 task: 3794286
GST return period totals now avoid counting invoiced point-of-sale orders twice. This helps businesses report more accurate GST amounts when POS orders are converted into invoices.
Original PR description
After odoo/enterprise#55370 all POS journal entries were included in the return period, regardless of whether an invoice was created. Therefore, if a user created an invoice for an order, its amount was added twice for the same GST return period, once from the POS journal entry and once from the invoice. After this PR, invoices from POS orders will not be included in the GST return period. Task [link](https://www.odoo.com/web#model=project.task&id=3908555) task-3908555
This update corrects several small issues across appointments, payroll, and knowledge management. It also aligns appointment page customization with the updated editor, helping users avoid editing problems and improving reliability in related workflows.
12 changes
Resolved issues and error corrections
This fix resolves an issue where the "Disabled children" toggle was not appearing in the salary configurator for Belgian employees, even when disabled children were configured in their profile. The problem occurred because a method was being called without proper event handling, causing the disabled children field to be incorrectly hidden. The fix ensures the toggle displays correctly so HR teams can properly configure salary options for employees with disabled dependents.
Original PR description
## Issue: When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary…
## Issue: When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary configurator does not appear. ## Steps To Reproduce: - on the runbot change the company to "my Belgian company". - In Laurie Poiret's employee profile, on the "personal information" tab, change the value for children to 2 and set 1 as disabled. - Go to Laurie Poiret's contract (stat button) and generate an offer. - From the offer, navigate to the salary configurator. - In the salary configurator, proceed until you reach the family status section. - Notice that the "Disabled children" Toggle does not appear unless you change the value of the children input. ## Solution: - The `onchangeChildren` method is being invoked in the `start` method without an `event` argument (`event` is `undefined`). This results in `event.currentTarget` being `undefined`, causing the `childCount` variable to be `NaN` and `disabledChildrenNumber` to get disabled at the end of the method. - to fix the problem, we added a check for `event` argument in the event handler, if it is not present, we fallback to getting the children input value using JQuery and it solves the issue. **opw-3925640** Forward-Port-Of: odoo/enterprise#64347 Forward-Port-Of: odoo/enterprise#63535
A recent update to the subscription module inadvertently prevented non-sales users (such as stock managers) from accessing the product creation form. This fix restores access by properly configuring user permissions for the new subscription pricing field, allowing all relevant team members to work with products without restrictions.
Original PR description
A new field of type 'sale.subscription.pricing' was added to the 'product.template' model. This breaks product creation form for users who don't have sales permissions (e.g. stock managers). This commit fixes the issue by adding `groups` to the field.
This fix addresses two validation issues in the Documents module when users clear required fields in the document inspector. When a required field like Name or Workspace is cleared, the system now properly displays an alert dialog and reverts the changes when the user confirms, instead of either showing no alert or incorrectly saving empty values. This ensures data integrity by preventing documents from being saved with missing required information.
Original PR description
**Steps to reproduce:** - Go to list view or kanban view. - Select the document to preview in the inspector. - Clear the input value of a required field (here, Name or Workspace), and click elsewhere…
**Steps to reproduce:**
- Go to list view or kanban view.
- Select the document to preview in the inspector.
- Clear the input value of a required field (here, Name or Workspace), and click elsewhere or press 'Enter'.
**Issues:**
- _**Workspace field**_
A validation error is raised when a Workspace name is cleared. However, an alert dialog is not displayed.
- _**Name field**_
An alert dialog indicating a validation error is shown yet on clicking the `OK` button, the unnamed document is saved as is.
Instead, the changes should be reverted.
**Causes:**
- _**Workspace field**_
The `required` attribute was not added to `folder_id` field in the view. As a result, alert dialog was not shown.
- _**Name field**_
The config mode never changes to 'edit'. Even when a user is editing an inspector field, the mode is 'readonly'.
As a result, the boolean `isInEdition` remains false and the code-block meant to be executed
on click of the confirm button of alert dialog does not execute as intended.
**Fix:**
- _**Workspace field**_
The `required` attribute is forcefully set to true for the `folder_id` field so that an empty value for workspace
is not considered to be a 'validSelection' and the user faces an alert popup.
- _**Name field**_
This PR fixes the issue by switching to edit mode whenever user changes the value of a document inspector field.
This PR also adds a testcase in `documents_kanban_tests.js` to ensure that the confirm ('OK') button works as intended.
Task: [3799280](https://www.odoo.com/web#id=3799280&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form)This fix prevents chatbot configuration errors by validating that an Email step exists before a Create Ticket step. Previously, misconfigured chatbots would break during operation. Now, the system catches these configuration issues upfront with a clear validation error message, ensuring a smoother user experience.
Original PR description
**Before this PR:** When you have a `Create ticket` step in your ChatBot script steps, but you don't have an `Email` step prior to that. Then it will break the flow of ChatBot, as an email is required to create a helpdesk ticket. **After this PR:** It will raise a `ValidationError` if it fails to validate the steps while configuring the chatbot script steps. **task**-[3547675](https://www.odoo.com/web#id=3547675&menu_id=6478&cids=2&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#64394 Forward-Port-Of: odoo/enterprise#56802
This fix resolves an error that occurred when users attempted to reconcile accounting lines with different currencies using the write-off wizard. The system was incorrectly trying to process multiple currency records at once, causing the reconciliation process to fail. Users can now successfully reconcile multi-currency transactions without encountering this error.
Original PR description
When trying to reconcile to debit or credit lines with different currencies, we get a singleton error on `wizard.reco_currency_id` in `_compute_is_write_off_required` opw-3833477 Forward-Port-Of: odoo/enterprise#64011
Fixed an issue where project administrators couldn't rename projects when the Documents module was installed. The system now properly handles folder name updates in the Documents module without requiring additional permissions, allowing project admins to manage their projects seamlessly.
Original PR description
To reproduce: ============= - install Project and Documents - create a project - give the user the project admin rights and **User** rights for the Documents module - try to rename a project -> access error Problem: ======== when Document is installed, every project has a related folder in the Documents. When renaming a project, the folder name should be updated as well. As the user has no rights to write on Documents, the renaming fails. Solution: ========= set the folder name as `sudo` to avoid access errors opw-3928018 Forward-Port-Of: odoo/enterprise#63787
This fix ensures that when users select an email template with CC recipients for follow-up emails in the Accounting module, those CC addresses are properly added to the email recipients list. Previously, CC addresses from templates were only included when loading the template in the full view, not when selecting it in the quick template field. This update makes the behavior consistent across both methods.
Original PR description
### Steps to reproduce the issue: 1. Go to _Settings > Technical > Email > Email Templates_ 2. Select a template that applies to a Contact 3. Add a mail address in the Cc field 4. Go to _Accounting >…
### Steps to reproduce the issue: 1. Go to _Settings > Technical > Email > Email Templates_ 2. Select a template that applies to a Contact 3. Add a mail address in the Cc field 4. Go to _Accounting > Customers > Follow-up Reports_ select one of the reports 5. Click on "Follow up" 6. Select the template with the Cc in the Content Template field 7. The Cc address is not added to the Email Recipients field 8. Click on Send Message in the chatter 9. Open the full view and add the template with the Cc in the Load template field 10. The Cc address is added to the Recipients field ### Explanation: The field `email_recipient_ids` is not a computed field. Because of it, there is no change called when `template_id` is assigned a new value. ### Suggested fix: We need to change `email_recipients_ids` according to `template_id` while keeping its current properties (stored, writable). The method is adapted from `mail.compose.message._compute_partner_ids`. https://github.com/odoo/odoo/blob/1849b709f1acf0f5546582bf7551129a870e3113/addons/mail/wizard/mail_compose_message.py#L482-L496 opw-3878125 Forward-Port-Of: odoo/enterprise#63918 Forward-Port-Of: odoo/enterprise#61861
Fixed an issue in the Documents module where the delete button (X) for tags was hidden when tag names were very long. The fix adjusts how the tag table is displayed so that long tag names don't cause the table to expand and hide the delete button, improving usability when working with documents that have lengthy tags.
Original PR description
By default, tables automatically adjust their width to accommodate the content of their cells, That causes table row to grow in size and make "X" button invisible. Here I'm constraining table layout so it doesn't matter how long the content of columns is [Reproduce] - Install documents - Add tag with a very long name - Go to all Documents, Select a document, Add the tag on a doc - BUG: "X" button is not visible* opw-3937326 BEFORE / AFTER https://github.com/odoo/enterprise/assets/33809926/5f2fc861-cd68-4478-8b8b-b8843b7d4944 Forward-Port-Of: odoo/enterprise#63279
This fix resolves a validation error that occurred when generating delivery guides for products that may be hazardous under Mexican regulations. The system now properly handles products with uncertain hazard classifications by allowing users to explicitly indicate whether such products should be treated as hazardous or non-hazardous, preventing delivery guide generation failures.
Original PR description
With an MX company setup Create a product with: - UNSPSC Category: 12352106 Ácidos orgánicos o sus sustitutos - Hazardous Material Designation Code (MX): - Hazardous Packaging (MX): - Tariff…
With an MX company setup Create a product with: - UNSPSC Category: 12352106 Ácidos orgánicos o sus sustitutos - Hazardous Material Designation Code (MX): - Hazardous Packaging (MX): - Tariff Fraction: 2917190800 Ácido fumárico. - UMT Aduana: kg - Weight: 1.00 Create a Sale Order with the product Confirm Go to Delivery Set: - Tansport Type: Federal Highways - In MX Tab add 'Vehicle Setup' and 'Gross Vehicle Weight' Validate and Generate Delivery Guide Error: Code : CP155 Message : El valor registrado en el atributo "Mercancia:MaterialPeligroso" no es válido o el valor registrado en el atributo “Mercancias:Mercancia:BienesTransp” contiene el valor "0" (cero) en la columna "Material peligroso" del catálogo catCartaPorte:c_ClaveProdServCP. This occurs because the MarierialPeligroso element is not filled In the ClaveProdServ tab of the CatalogoCartaPorte30 it is specified if a product or service is (1), not is (0) or may be (0,1) considered hazardous When having to deal with "may be" hazardous products it is required to set the 'MaterialPeligroso' element. Currently, the system does not allow to specify if the "may be" product is actually hazardous, but if the 'Hazardous Material Designation Code (MX)' field is not set the MaterialPeligroso element will not be filled, failing the validation The proposed workaround is to use the value '0' as flag to indicate that the maybe hazardous product should not be considered hazardous and 'MaterialPeligroso' will be set to 'No' opw-3955361 task-3668225 Forward-Port-Of: odoo/enterprise#64153 Forward-Port-Of: odoo/enterprise#63832
This update fixes an issue where appointment type intro messages couldn't be edited through the website editor if they hadn't been set yet. The fix adjusts how the intro message element is positioned and selected in the editor, making it properly editable for users who want to customize their appointment booking pages.
Original PR description
Purpose ======= Fix the appointment type intro message which, if not set yet, wasn't available for edition using the website editor. Specification ============= The "o_appointment_intro" element has been changed from inside, to next to the "o_appointment" element. Changing the selector to match the new "o_appointment_intro" position. Ref commit: https://github.com/odoo/enterprise/commit/4f68079b535c1ea54c42ae8dabae903f88d6e87f Also combining the 2 separate conditions that adds the d-none class into 1 single OR-ed condition for readability. Task-3976356
This fix resolves an issue where quotations created from CRM opportunities were not automatically using the partner's configured usage value. Previously, quotations would always default to "General Usage" instead of inheriting the partner's setting. Now the system correctly applies the partner's usage preference when creating new quotations.
Original PR description
Problem: When the user creates a new quotation from a CRM opportunity, the quotation does not compute to the partner's usage value and always default to "General Usage". The default prevents the compute from getting called. Purpose: The compute method "_compute_l10n_mx_edi_usage" should be called when a new quotation is created from the crm opportunity. Steps to Reproduce on Runbot17: 1. Install Sales, l10n_mx, l10n_mx_edi, CRM, Contacts 2. Set a value for field "Usage" (l10n_mx_edi_usage) on a partner whose country is Mexico in Contacts 3. Create a CRM opportunity with the partner above 4. Create a new quotation from the opportunity and observe that the "Usage" value is not the same as defined on the partner opw-3934009
This update fixes a crash that occurred when users tried to access call activities that had been removed from the Call Queue. The system now properly refreshes the display when call activities are added or removed, ensuring users always see current information and can safely interact with their call queue without encountering errors.
Original PR description
When call activity gets deleted or added, the related component has to be re-rendered so that most uptodate information is shown, otherwise this might lead to crash if those activities are accessed. To mitigate the issue, component re-rendering is invoked when call activity gets added or removed from the queue. The activity removal happens when `delete_call_activity` function is invoked directly, which crafts domain, to search the activies that are outdated. Steps to reproduce: - on crm lead schedule call activity and make sure that activity is old - book activity and save it - add it to Call Queue - remove it from Call Queue - try to access it/click on it Forward-Port-Of: odoo/enterprise#64325