Tuesday, November 12, 2024
16 changes · 17.0
Resolved issues and error corrections
The Discuss welcome page now shows the actual guest name instead of always displaying "Guest." This creates a more personalized and accurate experience for visitors joining conversations.
Original PR description
Before this commit, the welcome page was using "Guest" as the default name, regardless of what the name was.
Gift card and eWallet reward forms now show the description field, so teams can update the text after creation. This prevents descriptions from being locked in the creator's original language and makes customer-facing reward details easier to maintain.
Original PR description
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262
The domain selector dialog now respects when the "Show archived" checkbox should be hidden. This prevents users from seeing an irrelevant option in contexts where archived records should not be exposed, making the interface clearer.
Original PR description
The "Show archived" checkbox should not be displayed in some context opw-4104396
This fix improves how Odoo reports errors that happen very early while the web client is starting. Instead of showing duplicate browser errors, it logs the issue once with clearer context when normal user-friendly handling is not ready yet.
Original PR description
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior. After this commit, we prevnt the browser to apply its behavior. 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
New e-commerce categories now show their actual name in the website breadcrumb after saving, instead of appearing as "Unnamed." This makes store navigation clearer for administrators and avoids confusing category labels on the storefront.
Original PR description
Problem: When creating a new e-commerce category, the breadcrumb displays "Unnamed" instead of the actual category name. This happens because the `parents_and_self` field is not recomputed when `parent_path` changes, despite the former depending on the latter. Solution: Ensure that `parents_and_self` is recomputed whenever `parent_path` is updated, so that the correct name is reflected in the breadcrumb. Steps to reproduce: - Open the form to create a new e-commerce category. - After saving, the breadcrumb displays "Unnamed" instead of the actual category name. opw-4267144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where HR gamification badge buttons always showed zero recipients even after badges were granted. The button now reflects the correct recipient count and opens the appropriate list, making badge tracking reliable for HR users.
Original PR description
The issue occurs when granting a badge to a user. The smart button always shows zero (0) badges granted, regardless of how many users have received the badge. This happens because the smart button…
The issue occurs when granting a badge to a user. The smart button always shows zero (0) badges granted, regardless of how many users have received the badge. This happens because the smart button displays the count of employees granted the badge, but `employee_id` is always `False` as a result counting how many `employee_id` granted this badge is always 0. `employee_id` it wasn't calculated. instead `user_id` was calculated from `employee_id`, but I think it was done by mistake. I added the `_compute_granted_user_count()` function to count how many `users` have been granted the badge. This ensures the smart button now displays the correct number of users and employees who received the badge. But I left the _compute_granted_user_count() function even while we don't needed it any more, just in case of someone who didn't update. When clicking the smart button, now it lists all users that grant this budge, rather than listing only employees who grant it. And the `employee_id` is now computed, ensuring it is no longer `False` when the user is an employee. **Steps to reproduce the issue:** 1: Install Employees 2: Install HR Gamification (not an app) 3: open Employees --> Configurations --> Challenges --> Budges 4: click on of those budges 5: grant a budge to an employee 6: check the smart button it still shows that 0 employees were granted this budge 7: click on it and it wont list the employees who granted the budge opw-4165187
This pull request reverts a recent change that displayed general ledger reports using invoice dates instead of the actual accounting date. This ensures reports accurately reflect the date the transaction occurred, improving financial reporting accuracy. The change corrects a previous update that caused discrepancies in reporting.
Original PR description
…or the general ledger In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date. We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger. task-4270453
This update replaces the outdated icon for the UPS delivery module within Odoo Enterprise. The change ensures a consistent and professional visual representation of the UPS integration, improving the user experience. This is a minor cosmetic update.
Original PR description
The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822
This update clarifies the user interface for rounding methods in the Point of Sale settings. Previously, 'HALF-UP' was confusing, so the term has been changed to 'Nearest' to better align with user expectations and provide a more intuitive experience. This ensures accurate and easily understood calculations within the POS system.
Original PR description
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. This commit adapts an error message to the new term. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/odoo/pull/186237 Forward-Port-Of: odoo/enterprise#73285
This update resolves an issue where helpdesk tickets created from child contacts couldn't access products associated with their parent contacts. Previously, this limitation existed across several Odoo versions. This fix ensures that child contacts can now correctly see and utilize products linked to their parent contacts within the helpdesk system.
Original PR description
Steps to reproduce: - Install helpdesk_stock and Studio - Create 2 contacts, with one parent of the other - Create a quotation for parent contact with any product - Create a quotation for child contact with another product - Helpdesk app > Create a ticket - Add the 'product_id' field with studio - (Under 'Existing Fields' search product) - (View tab > Show invisible elements > Find product field > untick invisible) - Parent contact as Customer => Can only see their product (Expected) - Child contact as Customer => Can only see their product (Wrong) Between 15.0 and saas-17.4, the child contact cannot access its parent's sale order products. This is due to an improvement made in saas-17.4 https://github.com/odoo/enterprise/pull/48624 which lets child contacts use parent SOs in repair/return flows etc... opw-4285382 Forward-Port-Of: odoo/enterprise#73391
This update resolves an issue where selecting a document record in the documents module would lose its selection when column widths were adjusted. The fix prevents the system from removing selections triggered by resizing columns, ensuring users can consistently select and manage documents. This improves the overall usability of the documents module.
Original PR description
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375
Miscellaneous changes
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and m
Original PR description
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like…
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and memory-expensive because the `purchase_id` field is not stored so it needs to compute the relationship for all moves in the expanded ids due to prefetching. Since there exists a Many2many relationship between stock pickings and purchase orders, it's possible to rely on a search query instead of the `mapped` call. Although this might miss some cache optimizations, it's still much more efficient in terms of memory. This is because this approach is not susceptible to prefetch_ids explosion. It's also worth noting that this function is only called on individual stock moves instead of batches as part of the anglo_saxon_accounting logic. That being said, we don't have to worry this much about cache optimization since the method is not batched to begin with. Using this optimization, we get the following benchmarks. Benchmark: | num stock.move (_prefetch_ids) | time before | no. queries before | time after | no. queries after| |----|------|-----| ----- | ----- | | 1000 | timeout | N/A | ~ 85 seconds | 47897 | opw-4096108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181822
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186237
Original PR description
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186237
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186138
Original PR description
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186138
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set
Original PR description
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the…
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set * If needed, deliver the items * Create an invoice (regular invoice) * Confirm the invoice * Go back to the sale order > Observation: The downpayment line has a price unit of 0.0 Why the fix: ------------ The difference between the two flows (pos/sale) mainly resides in those few lines: https://github.com/odoo/odoo/blob/b3b1fe6a78f9e5b6f1d993b5aa2fed11e33c793e/addons/sale/models/account_move.py#L75-L85 `dpl.invoice_lines` will include 2 items when using the sale flow whereas only one when making the downpayment in pos. Downpayments from pos are not automatically invoiced and even if they are, the model `pos.order.line` does not have the field `invoice_lines`. However each downpayment **sale order line** that comes from the POS is linked to its downpayment **pos order line** with the field `pos_order_line_ids`. The only element left in `dpl.invoice_lines` will not be counted as it is included in `real_invoice` (the current invoice). The idea of the fix is to include the price unit of the downpayment made in pos in this sum. opw-4160111 Forward-Port-Of: odoo/odoo#185788
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of
Original PR description
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails…
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and formatted emails in various email input. This notably leads to better formatted email computation on partner that generates emails like '"email@example.com" <email@example.com>' when email is used both as name and email. When sending emails to this partner only a single email should be sent and counted. A fix is been done to remove duplicates in that tool, making the returned list unique. In this PR we allow to receive a pre-validated list of emails that restricts emails found by 'extract_rfc2822'. When going through classic flows, we already computed emails using 'email_split' and its subtools, hence we just need the encoding check of 'extract_rfc2822'. Additional emails found by that tool are ignored as we consider those are fake emails. This PR contains tests and fixes related to that issue as well as multi and formatted emails management. Task-3704658 Forward-Port-Of: odoo/odoo#185793