Friday, December 1, 2023
37 changes · 17.0
Enhancements to existing features
Point of Sale receipts now show items priced at zero as “Free” instead of displaying “0.00”. This makes receipts easier for customers and staff to understand when complimentary items or promotions are included.
Original PR description
For orderlines with a price of 0, the receipt will now display the price as 'Free' instead of '0.00'. Enterprise PR: odoo/enterprise#51338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an internal workaround used when creating chat channel members and replaces it with a cleaner approach. It improves maintainability in the mail/discuss area without changing the expected user experience.
Original PR description
Relying on such a hack, checking a sentinel against a value in the context to check from where the method was called is really not a good practice. Especially when there is a nicer way to do it.
Free items on receipts will now display "Free" instead of "0.00" for better clarity and professionalism. This improvement applies to point-of-sale systems in Belgium and Sweden, making receipts more user-friendly and easier to understand at a glance.
Original PR description
pos*: pos_blackbox_be, pos_l10n_se For orderlines with a price of 0, the receipt will now display the price as 'Free' instead of '0.00' and will remove the tax letter following this price. Community PR: odoo/odoo#143285
Added validation checks to a menu editing test to catch timing issues where dialogs weren't closing properly. This improvement helps prevent intermittent test failures and makes it easier to identify similar issues in the future.
Original PR description
The test "edit/delete menus" sometimes failed on runbot (error 23054) because there're 3 .btn_primary in the footer, whereas only one is expected. When this happened, it was because the second dialog wasn't closed yet. This commit adds assertions on the number of dialogs, which helped to understand and reproduce the issue, and which can also help in the future. Related to PR odoo/odoo#143813 which fixes the issue. Forward-Port-Of: odoo/enterprise#51587
This update refreshes the Spanish language translations for the Mexican Electronic Invoice (EDI) module. The changes ensure that users in Spanish-speaking regions see accurate and up-to-date text throughout the invoicing system, improving the user experience and maintaining compliance with regional requirements.
Resolved issues and error corrections
This fixes automated checks for the mail composer so they work reliably when demo data is not installed. It helps keep validation stable for mail-related workflows and automated actions without changing day-to-day user behavior.
Original PR description
runbot-26628
Miscellaneous changes
This commit's purpose is to give back to the portal user the access rigth to read on the model project.milestone. This access was removed because it was judge that it was not needed to give access to portal user to an entire model. The issue it created is that while the name_get still works, it is no longer possible to do a search on the milestone field on the portal sharing. The access right will thus be added back, but with some restriction. Instead of giving access to the full model, the use
Original PR description
This commit's purpose is to give back to the portal user the access rigth to read on the model project.milestone. This access was removed because it was judge that it was not needed to give access to…
This commit's purpose is to give back to the portal user the access rigth to read on the model project.milestone. This access was removed because it was judge that it was not needed to give access to portal user to an entire model. The issue it created is that while the name_get still works, it is no longer possible to do a search on the milestone field on the portal sharing. The access right will thus be added back, but with some restriction. Instead of giving access to the full model, the user will only have access to the milestone linked to the projects that were shared with him. A different fix is planned for the master version, since it involves changes that are not allowed in stable. affected version : 16.0 -> 17.0 ticket - https://www.odoo.com/web#id=3548142&cids=1&model=project.task&view_type=form 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#144035
This update helps Odoo identify which required modules are missing when importing an industry module. It supports clearer guidance on whether a customer may need to adjust their plan before completing the import.
Original PR description
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
This fix restores the Website settings category to behave as a normal selectable category for employees. It prevents a technical portal/public setting from changing the employee settings view into debug-only boolean options, making website configuration easier to access and understand.
Original PR description
The website_page_controller_expose is a technical model for portal and public, not for employee The side-effect of the change was that, before this commit, the category Website was no longer a selection but a list of boolean only accessible in debug mode Introduced at 198e226f5b 
This change updates HTTP handling tests around forwarded port information, helping Odoo behave correctly when it runs behind proxies or load balancers. This matters for businesses using hosted or reverse-proxied deployments because generated links and request handling are more likely to reflect the public-facing access point.
Original PR description
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
Fixed an intermittent test failure in the spreadsheet module where the cleanup process wasn't completing before the test ended. Added an extra step to ensure the spreadsheet properly closes and cleans up its resources, making the automated tests more reliable.
Original PR description
The tour `spreadsheet_create_list_view` would sometimes fail as the `beforeunload` process of the spreadsheet action occured at the last step of the test and is slow enough to be interrupted when the tour ends. This revision addresses this issue by adding an explicit last step to let the spreadsheet action clean itself properly. fixes runbot errors 21468 Forward-Port-Of: odoo/enterprise#51795
Fixed a timing issue in the bank reconciliation testing process where the system was switching views before a line reset operation completed. This caused test failures when trying to modify unmatched lines. The fix adds proper wait conditions to ensure reset operations finish before proceeding to the next step.
Original PR description
Currently there is the following problem in the tour. In some step we reset the the matching of a line. In the following step there is no trigger or extra_trigger waiting for the reset to finish. Due to this we may switch to the list view before the reset is finished (2 steps after starting the reset). If this happens the tour fails since the line we reset needs to be unmatched in the list view (to be able to modify it). Forward-Port-Of: odoo/enterprise#51876 Forward-Port-Of: odoo/enterprise#51816
This update enhances the logging functionality in the Sendcloud delivery integration by adding parameters to logger messages. This improvement makes it easier for support teams to debug shipping rate request issues by providing more detailed information in system logs.
Original PR description
Without params, it's impossible to debug for the rate request opw-3544614 Forward-Port-Of: odoo/enterprise#51429 Forward-Port-Of: odoo/enterprise#51059
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#144448
Original PR description
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#144448
Before this PR: When we are in a call in full-screen mode, if we have a tour marker visible in the background, it also becomes visible in the call. This is because the component targeted to go into full-screen mode was the 'body,' and the 'call' component is displayed in full screen by increasing the width and height of the component. After the PR: In this pull request, the 'call' component is targeted to go into fullscreen mode, allowing other parts of the DOM to 'hide' in the ca
Original PR description
Before this PR: When we are in a call in full-screen mode, if we have a tour marker visible in the background, it also becomes visible in the call. This is because the component targeted to go into full-screen mode was the 'body,' and the 'call' component is displayed in full screen by increasing the width and height of the component. After the PR: In this pull request, the 'call' component is targeted to go into fullscreen mode, allowing other parts of the DOM to 'hide' in the case of fullscreen mode. This results in the tour marker not being visible in fullscreen mode. task-3502417 Forward-Port-Of: odoo/odoo#144561 Forward-Port-Of: odoo/odoo#138900
Issue: When triggering an orderpoint, the date will be set to midnight UTC. This will cause issue with users in timezones UTC-x, as it will display the date as the day before. This is a so-so fix to reduce the number of impacted users by moving the orderpoint date from 0.00 to 12.00. opw-3579318 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144447 Forward-Port-Of: odoo/odoo#143385
Original PR description
Issue: When triggering an orderpoint, the date will be set to midnight UTC. This will cause issue with users in timezones UTC-x, as it will display the date as the day before. This is a so-so fix to reduce the number of impacted users by moving the orderpoint date from 0.00 to 12.00. opw-3579318 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144447 Forward-Port-Of: odoo/odoo#143385
Current behaviour: --- When coloring a word multiple colors, then wanting to re-color it a unified color, there is a traceback. Steps to reproduce: --- 1. Go to Settings 2. Click on Configure Document Layout 3. In Company Details, select a word 4. (eg: YourCompany) 5. Color half in yellow and half in red 6. (eg: Your in yellow, Company in red) 7. Then select the whole word 8. Color it in a unified color (eg: black) 9. Traceback Cause of the issue: --- range.setEnd(...endPos
Original PR description
Current behaviour: --- When coloring a word multiple colors, then wanting to re-color it a unified color, there is a traceback. Steps to reproduce: --- 1. Go to Settings 2. Click on Configure Document Layout 3. In Company Details, select a word 4. (eg: YourCompany) 5. Color half in yellow and half in red 6. (eg: Your in yellow, Company in red) 7. Then select the whole word 8. Color it in a unified color (eg: black) 9. Traceback Cause of the issue: --- range.setEnd(...endPos(last)) was throwing a warning: During applyColor, Sanitize is called, which merges similar nodes. (using moveNodes) After the merge, out of n similar nodes, only the first one is still contained in the document. opw-3502124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144403 Forward-Port-Of: odoo/odoo#138757
Currently there is a traceback in case of a 100% discount on an invoice line. This commit fixes the issue by computing the discount differently. Previously it was tried to calculate the discount amount from the discounted value and the discount factor. This is (mathematically) not possible if the discounted value is 0. After this commit we compute and use the undiscounted value in case the discount is 100% to compute the discount amount. The computation was adapted from '_prepare_edi_vals
Original PR description
Currently there is a traceback in case of a 100% discount on an invoice line. This commit fixes the issue by computing the discount differently. Previously it was tried to calculate the discount amount from the discounted value and the discount factor. This is (mathematically) not possible if the discounted value is 0. After this commit we compute and use the undiscounted value in case the discount is 100% to compute the discount amount. The computation was adapted from '_prepare_edi_vals_to_export' from account.move.line Reproduce 1. Install l10n_es_edi_tbai 2. Select the Spanish company 3. Settings > Accounting: Ensure "Test Mode" is set in Spain Localization section 4. Create a new invoice with Spanish customer 5. Add a line with a 100% discount 6. Confirm the invoice 7. Process the invoice with TicketBAI 8. Error / Traceback opw-3572426 Forward-Port-Of: odoo/odoo#143328
Steps to reproduce: - Create a Batch transfer and create two reciept in it each with a serial tracked product in them - Confirm the batch transfer Bug: in the detailed operation tab of the batch transfer (use existing lots/ create lots) options of the picking type are not respected and lot id is displayed instead of lot name (many2one instead of char field) Fix: keep the same batch transfer as in the pickings that constitute it opw-3541324 Forward-Port-Of: odoo/odoo#143891 Forward-
Original PR description
Steps to reproduce: - Create a Batch transfer and create two reciept in it each with a serial tracked product in them - Confirm the batch transfer Bug: in the detailed operation tab of the batch transfer (use existing lots/ create lots) options of the picking type are not respected and lot id is displayed instead of lot name (many2one instead of char field) Fix: keep the same batch transfer as in the pickings that constitute it opw-3541324 Forward-Port-Of: odoo/odoo#143891 Forward-Port-Of: odoo/odoo#142541
Currently, the arrow of a popup is not taken into account when computing its position resulting in an overlap with its parent element in some cases. This commit fixes this situation. Steps ===== - Install module project_enterprise - Create a project with a milestone set at the end of the current month - Assign this milestone to a task with planned dates set - Open the Gantt view of the project - Hover the milestone diamond Issue ===== - The popup displaying the milestone name is pa
Original PR description
Currently, the arrow of a popup is not taken into account when computing its position resulting in an overlap with its parent element in some cases. This commit fixes this situation. Steps ===== - Install module project_enterprise - Create a project with a milestone set at the end of the current month - Assign this milestone to a task with planned dates set - Open the Gantt view of the project - Hover the milestone diamond Issue ===== - The popup displaying the milestone name is partially overlapping the diamond resulting in a flicker when the mouse is positioned on the left of the diamond. Cause ===== Margin-bottom and margin-right are used in the style of popover. This has no effect on the positioning of the popover that relies on left/top properties. Fix === Those are replaced by negative top/left margins. task-3457106 Forward-Port-Of: odoo/odoo#131048
will get multiple company with multiple currency record as it will try to calculate multiple template cost currency field value. we need to do iteration for template record then it will resolve the error. Error has been introduced during upgrade. ``` File "/home/odoo/src/odoo/saas-16.4/addons/product/models/product_template.py", line 189, in _compute_cost_currency_id self.cost_currency_id = self.company_id.currency_id or self.env.company.currency_id.id File "/home/odoo/src/odoo/s
Original PR description
will get multiple company with multiple currency record as it will try to calculate multiple template cost currency field value. we need to do iteration for template record then it will resolve the…
will get multiple company with multiple currency record as it will try to calculate multiple template
cost currency field value. we need to do iteration for template record then it will resolve the error. Error has been introduced during upgrade.
```
File "/home/odoo/src/odoo/saas-16.4/addons/product/models/product_template.py", line 189, in _compute_cost_currency_id
self.cost_currency_id = self.company_id.currency_id or self.env.company.currency_id.id
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 1306, in __set__
self.write(protected_records, value)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3087, in write
cache_value = self.convert_to_cache(value, records)
File "/home/odoo/src/odoo/saas-16.4/odoo/fields.py", line 3010, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
ValueError: Wrong value for product.template.cost_currency_id: res.currency(2, 139)
```
Introduced by #116799
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#144488with this improvement now user can select the currency Chinese Yuan Offshore (CNH) and use it. my solution just adds the currency to the res_currency_data.xml opw-3599124 Forward-Port-Of: odoo/odoo#144331
Original PR description
with this improvement now user can select the currency Chinese Yuan Offshore (CNH) and use it. my solution just adds the currency to the res_currency_data.xml opw-3599124 Forward-Port-Of: odoo/odoo#144331
Before this commit, rtc join/leave sounds were played on every tab. This can be due to two issues: - notifications related to the current user should not play sound since it is already played by the tab that triggered the action. - only the main tab should play the sound. This commit implements this behavior. Steps to reproduce the issue: - Open two tabs - Start a call on the general channel - Notice that the "join" sound was played twice - Leave the call - The same applies for th
Original PR description
Before this commit, rtc join/leave sounds were played on every tab. This can be due to two issues: - notifications related to the current user should not play sound since it is already played by the tab that triggered the action. - only the main tab should play the sound. This commit implements this behavior. Steps to reproduce the issue: - Open two tabs - Start a call on the general channel - Notice that the "join" sound was played twice - Leave the call - The same applies for the "leave" sound task-3355352 Forward-Port-Of: odoo/odoo#144346 Forward-Port-Of: odoo/odoo#143987
**Current behavior before PR:** - Attempting to press the Enter key in the emoji picker when the search result was empty would lead to a traceback error. **Desired behavior after PR is merged:** - Now, Pressing Enter key in the emoji picker with an empty search result no longer triggers a traceback error. task-3576930 Forward-Port-Of: odoo/odoo#141451
Original PR description
**Current behavior before PR:** - Attempting to press the Enter key in the emoji picker when the search result was empty would lead to a traceback error. **Desired behavior after PR is merged:** - Now, Pressing Enter key in the emoji picker with an empty search result no longer triggers a traceback error. task-3576930 Forward-Port-Of: odoo/odoo#141451
Previously, if a tour was added to the registry after the tour service started, it would not be registered and could not be started. A previous PR ( https://github.com/odoo/odoo/pull/125055 ) fixed this behaviour, but did not auto-start the corresponding tour if needed. This commit fixes that. It also runs "auto" tours in exclusive mode, ie only one tour at a time, to prevent the check delay from being impacted by other tours which can lead to unwanted behaviour, especially with bootstra
Original PR description
Previously, if a tour was added to the registry after the tour service started, it would not be registered and could not be started. A previous PR ( https://github.com/odoo/odoo/pull/125055 ) fixed this behaviour, but did not auto-start the corresponding tour if needed. This commit fixes that. It also runs "auto" tours in exclusive mode, ie only one tour at a time, to prevent the check delay from being impacted by other tours which can lead to unwanted behaviour, especially with bootstrap modals, which are not immediately closable as soon as they start displaying, and can cause some test tours to fail. task-3377185 Forward-Port-Of: odoo/odoo#143112 Forward-Port-Of: odoo/odoo#125861
Description of the issue/feature this PR addresses: When registering for an event, the 'Register' button's enclosing form's `action` points to a JSON-only endpoint. However, actual usage delegates to a manual RPC call in Javascript, meaning that the action was never intended to be called directly by the browser. Task ID: 3501140 Closes #82942 Current behavior before PR: A race condition occurs between the 'Register' button being enabled, and the scripts being loaded meaning that i
Original PR description
Description of the issue/feature this PR addresses: When registering for an event, the 'Register' button's enclosing form's `action` points to a JSON-only endpoint. However, actual usage delegates to a manual RPC call in Javascript, meaning that the action was never intended to be called directly by the browser. Task ID: 3501140 Closes #82942 Current behavior before PR: A race condition occurs between the 'Register' button being enabled, and the scripts being loaded meaning that if the user is fast enough (or on a sufficiently slow device) can force a form-submit to the non-conforming endpoint, causing a 400. Desired behavior after PR is merged: This PR nullifies the form's default action and delegates entirely to Javascript, preventing the browser from submitting the form as-is. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139765
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a unicode string like http:/localhost/vi/xin-chào, http:/localhost/ru/привет, a error should occur at werkzeug._compat.wsgi_decoding_dance() because the path was not latin1 string. The utf-8 encoding followed by a latin-1 decoding is required by the WSGI specification[^1]. latin-1 is used as an e
Original PR description
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a…
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a unicode string like http:/localhost/vi/xin-chào, http:/localhost/ru/привет, a error should occur at werkzeug._compat.wsgi_decoding_dance() because the path was not latin1 string. The utf-8 encoding followed by a latin-1 decoding is required by the WSGI specification[^1]. latin-1 is used as an encoding passthrought: that encoding has a representation for all the 256 bytes, i.e. it is impossible that decoding a text will raise a ValueError. The WSGI spec uses this trick to save values until the actual charset (present in the Content-Type header) in known. [^1]: https://peps.python.org/pep-3333/#a-note-on-string-types X-original-commit: 81e0f23 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#143234
Because the class was imported in this file, unittest was discovering it again and was running the TestHttpStatic cases twice: once because of its inclusion in the test_static.py file, once more because of its inclusion in the test_web_server.py file. Changing the import solved the problem, since it is a python module object that is now exposed and not test case classes, unittest doesn't discover the classes. Description of the issue/feature this PR addresses: Current behavior before PR
Original PR description
Because the class was imported in this file, unittest was discovering it again and was running the TestHttpStatic cases twice: once because of its inclusion in the test_static.py file, once more because of its inclusion in the test_web_server.py file. Changing the import solved the problem, since it is a python module object that is now exposed and not test case classes, unittest doesn't discover the classes. 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#143752
pos*: pos_online_payment, pos_sale, pos_self_order Prior to this commit, different tests were using the demo data to run which was causing problems when the demo data were not installed. In this commit, we add products, categories, floor, table, etc. at the setup of the test so that the test can run without demo data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141958
Original PR description
pos*: pos_online_payment, pos_sale, pos_self_order Prior to this commit, different tests were using the demo data to run which was causing problems when the demo data were not installed. In this commit, we add products, categories, floor, table, etc. at the setup of the test so that the test can run without demo data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141958
opw-3608438
Original PR description
opw-3608438
Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be helpful in some cases, there should be a way to opt-out of the this automatic overwrite and to have a more flexible way to do those predictions. Here is how this is now possible: 1. With `disable_onchange_name_predictive` one can indicate their desire to opt-out of the prediction over
Original PR description
Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be…
Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be helpful in some cases, there should be a way to opt-out of the this automatic overwrite and to have a more flexible way to do those predictions. Here is how this is now possible: 1. With `disable_onchange_name_predictive` one can indicate their desire to opt-out of the prediction overwrite (i.e. the default behavior). 2. They can then use the `_predict_product`, `_predict_account`, `_predict_taxes` methods to create their own way of prediction. Placeholders for those were created to allow their use even if the prediction module isn't present. NB: As the module in charge of predictions (`account_accountant`) is not always installed the `edi_prediction_enabled` context key is used to indicate whether the prediction methods can be used or not. In the case of this fix, the key is setup in the `l10n_it_reports` module, as this module is always installed if `account_accountant` and `l10n_it` are installed. This way of predicting is useful for cases demanding a less generic approach to prediction. e.g. For the Italian EDI module the account of a line can be predicted without any limitation as it is not a value imported by the EDI. Whereas, its product and taxes should be predicted only if none were imported. opw-3201391 opw-3172035 Enterprise PR: https://github.com/odoo/enterprise/pull/51901 Forward-Port-Of: odoo/odoo#144347 Forward-Port-Of: odoo/odoo#115072
Versions: --------- - 15.0+ Steps to reproduce: ------------------- 1. Have multiple languages and Studio enabled; 2. create an event template; 3. add a question; 4. add translation to question; 5. use template to create event. Issue: ------ Translation doesn't get copied from template to event. Cause: ------ The `_compute_question_ids` method copied the questions by *manually* recreating them. It didn't use the `copy_translations` method like the regular `copy` methods does
Original PR description
Versions: --------- - 15.0+ Steps to reproduce: ------------------- 1. Have multiple languages and Studio enabled; 2. create an event template; 3. add a question; 4. add translation to question; 5. use template to create event. Issue: ------ Translation doesn't get copied from template to event. Cause: ------ The `_compute_question_ids` method copied the questions by *manually* recreating them. It didn't use the `copy_translations` method like the regular `copy` methods does. The reason the questions were recreated is because question records cannot link directly from event template to event, as changes to the event shouldn't affect the template. Solution: --------- Use the `copy` method instead while setting `event_type_id` to `False` to satisfy the restriction. opw-3572599 Forward-Port-Of: odoo/odoo#144408 Forward-Port-Of: odoo/odoo#141041
**Current behavior before PR:** Pressing Enter after selecting text does not remove the selected text. **Desired behavior after PR is merged:** Now pressing enter after selecting text removes text. task-3541359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137853
Original PR description
**Current behavior before PR:** Pressing Enter after selecting text does not remove the selected text. **Desired behavior after PR is merged:** Now pressing enter after selecting text removes text. task-3541359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137853
This commit addresses an issue where archived product variants were taking precedence over active variants with the same combination, rendering the combination unusable in the sales app. Steps to reproduce: 1. Install Sale & enable product variants 2. Create a product with two attributes, each having two values 3. Make a sale for each variant 4. Remove one of the attributes and save 5. Add back the same attribute with only one of the values 6. Make a new quote with the product; Option i
Original PR description
This commit addresses an issue where archived product variants were taking precedence over active variants with the same combination, rendering the combination unusable in the sales app. Steps to reproduce: 1. Install Sale & enable product variants 2. Create a product with two attributes, each having two values 3. Make a sale for each variant 4. Remove one of the attributes and save 5. Add back the same attribute with only one of the values 6. Make a new quote with the product; Option is not available. After this commit: Archived variants will no longer exclude a combination if an active variant with the same combination exists. opw-3538366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143655 Forward-Port-Of: odoo/odoo#138481
Before this commit, there was a problem when you were offline and had a draft order. If you tried to validate a new order while offline, the system would crash. This happened because the 'sendOrderInPreparation' function, called inside the 'onWillStart', would error out due to no internet connection, stopping the whole rendering process. To fix this, I've added a try/catch around 'sendOrderInPreparation' call. opw-3608162 --- I confirm I have signed the CLA and read the PR guidelines a
Original PR description
Before this commit, there was a problem when you were offline and had a draft order. If you tried to validate a new order while offline, the system would crash. This happened because the 'sendOrderInPreparation' function, called inside the 'onWillStart', would error out due to no internet connection, stopping the whole rendering process. To fix this, I've added a try/catch around 'sendOrderInPreparation' call. opw-3608162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144419
[FIX] hr_referral: Correct referral leaks Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position interviewer - As this user go to the recruitment app - You can see the applicant and you can open it Expected behavior: in that situation the user should not be able to see the applicant or access it in any way in the recruitment app. Explanation: The
Original PR description
[FIX] hr_referral: Correct referral leaks Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the…
[FIX] hr_referral: Correct referral leaks Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position interviewer - As this user go to the recruitment app - You can see the applicant and you can open it Expected behavior: in that situation the user should not be able to see the applicant or access it in any way in the recruitment app. Explanation: The user was able to see the applicant because the my referral view is based on the hr.applicant model and thus the user has access to the record in both apps. But the problem should be fixed in the recruitment app because the user should still be able to see the applicant in the referral app. after this fix: You'll not be able to see the applicant in the recruitment app if you are not the interviewer of the applicant or the interviewer of the job position if you only have the interviewer rights. You'll also get an access error if you try to access the applicant directly by URL. task-3457405 Forward-Port-Of: odoo/enterprise#45895
**Steps:** - Open timesheet - Start the timer in Grid View - Select a Project and Task **Issue:** - When the task is selected, the timer is shifted to that particular project and task in the row beneath, but the task field is emptied. **Cause:** - The onTimesheetChanged() function is triggered again before the save function triggers. This is because the function doesn't wait until the task record is saved. **Fix:** - adding await before the save function of the timesheet **Task
Original PR description
**Steps:** - Open timesheet - Start the timer in Grid View - Select a Project and Task **Issue:** - When the task is selected, the timer is shifted to that particular project and task in the row beneath, but the task field is emptied. **Cause:** - The onTimesheetChanged() function is triggered again before the save function triggers. This is because the function doesn't wait until the task record is saved. **Fix:** - adding await before the save function of the timesheet **Task:** 3378510 Forward-Port-Of: odoo/enterprise#43031