Daily updates from Odoo
Friday, May 17, 2024
16 changes
Resolved issues and error corrections
The Gantt calendar view now displays times in the correct format based on your location and language settings. Previously, times were always shown in 12-hour format with AM/PM regardless of regional preferences. This update ensures that users in regions using 24-hour time format will see times displayed correctly.
Original PR description
Issue: ------ When we go to a gantt view with the day view, the time format is always displayed in 12-hour format followed by "am" or "pm". Depending on the location, this format may also be 24 hours. Solution: --------- Use the current localization to determine the time display format. opw-3867317
This fix resolves an issue where the Starshipit shipping carrier would fail with an error when the API doesn't return pricing information. The system now retries fetching shipping details in the background to ensure accurate pricing is captured, preventing order processing failures.
Original PR description
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as welljust in case the API didn't return the total_shipping_price again. task-3887386
The Journal Report now displays more efficiently when expanding line items, eliminating excessive white space that previously caused horizontal scrolling. This improvement enhances the user experience by keeping the report properly sized for the screen without requiring users to scroll horizontally.
Original PR description
When unfolding the journals, a lot of empty, unused space was left around the values. This lead to the report easily becoming too large for the screen, causing the display of an horizontal scrollbar, and hence degrading the user experience. We fix that by removing any notion of minimal width for this report specifically.
This fix resolves an issue where the selected reporting period was not being applied when accessing the EC Sales List report from the Tax Report warning message. Users will now see the correct period when clicking the "Do not forget to submit the EC Sales list report" warning, ensuring accurate tax reporting for intra-community sales.
Original PR description
When accessing EC listing through the "Do not forget to submit the EC Sales list report" warning, the tax report's options used not to be passed onto EC listing. Steps to reproduce original issue: - Install `l10n_be_reports` - Create an invoice for a customer with 'Intra-Community' as a 'Fiscal Position' - Confirm it - Go to: Accounting > Reporting > Statement Reports > Tax Report - Select a period that'd include the invoice - Click on the "Do not forget to submit the EC Sales list report" warning - The period selected will be the wrong one task-3891799 Forward-Port-Of: odoo/enterprise#62726 Forward-Port-Of: odoo/enterprise#62642
This fix prevents creating URL redirects (308 rewrites) that point to existing website pages, which was causing unpredictable and inconsistent behavior. When a redirect pointed to an existing page like the shop or homepage, the system would sometimes show the wrong content depending on the order of internal routing rules. The fix ensures redirects only work as intended by blocking redirects to existing controller pages.
Original PR description
Creating a 308 which redirects to an existing controller will have unpredictable (and unwanted) behaviors. Indeed, 308 are there to redirect an existing URL (like `/shop`) to a non-existing URL (like…
Creating a 308 which redirects to an existing controller will have unpredictable (and unwanted) behaviors. Indeed, 308 are there to redirect an existing URL (like `/shop`) to a non-existing URL (like `/my-super-shop`) and to make it so that non existing URL will respond with the content of the existing URL. The way it's done is that it simply replace the routing map rule for the given URL by two new rules: - One for the non-existing URL (chosen url_to) which will serve the existing url endpoint - One for the existing URL, which will be turned into a redirect endpoint This works fine except if you actually select an existing controller as url_to in the 308 rewrite. In this case, there will be 2 werkzeug Rules for the same URL, which is bad. Worst than that, depending of the selected controller the order of those 2 Rules will change, leading to different behavior. Step to reproduce: - Create a 308 from /blog to / (note that "/" is a controller) - Go to /blog, it will redirect and show the homepage - Go to /, it will show the homepage - Now edit the 308 and redirect /shop to / - Go to /shop, it redirects to / but won't show the homepage, it will show the shop page - Go to /, it will show the shop page Technically, here is the routing map for both cases: 1. 308 shop case ``` <FasterRule '/' -> functools.partial(<bound method WebsiteSale.shop of <odoo.http.CustomerPortal (extended by PortalAccount, PaymentPortal, CustomerPortalExternalTax, SaleStockPortal, CustomerPortal, PaymentPortal, PaymentPortal, WebsiteSaleDelivery, WebsiteSaleExternalTaxCalculation, WebsiteSale, WebsiteSaleStockRenting, WebsiteSaleStockRenting, WebsiteSale, WebsiteSaleRenting, PaymentPortal, CustomerPortalExternalTax, CustomerPortal, WebsiteAccount) object at 0x7f4d9468a6b0>>)>, <FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website) object at 0x7f4d94583460>>)>, ``` 2. 308 blog case ``` <FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website) object at 0x7f7fc9ebd7e0>>)>, <FasterRule '/' -> functools.partial(<bound method WebsiteBlog.blog of <odoo.http.WebsiteBlog object at 0x7f7fc9d69090>>)>, ``` You see that the Rule order is inverted from one case to another. We could have decided to do another fix and adapt the `_generate_routing_rules()` method to keep only one Route but that seems worst as: 1. 308 are not designed for that in the first place, not even sure what we would want 2. it will technically be far from ideal, having the check routing map to check if exists already and ensure the same behavior all the time Note that testing a few main controllers, only the /shop seems to lead to this different behavior. Note that it's a bit of a non-stable change, so 17.0 seems like a good compromise. Especially since the /shop example is not buggy before 17.0 as somehow the `Website.index` Rule is before the `WebsiteSale.shop`. ``` <FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website, WebsiteTest) object at 0x7fad28571660>>)>, <FasterRule '/' -> functools.partial(<bound method WebsiteSale.shop of <odoo.http.WebsiteSale (extended by WebsiteSaleDelivery, WebsiteSale) object at 0x7fad28435e40>>)>, ``` opw-3901713
This fix resolves an issue where icons were being incorrectly cropped when converted to PNG format. The problem was caused by using incorrect coordinate values when positioning the icon within the image. By using the correct coordinate values, icons now export with proper sizing and positioning, ensuring users see complete and properly formatted icon images.
Original PR description
Commit that introduced the issue:
https://github.com/odoo/odoo/commit/e806328bc5bd8526594e8e2b90685c03504dea79
Issue:
=====
when an icon is converted to png it's cropped.
Steps to reproduce the issue:
=============================
- Go to this url: {host}/web_editor/font_to_img/61802/rgb(0,143,140)/rgb(255,255,255)/190x200
- The icon is cropped.
Origin of the issue:
=====================
In this case we are using `top` and `left` as they are the top left corner of the icon inside the image , but in reality the returned value is 0 , and the top left corner is represented by `box[0]` and `box[1]`.
Solution:
=========
Use of `box` values instead of `top` and `left`
Before:
======
After:
====
opw-3865845
Forward-Port-Of: odoo/odoo#163006This fix resolves errors that occur when trying to modify recurring calendar events if the original base event has been archived. Previously, the system would continue using the archived event as the base, causing errors or inconsistencies when users tried to change recurrence patterns. Now the system automatically selects a valid non-archived event as the new base event, allowing recurrence modifications to work smoothly.
Original PR description
When the base event is archived, it continues being the base event of the recurrence, and when trying to change the recurrence of all the events of the recurrence, an error is thrown or some…
When the base event is archived, it continues being the base event of the recurrence, and when trying to change the recurrence of all the events of the recurrence, an error is thrown or some inconsistencies occur. To test the problem, you can follow these steps: 1. Create a recurrence of events from a non included day on the recurrence (example: recurrence on tuesday and friday and the start of the recurrence on monday). The first event will be archived automatically. 2. Open other event of the recurrence. 3. Modify the recurrence for all events (example: change the weekdays, set just tuesday instead of tuesday and friday) An error will be thrown. See next gif:  By making these changes, the base event will be updated, as indicated in the `_select_new_base_event` method, so these inconsistencies will not occur when making the changes. See next gif:  cc @Tecnativa TT46742 ping @pedrobaeza @chienandalu --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165659 Forward-Port-Of: odoo/odoo#149349
When users create a menu item with special characters in the URL (like spaces) that doesn't exist, and then create the page through the "Create Page" button, the menu link now automatically updates to point to the new page. Previously, the menu would continue pointing to the old broken link, requiring manual correction.
Original PR description
Users can create menu items whose URL contain special characters (e.g. spaces, apostrophes, etc.). This is a legitimate use, as menus can for instance redirect towards uploaded files whose name may include such characters. However, when the URL doesn't exist, we land on a 404 page. If we then create the page through the "Create Page" button, special characters are slugified for the new page. At that point, we need to update the menu's URL accordingly. Steps to reproduce: 1. Create a Menu "Test A" 2. Add a URL with a space "/test a" 3. Save it 4. Go to the website, and click on the menu "Test A" (it opens the URL "/test%20a", which lands on a 404 page) 6. Click on "Create Page" (the created page uses the URL "/test-a") 7. Save it 8. Click again on the menu "Test A" => You land on the same 404 as before, on "/test%20a". opw-3896659 Forward-Port-Of: odoo/odoo#165602 Forward-Port-Of: odoo/odoo#165408
Fixed a bug in the job listings page that caused an error when some job postings had incomplete location information (missing city). The system now properly handles job listings with varying levels of location detail, allowing the page to display and sort all jobs correctly without crashing.
Original PR description
Steps to reproduce: - Install `website_hr_recruitment` - For one of the job listing add a job location without specifying a city - For another job listing add a job location with a city - Go to `/jobs` url Issues: Since one of the record doesn't have a city specified `record[city]` is False. This resulted in a traceback in the `sorted` call as we were comparing string to boolean. opw-3911415 Forward-Port-Of: odoo/odoo#165094
Colombian phone numbers starting with 324 were incorrectly marked as invalid due to outdated phone number validation data. This fix updates the validation rules to recognize these numbers as valid, ensuring customers and contacts in Colombia can properly register their phone numbers in the system.
Original PR description
Current behavior:
---
Colombian phone numbers starting with 324 are invalid.
Steps to reproduce:
---
parsed = phonenumbers.parse('324 1234567', 'CO')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False
Cause of the issue:
---
Old versions of phonenumbers (external library) are not
up to date with the latest colombian phone system changes
Fix:
---
Monkey patched the library
Similar as: https://github.com/odoo/odoo/commit/b7878038e0aca885aa174ccd74be9ffd4b393a89
opw-3870579
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#164848
Forward-Port-Of: odoo/odoo#164608Fixed an issue where the 'Everybody's Calendar' filter selection was lost when users navigated back to the calendar view using the breadcrumb. The filter preference is now saved and restored automatically, eliminating the need to reselect it each time. This improves the user experience by maintaining filter settings across navigation.
Original PR description
Version: ---------- sass-16.3 Steps to reproduce: -------------------------- - open the Calendar module - click on the everybody's calendar filter option to view all the meetings - click on any…
Version: ---------- sass-16.3 Steps to reproduce: -------------------------- - open the Calendar module - click on the everybody's calendar filter option to view all the meetings - click on any meeting to open the form view for that meeting - now navigate back through the breadcrumb - the everybody's calendar filter is now unchecked Issue: ---------- The 'Everybody's Calendar' option is not set and one needs to check it again every time he come back through the breadcrumb. Cause: ---------- All the other filters are saved in the backend through orm calls but the All filter is not saved since it does not have a recordId. Solution: ---------- The filter state is now stored in the user context, so when a user come back through the breadcrumb the previous set value is taken from the user context. task-3792066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165459 Forward-Port-Of: odoo/odoo#160952
This fix resolves an issue where re-enabling a warehouse resupply connection would create a duplicate route instead of reusing the existing one. When users removed and then re-added a warehouse as a resupply source, the system now correctly restores the previous route rather than creating a new one, preventing confusion and data duplication.
Original PR description
Steps to reproduce: - Create two warehouses A & B - Open the warehouse B form - Set warehouse A as resupply and save - Remove warehouse A as resupply and save - Set warehouse A as a resupply again and save Issue: Instead of unarchiving the existing resupply route, it created a new route instead, meaning we have now two resupply routes from the same warehouse to the same warehouse. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165660 Forward-Port-Of: odoo/odoo#165129
This fix resolves an issue where customers would see conflicting messages when browsing product variants on the website. Previously, when switching to a deleted product variant, both a "product doesn't exist" message and an outdated stock availability message would display simultaneously. The fix ensures that only the appropriate message appears based on the current variant's status.
Original PR description
Issue: ====== Availablity message and product doesn't exist shows at the same time. Steps to reproduce the issue: ============================= - Create a storable product with 2 attributes each having 2 values - Set show available qty below 5 units - Remove one of the created variants - Set qty for all the other variants to 3 (anything less than 5 and > 0) - Go to website page of the product and switch between variants - You can see that when we go to the deleted variant it shows both messaged. "Deoesn't exist" message for the current variant and stock message from the old variant that we switched from Origin of the issue: ==================== When the product doesn't exist we don't update the availability message neither we hide it. Solution: ========= We can use the same trick to show/hide the not available message but in the opposite logic to show/hide the availability message. opw-3875941 Forward-Port-Of: odoo/odoo#163979
Fixed a technical issue that caused an error when users clicked the print button on survey responses. The problem occurred because comment fields were being incorrectly counted as answers when calculating survey statistics. The fix ensures that only actual answers are counted, not optional comments, allowing users to successfully print their survey participation records.
Original PR description
Purpose ======= Fix the traceback appearing when clicking on the print button for a survey participation. Specifications ============== When preparing the print page statistics, the number of correct/skipped/partial/incorrect answers are computed based on the user input lines. The issue is that when the user input lines are retrieved, the comments are also taken into account. So when the user input lines for a simple choice question are accessed, a traceback appears as we got 2 input lines (the simple choice answer and the comment) where we expected only 1. Fixing the issue by removing from the considered user input lines the ones related to comments if they're not considered as being an answer. (the comment_count_as_answer field on the question is False). related PR: odoo/odoo#120629 Task-3893199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163346
Popups were not appearing on the Point of Sale login page because the login page had a higher display priority (z-index). This fix increases the popup priority so they now display correctly on top of all other elements, ensuring users can see important notifications and dialogs.
Original PR description
Prior to this commit, popups would not appear on the login page due to its z-index being set to 1000. This commit resolves the issue by setting the staring z-index of the popups to 10000, ensuring that popups are displayed on top. opw-3930943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where long footer text was not wrapping properly in boxed document layouts, causing text to overflow. An outdated CSS rule that was originally designed for a different footer format has been removed, allowing footers to display correctly regardless of length.
Original PR description
If the footer is too long in a boxed layout, it's not properly wrapped. This css rule was introduced in saas-15 in 4c8a806a23f7d0da8f43c0bb5ebf7307776bf000 to fix an issue where the phone/vat fields of the footers could be wrongly displayed. (in those older versions, you had harcoded company fields in the footer, like phone and vat) Now footer is a simple text, so this css line is not relevant anymore. steps to reproduce: - go to settings, click on "configure document layout" - select boxed - add a really long one-line footer - check the preview (or download the pdf preview) before this commit:  after this commit:  opw-3871778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162921