Tuesday, September 3, 2024
24 changes · 17.0
Enhancements to existing features
The POS IoT module now has a visual icon that will be displayed in the Odoo interface. This improvement makes the module easier to identify and recognize within the system, enhancing the overall user experience when browsing available modules.
Original PR description
Added `pos_iot` module icon.
Resolved issues and error corrections
The online shop category list no longer shifts slightly when customers hover over it and there are only a few categories. This keeps the storefront layout stable and improves the browsing experience.
Original PR description
**Steps:** - Create a few products and e-commerce categories - Go to the shop page - Hover on the eCommerce categories created - A bit displacement is seen in the margin **Issue:** - The margin is given to adjust the height of the scrollbar on hover but it's applied even when scrollbar is not present (when handful of categories are there) resulting in a displacement. **Fix:** - Disabling the margin on hover when there are less categories that is when scrollbar is not present **Affected version:** 17.0~master opw-4088697
Miscellaneous changes
[FIX] website_sale: Avoid collect sale orders confirmed in backend This happens when, during a payment process, when the order is confirmed from the backend and in Website the cart icon is clicked. What causes the error is that the request is still pinned in the session, so it identifies that certain values should not be loaded and deletes them. The cart() method identifies if it's not a draft order, and in that case it clears the session order to continue with a new one. That causes u
Original PR description
[FIX] website_sale: Avoid collect sale orders confirmed in backend This happens when, during a payment process, when the order is confirmed from the backend and in Website the cart icon is clicked.…
This fixes an issue where Italian electronic invoicing behavior differed between Community and Enterprise editions, causing a test failure around payment status. The change relies on payment matching information instead, making the result more consistent while avoiding unnecessary processing for non-Italian companies.
Original PR description
The test "test_account_move_payment_method" was failing in community only because the payment_state is paid if only l10n_it is installed but is in_payment if the enterprise module is installed. We decided to totally remove the if statement on the payment_state. The matching numbers are enough. Also adding some early returns in the compute to make sure we don't do the search on account.move.line for nothing or compute the document type for non italian companies. no task-id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that accrual-based time-off allocations are recalculated when an employee is selected. It prevents allocation balances from staying blank or incorrect during setup, helping HR users create accurate time-off records.
Original PR description
### Steps to reproduce: - Install Time-off module - Create new allocation - If there is a default employee set remove it - Select Accrual Allocation - Set start date to a year ago - Set an employee ### Current behavior before PR: The allocation days is not getting computed onchange of employees. This is happening because it is computed only when we trigger _onchange_date_from and employee_id is not one of the fields that triggers this onchange method. ### Desired behavior after PR is merged: Since we are checking if we have an employee_id or not in _onchange_date_from we added the employee_id to be one of the fields that triggers the onchange then to recompute the allocation days opw-4100075
Downloading a contact card no longer fails when an address/contact record has no direct name. The system now uses the full available contact name instead, avoiding an error and letting users export the card successfully.
Original PR description
Currently, a traceback is occurring when the user tries to download a card for a child partner of type `other` having no name. To reproduce this issue: 1) Install `Contacts` 2) Create a record in…
Currently, a traceback is occurring when the user tries to download a card
for a child partner of type `other` having no name.
To reproduce this issue:
1) Install `Contacts`
2) Create a record in `Contact & Addresses` of type as `Other Addresses`
in an existing contact
3) Now open the above-created contact
4) Download the Vcard for that record
Error:-
```
AttributeError: 'bool' object has no attribute 'replace'
```
As you can see name is only required when the type is 'contact'.
When the user creates a partner record without a name and tried to download the Vcard, it led to a traceback.
Because the name was used in the Vcard, which is false in this case. https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/models/res_partner.py#L30
**Note:-**
Also in the below line, `/web_enterprise/partner/<model("res.partner"):partner>/vcard`
route was never used anywhere in the Odoo except in one test case.
which was also introduced from the same PR through which the above route was added.
Because `Vcard` was initially in `enterprise` and later shifted to `community`.
https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/controllers/vcard.py#L16-L17
This commit will resolve this issue by taking the `complete name`
when the partner record failed to provide the name.
sentry-5673082917When creating a new sales order line linked to projects, the product search now only shows service-type products. This prevents users from accidentally selecting consumable or other non-service products, reducing order entry mistakes.
Original PR description
When a user creates a new sol, only service-type product should be searched. Before this commit, consumable and other types of product was being searched. task-3972359
The wishlist page is adjusted for small screens so action buttons remain visible, especially in longer translated languages such as French. Removing unused image space improves readability and usability when viewing or zooming on mobile devices.
Original PR description
**Steps:** - Go to Shop - Add a product to the wishlist. - Access the Wishlist page and apply the Mobile View. - Apply Zoom on the mobile view **Issue:** - For some languages (like French) the full button can't be seen at the standard 100% view. Also a column of image is shown extra even though the image is not displayed **Fix:** - Removing the column of image for smaller screens will resolve our issue, and we would be able to see the button upto a lot more zooming ratio. **Affected version:** 17.0~master opw-4089951
Saving product settings will no longer automatically switch pricelist discount display back to hiding discounts. This preserves users' chosen discount display behavior, especially for Point of Sale, unless discounts are deliberately disabled.
Original PR description
The pricelist discount policy is always visibile in 17+, and some users may change it to display discounts in the PoS. Nevertheless, if the sale discounts are not enabled, saving the settings will reset the value to 'hide discounts'. Since the group is ambiguous, has been moved to sale in 17.2, and the discount policy feature is removed in 18, we'll restrict the reset of the discount policies only when the discount group is effectively disabled manually, not any time the settings are saved. opw-4019168 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an internal notification test wait for messages before checking results, preventing occasional false failures. It improves confidence in automated testing without changing user-facing behavior.
Original PR description
Before this PR, the `test_postcommit` test would occasionally fail in a non-deterministic manner. This test ensures that the bus sends notifications after bus records are committed. However, we weren't waiting for the notification to occur before checking the expected channels. As a result, the check could happen too early, leading to test failures. This PR ensures that we wait for the notifications to be sent before verifying that each channel received them. runbot-76481
When a pricelist is duplicated, the new pricelist name now automatically includes “(copy)” instead of keeping the exact same name. This helps users distinguish original pricelists from duplicated ones and reduces confusion when managing pricing.
Original PR description
Before this commit, when user duplicate pricelist then new pricelist is created with same name. After this commit, add sufix '(copy)' in newly created pricelist when user duplicate pricelist. task-4035473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a confirmed sales order is settled in Point of Sale, the “ship later” option now stays off by default instead of being automatically enabled from the original order’s delivery date. This prevents staff from accidentally delaying delivery when completing an in-store payment.
Original PR description
When settling a sale order in the PoS the shiplater option was always turned on. Steps to reproduce: ------------------- * Activate ship later option in PoS config * Create a sale order and confirm it * Open the PoS * Settle the order * Click on pay > Observation: The ship later button is already activated Why the fix: ------------ The button activation is based on the presence or not of a delivery date to fix it we just make sure not to import the delivery date from the original sale order. opw-3987515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Email templates posted in the chatter now stay contained within the message bubble. Wide content can be scrolled horizontally, preventing layout overflow and keeping conversations easier to read.
Original PR description
**Current behavior before PR:** When an email template is posted inside the chatter, the content overflows in the x-direction, causing a UI issue where the message bubble does not handle the overflow properly.  **Desired behavior after PR is merged:** The issue has been fixed, making the message content scrollable inside the message bubble, preventing overflow and maintaining proper UI appearance. **Task**-4083373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The cart now only shows loyalty rewards from programs enabled for eCommerce. This prevents shoppers from seeing or claiming rewards that the business has intentionally disabled online, keeping promotions aligned with store settings.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a loyalty program that applies on future orders; 2. disable it for eCommerce; 3. create a card for you with adequate points for a reward; 4. go to website shop; 5. add product to cart; 6. go to shopping cart view. Issue ----- Claimable reward is display despite being disabled for eCommerce. Cause ----- The `_get_claimable_and_showable_rewards` method doesn't take a program's `ecommerce_ok` field into account when searching for cards. Solution -------- In the domain used, use the result of `_get_program_domain` to ensure only applicable cards from applicable program's are retrieved. opw-3997371
This update fixes failing tests in the subscription module that were caused by incorrect time handling during test execution. The fix ensures that time is properly frozen during testing, preventing intermittent test failures that occurred when tests were run at specific times. This improves the reliability of the subscription testing process.
Original PR description
Before this commit, some tests were failing because the time was not correctly frozen. The failing test could be seen when run like this: faketime '2024-08-31 02:01:00 UTC' ./odoo-bin -c ... runbot errors: 76518, 76519, 76520
[FIX] website_sale: Avoid collect sale orders confirmed in backend This happens when, during a payment process, when the order is confirmed from the backend and in Website the cart icon is clicked. What causes the error is that the request is still pinned in the session, so it identifies that certain values should not be loaded and deletes them. The cart() method identifies if it's not a draft order, and in that case it clears the session order to continue with a new one. That causes undesired modifications in modules that inherit cart() and execute before calling super(), such as website_sale_delivery, that removes carrier from order. With this motification the method sale_get_order() will now discriminate the orders that are completed and clear ir from the session, avoiding losses of information. Description of the issue/feature this PR addresses: This error was detected because the carrier_id was eliminated when following the aforementioned flow. The problem is that clicking on the cart retrieves the order that is in the session, but if it has been confirmed from the backend it should not collect it since at that moment it is not a "cart". A way to see this clearly is with the 'delivery_auto_refresh' module. This module shows the carrier_id field in sale order view (that exists but is not visible), which is collected at website. The flow that exists nowadays remove this value when we follow this steps: [Grabación de pantalla desde 16-08-24 10:41:50.webm](https://github.com/user-attachments/assets/9ec82b67-3e73-4083-b65b-be8d59db6a5a) In this video: 1. Customer starts an order 2. An user confirms the order at backend 3. Customer acceses to /shop/cart 4. Some fields of the sale order can be deleted, such as the delivery carrier If we confirm the order at backend and then follow the flow shown, the value of this field will dissapear. This happens because, as I said before, clicking the cart icon recovers the confirmed sale order (which is no longer a 'cart') and deletes many values of it. Current behavior before PR: If you confirm an order in process from website at backend and then click on the cart icon, certain fields are eliminated. Desired behavior after PR is merged: The cart button identifies whether the order is in confirmed status (or quote sent), and if so removes it from the session before the fields are cleared, thus starting a new order. FL-650-982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176718
This commit improves test coverage for the `website_payment` module by addressing recent updates and scenarios: - **Minimum Amount**: Verifies that donations below the minimum amount are properly handled (PR: [177766](https://github.com/odoo/odoo/pull/177766)). - **Multiple Amounts**: Ensures that multiple donation amounts cannot be selected at once (PR: [176722](https://github.com/odoo/odoo/pull/176722)). - **Last Amount Selection**: Checks that the last selected amount is correct
Original PR description
This commit improves test coverage for the `website_payment` module by addressing recent updates and scenarios: - **Minimum Amount**: Verifies that donations below the minimum amount are properly handled (PR: [177766](https://github.com/odoo/odoo/pull/177766)). - **Multiple Amounts**: Ensures that multiple donation amounts cannot be selected at once (PR: [176722](https://github.com/odoo/odoo/pull/176722)). - **Last Amount Selection**: Checks that the last selected amount is correctly applied (PR: [176722](https://github.com/odoo/odoo/pull/176722)). These enhancements ensure that the module's behavior is thoroughly tested and functioning as expected. During FW to 16.0 we will take in consideration the iframe task-4138385 Forward-Port-Of: odoo/odoo#178565 Forward-Port-Of: odoo/odoo#177908
### Issue: Previous fix: odoo/odoo@4c0f03c7a1d1ec1f99dbc8b2202454e4398e386b In CH tax report, tax amounts from Payments of Expenses paid by company are not shown when using taxes with Cash Basis. ### Explanation: The CH report uses tags to fetch taxes. With previous fix, those tags were still not passed through. ### Fix reasoning: We will use the same condition for the `include_caba_tags` parameter as for the `caba_no_transition_account` context key for consistency. opw-394636
Original PR description
### Issue: Previous fix: odoo/odoo@4c0f03c7a1d1ec1f99dbc8b2202454e4398e386b In CH tax report, tax amounts from Payments of Expenses paid by company are not shown when using taxes with Cash Basis. ### Explanation: The CH report uses tags to fetch taxes. With previous fix, those tags were still not passed through. ### Fix reasoning: We will use the same condition for the `include_caba_tags` parameter as for the `caba_no_transition_account` context key for consistency. opw-3946362 Forward-Port-Of: odoo/odoo#178578 Forward-Port-Of: odoo/odoo#177246
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`. When that happens, if the event is pushed to a Google Calendar and synced in Odoo, all participants' calendars stop syncing from there onwards. <details> ``` 2024-06-26 07:10:57,942 41 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z ! Traceback
Original PR description
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`. When that happens, if the event is pushed to a Google Calendar and…
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`.
When that happens, if the event is pushed to a Google Calendar and synced in Odoo, all participants' calendars stop syncing from there onwards.
<details>
```
2024-06-26 07:10:57,942 41 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z !
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 78, in _sync_google_calendar
synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
File "/opt/odoo/auto/addons/google_calendar/models/calendar_recurrence_rule.py", line 88, in _write_from_google
super()._write_from_google(gevent, vals)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 304, in _write_from_google
self.write(vals)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 71, in write
result = super().write(vals)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3808, in write
fields[0].determine_inverse(real_recs)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1401, in determine_inverse
determine(self.inverse, records)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 219, in _inverse_rrule
values = self._rrule_parse(recurrence.rrule, recurrence.dtstart)
File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 366, in _rrule_parse
rule = rrule.rrulestr(rule_str, dtstart=date_start)
File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1730, in __call__
return self._parse_rfc(s, **kwargs)
File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1698, in _parse_rfc
raise ValueError("unsupported property: "+name)
ValueError: unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z
```
</details>
In https://discourse.gnome.org/t/working-with-evolution-mail-and-web-calendar-using-rrule-fail-because-of-x-evolution-enddate-in-rrule/19710/3 it explains why this happens and how it's actually a supported feature of RFC 5545.
Dateutil doesn't support that feature. It just fails with `ValueError`. Progress is being tracked in https://github.com/dateutil/dateutil/pull/1374.
Regarding what matters to Odoo, we can just strip any X-named params from the RRULE prefix and live happy with the rest (or fail if there's really a wrongly-formatted RRULE param). This way we avoid dateutil to fail unnecessarily and unlock users Google calendars synchronizations.
@moduon MT-6287
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171784Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases - Multiple payment term lines - Discount on payment term lines This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly). After this commit the cash rou
Original PR description
Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the…
Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases
- Multiple payment term lines
- Discount on payment term lines
This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly).
After this commit the cash rounding is applied to the payment terms:
- The amount of each payment term line is cash rounded
- The discounted amount of each payment term line is cash rounded
Reproduce:
1. Install module `account` (or `account_accountant`)
2. Create a payment term with 1 line with 10% discount when paid within 30 days. Ensure "Display terms on invoice" is on. (Invoicing / Accounting -> Configuration (menu) -> Payment Terms)
3. Enable "Cash Rounding" in the settings
4. Create a cash rounding with precision 0.05 and rounding method HALF-UP (Invoicing / Accounting -> Configuration (menu) -> Cash Roundings)
5. Create an invoice
- Payment term from step 2
- Cash rounding from step 3 (set in "Other Info" tab) - A line s.t. the total is 868.35 (This value does not need cash rounding)
6. Confirm the invoice
7. Print the invoice: On the PDF the value 781.52 is shown for the payment terms. But the value should be 781.50 due to the cash rounding.
8. Register payment: The amount 781.52 is suggested. But the value should be 781.50 due to the cash rounding. Changing the amount to 781.50 loses the automatic reconciliation.
task-4095505
opw-3985470
Forward-Port-Of: odoo/odoo#176289Issue: When trying to resend a mail authored by any other user as an administrator, we are going to receive a "Delivery Failed" error even though the mail has been sent. Steps to reproduce: - Send any email as Demo, so they stay in queue for seding under mails. - Go to mails as admin now and try to send the mail manually. (You can use a meeting for example to send the mail, create a meeting and send the mail to notify this meeting.) Solution: Since the issue is triggered when we try
Original PR description
Issue: When trying to resend a mail authored by any other user as an administrator, we are going to receive a "Delivery Failed" error even though the mail has been sent. Steps to reproduce: - Send any email as Demo, so they stay in queue for seding under mails. - Go to mails as admin now and try to send the mail manually. (You can use a meeting for example to send the mail, create a meeting and send the mail to notify this meeting.) Solution: Since the issue is triggered when we try to write on the message_id, which is a related field we might want to specify it in 'mail.mail' so we ensure that message_id is available directly on the 'mail.mail' model. This, will also apply properly the related_sudo=True that we need in order to work with it as administrator. opw-3963124 Forward-Port-Of: odoo/odoo#177098 Forward-Port-Of: odoo/odoo#173406
Because the signature is precomputed and includes the server URL, when running with a non-standard port the test fails as the port does not match the original value used to precompute the signature. - reset `web.base.url` to its default / precomputation value. - patch `TestPaymentTransaction.base_url` to return the same, as that is what `PaymentHttpCommon._build_url` uses to... build the url. Forward-Port-Of: odoo/odoo#178584
Original PR description
Because the signature is precomputed and includes the server URL, when running with a non-standard port the test fails as the port does not match the original value used to precompute the signature. - reset `web.base.url` to its default / precomputation value. - patch `TestPaymentTransaction.base_url` to return the same, as that is what `PaymentHttpCommon._build_url` uses to... build the url. Forward-Port-Of: odoo/odoo#178584
### Steps to reproduce: - Change the main company's country to 'United Kingdom' - Install the Accounting module - The module "account_bacs" is not installed, but it should ### Cause: In account, it checks if `country_code == 'uk'` instead of 'GB' ### Solution: Move `module_list.append('account_bacs')` to the already existing `country_code == 'GB'`. opw-4122475 Forward-Port-Of: odoo/odoo#177561
Original PR description
### Steps to reproduce:
- Change the main company's country to 'United Kingdom'
- Install the Accounting module
- The module "account_bacs" is not installed, but it should
### Cause:
In account, it checks if `country_code == 'uk'` instead of 'GB'
### Solution:
Move `module_list.append('account_bacs')` to the already existing `country_code == 'GB'`.
opw-4122475
Forward-Port-Of: odoo/odoo#177561When a table of content is edited, the anchor ids to each of its h1 and h2 headings are re-generated in order to make the possibly updated navigation links target each individual heading. These ids are generated based on time for the table of content itself and a unique id for the heading. Because of this when links are defined to target those headings anchors, the links do not reference the correct id anymore if the table of content snippet is edited in any way. This commit fixes this
Original PR description
When a table of content is edited, the anchor ids to each of its h1 and h2 headings are re-generated in order to make the possibly updated navigation links target each individual heading. These ids are generated based on time for the table of content itself and a unique id for the heading. Because of this when links are defined to target those headings anchors, the links do not reference the correct id anymore if the table of content snippet is edited in any way. This commit fixes this issue's general case by keeping track of a generated id for the table of content, and assigning ids to headings in their sequence order. Steps to reproduce: - Drop a "Table of Content" block - Define a link to a heading (`#table_of_content_heading_...`) - Save - Edit - Select table of content => The link anchor does not match the heading id anymore. opw-3974850 Forward-Port-Of: odoo/odoo#178333 Forward-Port-Of: odoo/odoo#169408
This commit make card column with 100% for 3 column grid in order to not have forth blank space in mobile view and display on product par row in mobile. opw-4052977 Forward-Port-Of: odoo/odoo#178487
Original PR description
This commit make card column with 100% for 3 column grid in order to not have forth blank space in mobile view and display on product par row in mobile. opw-4052977 Forward-Port-Of: odoo/odoo#178487