Tuesday, March 5, 2024
49 changes · saas-17.1
Enhancements to existing features
This update enhances the visual clarity of website slides by increasing the boldness of the section headings. The change adds a priority style to ensure sections stand out more effectively from the surrounding content. This improves the overall user experience and makes it easier for visitors to quickly understand the slide's key points.
Original PR description
Purpose ======= Increase the bold of the sections in back end to better differentiate them from the content. Specifications ============== Adding !important next to the css bold style (value = 700) applied on the sections to make sure it takes the priority over the default list view sections "fw-bold" class (value = 500). Task-3759152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154990
Resolved issues and error corrections
This fixes a case where certain website request errors could bypass the normal error handling flow. It helps ensure visitors and administrators get consistent error behavior instead of unexpected failures during specific read-only website callbacks.
Miscellaneous changes
The current code was made in response to an issue where the exact_price value would not always be in the response of /orders, which would cause issues and inconsistencies. As of now, this issue seems to not happen anymore and we can thus revert to the original way of handling that which uses less api calls and a faster flow. Forward-Port-Of: odoo/enterprise#58040
Original PR description
The current code was made in response to an issue where the exact_price value would not always be in the response of /orders, which would cause issues and inconsistencies. As of now, this issue seems to not happen anymore and we can thus revert to the original way of handling that which uses less api calls and a faster flow. Forward-Port-Of: odoo/enterprise#58040
This fix prevents form fields with long option labels from breaking the page layout. Business users should see cleaner, more consistent forms, especially in translated views or Studio automation screens.
Original PR description
**Current behavior:** Form fields and/or selections using the oe_inline class and have very long selection options will result in views with many stylistically broken page elements; specifically vertical text and text breaking out of its container. **Expected behavior:** Form views will look uniform. **Steps to reproduce:** 1. Install sale_management and web_studio, then install the Dutch (BE) language pack and activate it 2. From the home screen, go to `Verkoop` (Sales), then toggle studio 3. Go to the `Automatiseringen` (automations) menu -> `Niuew` 4. Observe the broken style **Cause of the issue:** The oe_inline class is allowing auto width, which is problematic for the `trigger` field in this specific instance because there are very long selections available for this selection element. **Fix:** Change width: auto to width: 100%. opw-3756540
This update resolves an issue where website tours sometimes caused buttons to appear blank due to a conflict with content loading. The fix provides a fallback to an empty SVG, ensuring buttons always display correctly. This improves the user experience for website tour functionality.
Original PR description
In the test framework at [1], when a tour is finished, a request to stop loading content is sent to the browser. This clashes with [2] which sometimes is in the middle of a fetch request from the Snippets Menu. (Specifically when loading SVGs icons for buttons.) This commit fixes that by adding a fallback to an empty SVG when the fetch fails. This could lead to buttons appearing empty. [1]: https://github.com/odoo/odoo/blob/eca34179a1657d8fcbdf845349b5b051e5fc6043/odoo/tests/common.py#L1437 [2]: https://github.com/odoo/odoo/blob/eca34179a1657d8fcbdf845349b5b051e5fc6043/addons/web_editor/static/src/js/editor/snippets.options.js#L110 runbot-54422
The project tour now functions correctly on mobile devices. This update resolves a previous bug where the tour would get stuck, preventing users from fully experiencing the feature. The fix involved adding a mobile-specific step and adjusting a trigger to ensure compatibility.
Original PR description
The tour isn't working if you run it on mobile mode, it gets stuck at some points. To fix this issue, a mobile step was added, and one trigger was edited to work with mobile mode as well. task-3709501 Forward-Port-Of: odoo/odoo#155789 Forward-Port-Of: odoo/odoo#153444
This update resolves a potential problem where a channel could be removed while a call was still loading, leading to errors. This fix ensures calls are handled correctly and prevents disruptions to user experience. It's a technical improvement focused on stability.
Original PR description
Before this commit, there could be race conditions in which a channel could be removed while the call was still loading, this commit prevents this issue. task-3660964 Forward-Port-Of: odoo/odoo#149034
This update resolves an issue related to how access keys are used within the loyalty program. The change ensures consistent behavior whether accessing loyalty data through retrieval or subscription methods, improving reliability and preventing potential errors. This update focuses on internal improvements within the loyalty module.
Original PR description
Addendum to https://github.com/odoo/odoo/commit/7ed0a773b6e0 Reference PR: https://github.com/odoo/odoo/pull/150418 Forward-Port-Of: odoo/odoo#155927
This update resolves an error that occurred when creating new websites without a linked company. It also ensures existing Brazilian websites are updated consistently after module installation, standardizing their settings. This improves website creation reliability and data consistency.
Original PR description
This commit fixes an issue on websites creation. If a website is created with no company linked to it, an error is raised because website.company_id has no value. This is fixed by using a .get(). While at it a constistency issue is fixed too. When installing the module, already existing websites don't get their setting changed when the module is installed. A post init hook has been added to address this issue so all brazilian webites have the same behavior. Fixed issues originate from this commit: https://github.com/odoo/odoo/commit/45f28eed95b60119fb1770524e10b84eeee5e95f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rare crash that occurred when Odoo generated initial assets (like CSS and JavaScript). The issue stemmed from a timing problem where multiple processes attempted to create the same directory simultaneously. This change ensures consistent directory creation, preventing the crash and improving stability.
Original PR description
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time…
Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time (CSS, JS); one of the two times might crash.
Traceback :
```FileExistsError: [Errno 17] File exists: '/home/odoo/.local/share/Odoo/filestore/brawl-stars/7d'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/website/models/website.py", line 431, in configurator_apply
redirect_url = theme.button_choose_theme()
File "addons/website/models/ir_module_module.py", line 399, in button_choose_theme
self._theme_remove(website)
File "addons/website/models/ir_module_module.py", line 375, in _theme_remove
self.env['theme.utils'].with_context(website_id=website.id)._reset_default_config()
File "addons/website/models/theme_models.py", line 259, in _reset_default_config
self.env['web_editor.assets'].make_scss_customization(
File "addons/website/models/assets.py", line 38, in make_scss_customization
self.make_scss_customization('/website/static/src/scss/options/colors/user_theme_color_palette.scss', {
File "addons/website/models/assets.py", line 143, in make_scss_customization
self.save_asset(url, 'web.assets_frontend', updatedFileContent, 'scss')
File "addons/web_editor/models/assets.py", line 77, in save_asset
self.env["ir.attachment"].create(new_attach)
File "<decorator-gen-292>", line 2, in create
File "odoo/api.py", line 420, in _model_create_multi
return create(self, [arg])
File "addons/website/models/ir_attachment.py", line 23, in create
return super().create(vals_list)
File "<decorator-gen-61>", line 2, in create
File "odoo/api.py", line 421, in _model_create_multi
return create(self, arg)
File "odoo/addons/base/models/ir_attachment.py", line 636, in create
values.update(self._get_datas_related_values(
File "odoo/addons/base/models/ir_attachment.py", line 277, in _get_datas_related_values
values['store_fname'] = self._file_write(data, values['checksum'])
File "odoo/addons/base/models/ir_attachment.py", line 132, in _file_write
fname, full_path = self._get_path(bin_value, checksum)
File "odoo/addons/base/models/ir_attachment.py", line 112, in _get_path
os.makedirs(dirname)
File "os.py", line 225, in makedirs
mkdir(name, mode)
```
sentry-4417110945
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156232This update resolves an issue where the search bar within the website's fixed header was incorrectly positioned. The fix involves relocating the search element to ensure it appears below the header when the header is in its fixed state, improving the user experience in website edit mode.
Original PR description
Steps to reproduce:
- In website edit mode, have a header with a search icon
('default header').
- Add a few building blocks, enough so that you can scroll.
- Save the page.
- Scroll down until the header is back to fixed on top.
- Click on the search icon.
- Bug: the search bar appears in header (instead of below it, like at
the beginning).
This issue occurs because when the header is fixed and has a 'transform:
translate' property applied, the search modal, which is positioned
absolutely, takes the dimensions of the header instead of those of the
body.
To resolve this, we relocated the '#o_search_modal' element from the
'#header' to '#o_shared_blocks'.
task-3646513
Forward-Port-Of: odoo/odoo#155703This update resolves an issue where the calendar month view wasn't correctly showing the start hour of events. The fix ensures that the start hour is consistently displayed, improving the accuracy of event scheduling and visibility within the calendar. This was a minor bug fix identified and resolved by our development team.
Original PR description
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is display in calendar month view.
The test was failing because when clicking on scale selector, it used '.dropdown-toggle:contains("Week")' however it might happen that the current scale is not week.
This commit fixes this issue by changing the way we access the scale selector.
fixes runbot-59023
Forward-Port-Of: odoo/odoo#156121This update corrects a display issue where landed costs were incorrectly shown for product types like Event Tickets and Gift Cards. The fix involves changing how product types are defined within the system, ensuring landed costs are only visible for service-based products during purchase.
Original PR description
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a…
Steps to Reproduce : - install sales, stock modules - go to products and create new - select product type as Event Ticket,Event Booth or Gift Card - Landed cost boolean is suppose to be visible for a service type product under purchase. Issue : - Landed cost boolean is suppose to be visible for a service type product under purchase, But currently it is visible on other type of products specific to other models like event tickets, event booths etc. Cause: - In product Module there are two Selection fields like detailed_type and type. The detailed_type Selection field contain service, consumable, event booths, event tickets, storable product And the type selection field contains service, consumable, storable product - In xml views for that landed cost boolean the invisible attribute contains the condition like type != service, because of this the landed cost boolean is visible for the product type of event tickets, event booths and gift Cards. Solution: - if we use detailed_type instead of type selection field, then the landed cost boolean field will be invisible on other product types. task- 3725202 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#156133 Forward-Port-Of: odoo/odoo#153371
This update resolves an issue where survey text areas would overlap when resized, particularly when filling them with a lot of text. The fix ensures the text area maintains its intended height and prevents unexpected resizing behavior, improving the user experience for surveys.
Original PR description
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data…
**Steps to reproduce:** - Create a survey and enable all questions in 1 page - Add questions. (Minimum 1 Multiple Lines Text Box) - Test the survey - Fill the text area with a certain amount of data vertically - Now, hold the icon to resize the text area block - It's overlapping with other questions. **Issue:** Fixed `height:1px` is applied to Parent div. **Technical Reason:** With this commit (https://github.com/odoo/odoo/commit/eaacaf122dff62adcdf885f0ffdcb4a506bded27) the height is applied to the parent div and textarea which is the same for the backend(title of the survey) and frontend. Now backend needs to apply this height to the parent and text area because it has to show all data in the text area but, in the frontend, if we change the height of the textarea then while pressing enter the textarea block increases, and this should not happen. **Solution:** So, applying the `h-auto` class to the parent div of textarea. Now, the questions did not overlap with each other. **Task**-3707415 Forward-Port-Of: odoo/odoo#152182
This update resolves an issue where the status bar on mobile devices would overflow when viewing the expense module. The fix ensures the status bar remains within the screen boundaries, providing a consistent and usable experience for users on smaller mobile screens. This improves the overall usability of the expense tracking feature.
Original PR description
Steps to reproduce ================== - Install Expense (hr_expense) - Use a small viewport - Go to Expense => The status bar overflows  opw-3704233 Forward-Port-Of: odoo/odoo#156114 Forward-Port-Of: odoo/odoo#154032
This update resolves an issue where form fields were displaying numerical IDs instead of their intended labels. This change ensures users see the correct labels when selecting options within forms, improving usability and data entry accuracy. The fix was triggered by a user reporting the incorrect display of field IDs.
Original PR description
This commit resolves an issue (arose in [1]) where a select field was displaying IDs instead of labels. Steps to reproduce: - Navigate to edit mode - Drop a form block. - Select the form action type "create customer" (CRM app must be installed). - Add a field for "country". - Add another field and set its visibility to depend on the country value. Issue: Users are seeing IDs instead of country labels. [1]: https://github.com/odoo/odoo/commit/a54f11edb1f81c8dade2a4ef6080b666b94e918d task-3460326 Forward-Port-Of: odoo/odoo#155531
This update resolves a bug where PDF navigation buttons (next, previous, etc.) in e-learning materials were sometimes incorrectly enabled or disabled. The fix ensures these buttons function reliably, regardless of the content's structure or suggested slides, improving the user experience for e-learning courses.
Original PR description
Bug === When we show a PDF in e-learning, we have some navigation buttons (next, previous, last, first) with some conditions for them to be enabled or not (e.g. a documentation can have suggested slides, and so the next button is visible even if we are on the last page). Those conditions are broken (sometimes a button is disabled when it shouldn't and vice versa), this commit aims to fix that issue. Task-3751253 Forward-Port-Of: odoo/odoo#156252 Forward-Port-Of: odoo/odoo#154967
This update fixes an issue that prevented the generation of PDF BOM overviews when products were created with dynamic attribute variants. The change ensures that BOMs are correctly generated, even with this product configuration, allowing users to consistently print accurate BOM reports. This resolves a previous error that impacted the printing of product BOMs.
Original PR description
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: -…
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: - Inventory > Configuration > Products > Attributes Create an attribute with Variants Creation Mode set to "Dynamically". Create a new product with this single attribute and multiple values. Create a BOM for this product with BOM Type set to "Subcontracting". Print the BOM overview. Cause of the issue: - Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function `_get_bom_data` can not apply the method `_select_seller` properly in that case. Notes: - - There is no error if a variant was manually created for that product. - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise. Fix: - As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid. opw-3698050 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152275
This update ensures that product variants are automatically adjusted when product template exclusions are created, modified, or removed. Previously, changes to exclusions didn't reflect on the associated variants. This fix maintains data consistency and accuracy for product offerings.
Original PR description
opw-3693065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156212 Forward-Port-Of: odoo/odoo#155103
This update fixes an issue where tests related to screencast recordings wouldn't run correctly if the necessary files were missing. It also reduces the amount of logging generated during test failures, making debugging easier. This ensures more reliable test results and faster identification of problems with screencast functionality.
Original PR description
Fix similar to 151558 Don't fail if the screencast dir doesn't exist (after clear) Also, reduce the log size. Forward-Port-Of: odoo/odoo#156202 Forward-Port-Of: odoo/odoo#156043
This update resolves a technical issue where accessing a non-existent file URL within the Odoo interface triggered an infinite redirection loop. The fix prevents the system from incorrectly attempting to serve attachments via a fallback mechanism, ensuring a stable and reliable user experience. This improves overall system stability.
Original PR description
Create an attachment with an URL to a static file that does not exists, e.g. '/web/static/idontexist.png'. Inside your browser try to access that file, open <localhost:8069/web/static/idontexist.png>. The browser fails with a "Too Many Redirections" error. When a path is not found, nor in the static files, nor in the controllers, `_serve_fallback` kicks in and attempt to find a resource outside of the router that matches the URL. In case it finds an attachment with a matching URL, it'll deliver it. In this specific case, it finds our attachment and return a redirection to it's URL, which is the same URL as the request hence it loops back. Don't deliver URL attachments via `_serve_fallback`, only deliver stored files. 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#154883
This update fixes an issue where the departure date wasn't correctly populated for employees with ongoing contracts. Now, if an employee has an open contract, the system automatically uses the end date of their most recent expired contract as the departure date. This ensures accurate record-keeping and reporting.
Original PR description
Purpose ======= Take the last expired contract end date if there is not open contract for the related employee. TaskID: 3610709 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#156065
This update corrects a bug where email templates didn't always show all intended recipients (followers/partners) during the preview stage. The issue stemmed from a formatting error when processing partner IDs, leading to a partial list being displayed. This ensures accurate recipient lists are shown when creating and testing email templates.
Original PR description
Steps to reproduce:
---
1. Activate dev mode
2. Go to Email Templates
3. Create a new template
4. Applies to Task
5. Email Configuration > To (Partners)
6. {{[p.id for p in object.message_partner_ids]}}
7. Click on Preview
8. Select a record with followers
9. Look at Recipients
10. => No or not all followers/partners are included
Cause of the issue:
---
Caused by https://github.com/odoo/odoo/commit/cf7ae6b9d562622709e2730c1ea8c43816c169bf
In the case of partner_to being '[2,3,4]'
Split would output '[2', '3', '4]'
So after the isdigit it would be '3'
It should have been 2, 3, 4
opw-3677069
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#149563This update fixes a technical issue preventing the number of open job positions displayed on the website from being translated. The change ensures that job listings are correctly localized for different languages, improving the user experience for international job seekers. This resolves a previous bug impacting translation accuracy.
Original PR description
When listing jobs on the website, we show the number of open positions. Currently the "open positions" were crafted in the QWeb template in such a way that the translation mechanism couldn't extract it and thus it could not be translated. In this commit we fix that, so that it can be translated again. opw-3761288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155974 Forward-Port-Of: odoo/odoo#155876
This update fixes an issue where payments weren't displayed on POS invoices. Previously, after invoicing a POS order, the payment details were missing from the invoice PDF. This change ensures that all payment information is accurately reflected when generating invoices from POS orders, improving invoice accuracy and reporting.
Original PR description
Current behavior: When invoicing a POS order, the payment were not appearing in the invoice. Steps to reproduce: - Create a POS order - Validate and invoice the order - Open the invoice PDF, the payment is not appearing opw-3748596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155771
This update fixes an issue where dates and datetimes were not being formatted correctly, leading to incorrect data storage and the display of 'Invalid Date'. The fix ensures that dates and datetimes are stored in the standard 'YYYY-mm-dd' format, improving data accuracy and reliability.
Original PR description
Bug === Since c5b87e130bd69996c9121227bb6d085035c362fa , the Date / Datetime are not formatted the way they suppose to be. So the value is not correct (it contains the timezone, etc). Because of that, the string "Invalid Date" is stored in database instead of "YYY-mm-dd". Task-3774178 Forward-Port-Of: odoo/odoo#155749
A minor issue preventing the correct styling of the 'preview' button on the course page has been resolved. This ensures that the button consistently displays the appropriate styles for both enabled and disabled content previews, improving the user experience. This change was a simple fix to ensure proper button styling.
Original PR description
Bug ===== Click the `preview` button on the course page. It does not apply the proper styles to the button used for enabled or disabled content previews. Technical =========== With commit https://github.com/odoo/odoo/commit/2d386bc437194b78ea5d446d7b0fa4f5444406e2, the `badge-hide` class used for the `preview` button was replaced and some styles were altered. After this commit ================== The `preview` button is functioning properly. Task-3751285 Forward-Port-Of: odoo/odoo#155003
This update resolves an issue where product documents with incomplete URLs were incorrectly redirecting to local pages, causing errors. The change adds a validation step to ensure URLs in product documents are properly formatted (e.g., including ‘https://’), preventing these redirects and ensuring accurate external links. This improves the user experience and data integrity.
Original PR description
Added a validation for URLs on product.document to resolve an issue where incomplete links on documents will redirect to a local URL instead of an external URL. Thus leading to a page that does not exist. e.g.: youtube.com instead of https://www.youtube.com This seemed like the proper course of action as there would be no reason to not validate as any URL within the database can still be formatted properly and work the same. Changed from targeting 15.0 ir.attachments to targeting product.document on this version as per @ryv-odoo Old PR: https://github.com/odoo/odoo/pull/155322 api.constrains does not seem to work upon creation on this model, so I opted to use the api.onchange. opw-3698591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155806
This update resolves a discrepancy in invoice tax calculations caused by rounding errors during tax processing. The fix ensures that tax totals align correctly between sales orders and invoices, preventing inaccurate financial reporting. This improves the reliability of our invoicing system.
Original PR description
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be:…
Create a sale order having these line values: - Price Unit 54.45, tax 10% not included - Price Unit 600.00, tax 10% not included - Price Unit -500.00, tax 10% not included Tax total will be: |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.44| |Total | 169.89| From the Sales Order create the Invoice Issue: Invoice tax totals will be |name|total| |---|---| |Untaxed Amount |154.45| |Taxes | 15.45| |Total | 169.90| This occurs because when managing the rounding errors for global rounding the system 'force' a 1 cent difference on the negative line that do not need rounding Example: Line 1 - current diff: 0.0 - computed tax amount: 5.455 - tax amount + diff: 5.455, after rounding: 5.45 - stored diff for next line: -0.005 Line 2 - current diff: -0.005 - computed tax amount: 60.0 - tax amount + diff: 59.995, after rounding: 60.0 - stored diff for next line: -0.005 Line 3 - current diff: -0.005 - computed tax amount: -50.0 - tax amount + diff: -50.005, after rounding: -50.01 A solution is to not add the diff when the tax line is already rounded opw-3715229 Forward-Port-Of: odoo/odoo#156016 Forward-Port-Of: odoo/odoo#154861
This update fixes a bug in the daily sales report that previously failed to include differences for bank payments when closing a session. The change restores the original report behavior, ensuring all payment types (bank and cash) are accurately reflected in the report totals. This improves the reliability of sales data reporting.
Original PR description
Current behavior: When entering a difference at the closing of the session for a bank payment method, the daily sales report was not taking into account the difference for the bank payment method. Steps to reproduce: - Start PoS and make a sales with bank and a sales with cash - Close the session with a difference for both payment methods - Go to the daily sales report and check the difference for the bank payment method. The one for the cash is there but not the one for the bank. Note: This bring back the original behavior of the report that was removed here (https://github.com/odoo/odoo/pull/146341) and makes it coexist with the current one so that all cases are covered. opw-3737223 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154929
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is properly visible in other views (kanban, form). Cause: - In list view we used `rating_last_text` field and in other view we used `rating_avg` because of that list there are not data in that field. Fix: - Replace rating_last_text by rating_avg_text field to display proper ratings. Ad
Original PR description
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is…
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is properly visible in other views (kanban, form). Cause: - In list view we used `rating_last_text` field and in other view we used `rating_avg` because of that list there are not data in that field. Fix: - Replace rating_last_text by rating_avg_text field to display proper ratings. Additional info: - There are actually two ratings created from a ticket one from demo data and other from thread send email and helpdesk ratings demo data created before ratings created from thread email and since that ratings does not contains any ratings in it gives `rating_last_text` value as false. We can create our rating demo data after thread's rating by moving ratings related demo data in different file in master. task-3589757 Forward-Port-Of: odoo/enterprise#57914 Forward-Port-Of: odoo/enterprise#52371
Steps to reproduce ================== - Go to timesheet - Switch to the next week - Open a record by clicking on the magnifying glass icon - Go back to the grid view by clicking on the previous breadcrumb => The previously selected week is not restored Cause of the issue ================== We don't export the current state when leaving the view opw-3729307 Forward-Port-Of: odoo/enterprise#57990 Forward-Port-Of: odoo/enterprise#57510
Original PR description
Steps to reproduce ================== - Go to timesheet - Switch to the next week - Open a record by clicking on the magnifying glass icon - Go back to the grid view by clicking on the previous breadcrumb => The previously selected week is not restored Cause of the issue ================== We don't export the current state when leaving the view opw-3729307 Forward-Port-Of: odoo/enterprise#57990 Forward-Port-Of: odoo/enterprise#57510
Each payment acquirer has its own implementation specificities: some implement a 'payment with redirection' flow and others a 'direct payment flow'; sometimes the 'payment with redirection' flow is even implemented as a 'direct payment' flow through an iframe; one payment acquirer could support webhooks while another does not and relies on another mechanism to fetch payment status updates... It can be tricky to guess where to look in the code to determine how a payment acquirer is implemented
Original PR description
Each payment acquirer has its own implementation specificities: some implement a 'payment with redirection' flow and others a 'direct payment flow'; sometimes the 'payment with redirection' flow is…
Each payment acquirer has its own implementation specificities: some implement a 'payment with redirection' flow and others a 'direct payment flow'; sometimes the 'payment with redirection' flow is even implemented as a 'direct payment' flow through an iframe; one payment acquirer could support webhooks while another does not and relies on another mechanism to fetch payment status updates... It can be tricky to guess where to look in the code to determine how a payment acquirer is implemented. On top of that, the online payments ecosystem evolves at a fast pace due to competition, buyouts, and legislation enforcement. Acquirers are thus frequently migrated to new APIs that might differ in implementation from the previous API. To help figure out the *which*, *why*, *how*, and *when* of payment API implementations, a README.md file is added to the main directory of all payment acquirer modules. They can be browsed in human-readable format on GitHub. task-2374916 See also: - https://github.com/odoo/odoo/pull/153016 Forward-Port-Of: odoo/enterprise#57921 Forward-Port-Of: odoo/enterprise#56182
Issue: ---------- As of now, the standard allowance is 1 rupee. Fix: --------- As per Government of India guidelines, the standard allowance is Rs 50000, so we calculated the amount based on the employee's working day. task-3672767 Forward-Port-Of: odoo/enterprise#56593
Original PR description
Issue: ---------- As of now, the standard allowance is 1 rupee. Fix: --------- As per Government of India guidelines, the standard allowance is Rs 50000, so we calculated the amount based on the employee's working day. task-3672767 Forward-Port-Of: odoo/enterprise#56593
Adds a bunch of extra steps in the tour to avoid race errors. Also, make some minor changes in the code: - `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to be sure those methods are called with an existing record, and the ones from `mrp.workorder` call the `mrp.production` method to avoid duplicate; - For the `mrp_workorder.additional.product` wizard, the `production_id` is now got from the context. Before, it was `workorder_id` who was took from
Original PR description
Adds a bunch of extra steps in the tour to avoid race errors. Also, make some minor changes in the code: - `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to…
Adds a bunch of extra steps in the tour to avoid race errors. Also, make some minor changes in the code: - `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to be sure those methods are called with an existing record, and the ones from `mrp.workorder` call the `mrp.production` method to avoid duplicate; - For the `mrp_workorder.additional.product` wizard, the `production_id` is now got from the context. Before, it was `workorder_id` who was took from the context, but it does not make sense since the tablet view was dropped for the Shop Floor (where the MO is now the main model). Also, the `company_id` is now related from the MO. - Regarding the previous point, we pass the key `'production_id'` instead of `'default_production_id'` in the context to avoid the propagation to the creation of the move (otherwise, a component move will have the `production_id` field set and the move will also be count as a by-product move.) Run build error: 56688 Forward-Port-Of: odoo/enterprise#56488
Having a partner and a label that match an account in a bill line leads to the account to be predicted even if it is of the wrong account type. Steps: - Create a payable account X with name containing ABC - Open vendor bill, set partner ABC - On the invoice line set the label to ABC and unfocus the line -> The account that is predicted is account X opw-3717805 Forward-Port-Of: odoo/enterprise#57790
Original PR description
Having a partner and a label that match an account in a bill line leads to the account to be predicted even if it is of the wrong account type. Steps: - Create a payable account X with name containing ABC - Open vendor bill, set partner ABC - On the invoice line set the label to ABC and unfocus the line -> The account that is predicted is account X opw-3717805 Forward-Port-Of: odoo/enterprise#57790
Steps to reproduce: - Create a payroll declaration sheet - Populate the declaration - Delete the declaration sheet - Create another payroll declaration sheet - Populate the declaration again - Try to generate the declaration pdfs Current behaviour: - Error raised Expected behaviour: - Generate declaration pdfs successfully Explanation: When deleting declaration sheet, declarations will not be deleted. They remained in the database. Therefore when excuting the generate p
Original PR description
Steps to reproduce: - Create a payroll declaration sheet - Populate the declaration - Delete the declaration sheet - Create another payroll declaration sheet - Populate the declaration again - Try to generate the declaration pdfs Current behaviour: - Error raised Expected behaviour: - Generate declaration pdfs successfully Explanation: When deleting declaration sheet, declarations will not be deleted. They remained in the database. Therefore when excuting the generate pdfs scheduled action, the system will search the declarations and try to browse the deleted declaration sheet. As a result, error raised. X-original-commit: 7ad17cb Forward-Port-Of: odoo/enterprise#57955
Steps to reproduce: - go to the field service - go to any task add product to it - generate the pdf report 'worksheet report pdf' Issue: - 'totals' labels is not aligned to the right Solution: - aligned the 'labels' to the right us css class Task:3549234 Forward-Port-Of: odoo/enterprise#57951 Forward-Port-Of: odoo/enterprise#50101
Original PR description
Steps to reproduce: - go to the field service - go to any task add product to it - generate the pdf report 'worksheet report pdf' Issue: - 'totals' labels is not aligned to the right Solution: - aligned the 'labels' to the right us css class Task:3549234 Forward-Port-Of: odoo/enterprise#57951 Forward-Port-Of: odoo/enterprise#50101
Since https://github.com/odoo/enterprise/commit/79461fce51f1f931b34aa66f8886a5faaf9c0908 The matching with SO changed. Suppose a SO already invoiced and reconciled with a payment. Before the commit above: - the SO rule was failing. - the AML rule was able to retrieve the related payment. After: - the SO rule found a match. - since there is no available aml to match on the invoice, nothing is suggested to the user on the bank reco widget. ticket_id: 3776876 Forward-Port-Of: odoo/en
Original PR description
Since https://github.com/odoo/enterprise/commit/79461fce51f1f931b34aa66f8886a5faaf9c0908 The matching with SO changed. Suppose a SO already invoiced and reconciled with a payment. Before the commit above: - the SO rule was failing. - the AML rule was able to retrieve the related payment. After: - the SO rule found a match. - since there is no available aml to match on the invoice, nothing is suggested to the user on the bank reco widget. ticket_id: 3776876 Forward-Port-Of: odoo/enterprise#57958
Before this commit the test `test_image_crop` sometimes failed. This was because the browser quit while the image of the image cropper was loading. This operation caused an error, that was caught by the browser and then by the test infrastructure but *after* the tour was marked as succesful. After this commit, we wait a little bit longer, that is, until the cropper widget (which is a JQuery extension) appears. runbot-error-59063 Forward-Port-Of: odoo/enterprise#58002
Original PR description
Before this commit the test `test_image_crop` sometimes failed. This was because the browser quit while the image of the image cropper was loading. This operation caused an error, that was caught by the browser and then by the test infrastructure but *after* the tour was marked as succesful. After this commit, we wait a little bit longer, that is, until the cropper widget (which is a JQuery extension) appears. runbot-error-59063 Forward-Port-Of: odoo/enterprise#58002
In some cases, when the cron to fetch transaction is running, we first set the status of the connection to "fetching transactions" which is displayed on the dashboard. Once the process is over, status is changed to "done". If an error happen when contacting the provider, status is also reset in order to not display the "fetching status" message forever. However it can happen that an error occured when creating transaction in database (wrong configuration inside the journal, etc) and those errors
Original PR description
In some cases, when the cron to fetch transaction is running, we first set the status of the connection to "fetching transactions" which is displayed on the dashboard. Once the process is over, status is changed to "done". If an error happen when contacting the provider, status is also reset in order to not display the "fetching status" message forever. However it can happen that an error occured when creating transaction in database (wrong configuration inside the journal, etc) and those errors were not resetting the fetching_status flag. Hence leaving the customer with the impression that it was still loading transactions. This commit fixes the problem by resetting the flag in such cases. So if such an error happen during the cron, it won't fetch transactions and display will be clean. Error will still be raised to the customer if he clicks on manual refresh. Forward-Port-Of: odoo/enterprise#56380
When the detected skill belonged to a skill type for which none of the levels were marked as default, a validation error would occur as the level is a required field of `hr.applicant.skill`. Ticket #3673664 Forward-Port-Of: odoo/enterprise#57269
Original PR description
When the detected skill belonged to a skill type for which none of the levels were marked as default, a validation error would occur as the level is a required field of `hr.applicant.skill`. Ticket #3673664 Forward-Port-Of: odoo/enterprise#57269
- When trying to delete a record and receiving an OdooFinRedirectException(mode=link), allow record deletion. - When trying to link with a bank account and record is too old and has been deleted server side. Don't display traceback saying to reopen in link mode, instead delete record and create a new one. Forward-Port-Of: odoo/enterprise#57788
Original PR description
- When trying to delete a record and receiving an OdooFinRedirectException(mode=link), allow record deletion. - When trying to link with a bank account and record is too old and has been deleted server side. Don't display traceback saying to reopen in link mode, instead delete record and create a new one. Forward-Port-Of: odoo/enterprise#57788
To reproduce: ============= - on Safari (Epiphany for Linux) - on a task for which you can "Sign Report" - click on "Sign Report" -> on portal "Sign" button is badly positioned which make it unclickable Problem: ======== - apparently on Browsers like Safari, we must specify position for the button otherwise it won't be correctly positioned Solution: ========= - add `align-self-star` to make sure the button is correctly positioned at the start of the grid layout opw-3725269  Forward-Port-Of: odoo/enterprise#56517
Currently it's imposible to patch preparationDisplayService, so it's not possible to make any customizations and the only workaround is copying the whole service's functionality. By adding the export declaration the file can be imported and the service can be patched, which allows to make customizations to it's functionality. Forward-Port-Of: odoo/enterprise#56461
Original PR description
Currently it's imposible to patch preparationDisplayService, so it's not possible to make any customizations and the only workaround is copying the whole service's functionality. By adding the export declaration the file can be imported and the service can be patched, which allows to make customizations to it's functionality. Forward-Port-Of: odoo/enterprise#56461
…t in test Before this commit, the test /web_studio.test_export crash in single app testing because the model on which the test is done did not have a currency field. After this commit, there is no crash as we create a new currency field if necessary. runbot-error-57418 Forward-Port-Of: odoo/enterprise#57686
Original PR description
…t in test Before this commit, the test /web_studio.test_export crash in single app testing because the model on which the test is done did not have a currency field. After this commit, there is no crash as we create a new currency field if necessary. runbot-error-57418 Forward-Port-Of: odoo/enterprise#57686
Fix wrong value for crontract creation in test file test_payroll_ma.py. task : 3774041 Forward-Port-Of: odoo/enterprise#57721
Original PR description
Fix wrong value for crontract creation in test file test_payroll_ma.py. task : 3774041 Forward-Port-Of: odoo/enterprise#57721
UK users often request the option to create customer statements. Now that the customer statements module has been deployed in Odoo 17, UK users can benefit from it by default. Since this is needed in 17.0, this commit creates a bridge module. task-3764637 Forward-Port-Of: odoo/enterprise#57530
Original PR description
UK users often request the option to create customer statements. Now that the customer statements module has been deployed in Odoo 17, UK users can benefit from it by default. Since this is needed in 17.0, this commit creates a bridge module. task-3764637 Forward-Port-Of: odoo/enterprise#57530
In large database, the time to unlink sale.order or sale.order.line can be huge, because some index are needed. @rco-odoo @arj-odoo Forward-Port-Of: odoo/enterprise#57783 Forward-Port-Of: odoo/enterprise#39414
Original PR description
In large database, the time to unlink sale.order or sale.order.line can be huge, because some index are needed. @rco-odoo @arj-odoo Forward-Port-Of: odoo/enterprise#57783 Forward-Port-Of: odoo/enterprise#39414