Monday, December 11, 2023
31 changes · 17.0
Resolved issues and error corrections
Users can now cancel while attaching a receipt to an expense without triggering an error. This prevents an unnecessary interruption in the expense workflow and keeps the existing expense record usable.
Original PR description
This traceback arises when the user tries to attach a receipt in the expense To reproduce this issue: 1) Install `hr_expense` 2) Open any existing `my expense` record 3) Click on the `Attach Receipt`…
This traceback arises when the user tries to attach a receipt in the expense
To reproduce this issue:
1) Install `hr_expense`
2) Open any existing `my expense` record
3) Click on the `Attach Receipt` button and attach a file
4) Now again attach a file through the `Attach Receipt` button
5) Now this time click on `cancel` while attaching a file through `Attach Receipt`
Error:-
```
IndexError: list index out of range
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/hr_expense/models/hr_expense.py", line 484, in attach_document
self.message_main_attachment_id = kwargs['attachment_ids'][-1]
```
When the user clicks on the `cancel` button when trying to attach a file,
the `kwargs` returns an empty `attchemnt_ids` record.
This leads to the above traceback from here
https://github.com/odoo/odoo/blob/5d00b4146aa5cc1942d66e60dc92d321f79bf891/addons/hr_expense/models/hr_expense.py#L482-L484
sentry-4705156379This fix ensures the website editor correctly reads modern CSS color formats and shows the right selected color in the color picker. It prevents confusion when editing borders or other styled elements that use transparent or advanced color values.
Original PR description
This commit introduces a parser to enable support for functional color notation in CSS. It adheres to the specifications outlined in the CSS 'color()' function as described in the official documentation (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color). This new feature accommodates various color spaces utilized within the 'color()' CSS function, seamlessly converting them into an RGBA format that is comprehensible to the right panel. Steps to reproduce: - Enter edit mode - Add a snippet with a column - Click on the column - Set border-width to 5px, enter => A gray border appears but the option colorpicker shows no color Since [this commit] the border has as default opacity of 15%. But now the custom color in the colorpicker is correctly set. [this commit]: https://github.com/odoo-dev/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e task-3536051 @SergeBayet
The accounting Send & Print wizard was simplified by removing outdated cancel-handling code that is no longer needed after a previous internal change. This reduces unnecessary complexity and helps keep the invoicing workflow easier to maintain without changing day-to-day user behavior.
Original PR description
In Send & Print refactoring : part 1 (https://github.com/odoo/odoo/commit/33625269062d50e52fe2e0d8cf4a6df788e93062) we changed the wizard back to a transient model, making the special handling of the cancel useless therefore the custom form is now irrelevant.
The calendar view now checks that it is still available before trying to automatically scroll to a time slot. This prevents an occasional error message when users quickly apply a Knowledge template that includes a calendar.
Original PR description
In the `onMounted` hook of the calendar renderer, the given callback function will schedule a new function call using `setTimeout` with a delay of 0 if some conditions are satisfied. The scheduled…
In the `onMounted` hook of the calendar renderer, the given callback function will schedule a new function call using `setTimeout` with a delay of 0 if some conditions are satisfied. The scheduled function will then trigger a scroll in the calendar view to display a precise timeslot. If the component is destroyed before the scheduled function is executed, the scheduled function may trigger an error as the root element of the calendar will be removed from the DOM when the component is destroyed. This commit will fix that issue by checking that the root element of the calendar exists before calling the `scrollToTime` function. Steps to reproduce the error: 1. Open Knowledge 2. Open the template gallery 3. Select the template "Sprint Calendar" 4. Quickly apply the template => If you have the right timing: a traceback will be displayed indicating that the function `scrollToTime` is not defined on `null`. TO BE: No traceback should be displayed when applying the template. task-3627780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue in the List View Editor where setting a field to read-only would incorrectly trigger automatic saving. The "force_save" feature is now properly limited to form views only, where it's intended to be used. This prevents unintended automatic saves when editing list view configurations.
Original PR description
Before this commit: When editing a list view and setting a field's readonly attribute to true, "force_save" would be set to true while this should only be the case in the form view. After this commit: The "force_save" attribute is now only set in form view. Task: [3284910](https://www.odoo.com/mail/view?model=project.task&res_id=3284910&access_token=1e9b0d2e-0712-472c-8db8-f86e7f6287e9) Forward-Port-Of: odoo/enterprise#46471 Forward-Port-Of: odoo/enterprise#41783
The helpdesk SLA status analysis graph was displaying confusing random numbers next to legend labels (e.g., "SLA Failed /1"). This fix removes those extraneous numbers, making the graph legend clearer and easier to understand for users reviewing SLA performance data.
Original PR description
Before this PR when we see sla status analysis graph view it was showing random numbers shown by legend (SLA Failed /1 ). In this PR we have fixed that issue and made it as SLA Failed. task-3484150 Forward-Port-Of: odoo/enterprise#47057
Miscellaneous changes
# Issue: The _predicted_field is still slow after refactor. # Analyze: Due to the refactor of the query made in account_move.py _predicted_field, an index is needed on partner_id. # Fix: Add an index on partner_id Many2One. # Note: The previous PR has already been merged https://github.com/odoo/enterprise/pull/50911 but without the index it is not as fast as expected. This index had been added by hand. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:-----
Original PR description
# Issue: The _predicted_field is still slow after refactor. # Analyze: Due to the refactor of the query made in account_move.py _predicted_field, an index is needed on partner_id. # Fix: Add an index on partner_id Many2One. # Note: The previous PR has already been merged https://github.com/odoo/enterprise/pull/50911 but without the index it is not as fast as expected. This index had been added by hand. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 30M | 22.827 s | 18.59 ms| # Related task: opw-3539632 Forward-Port-Of: odoo/odoo#145675 Forward-Port-Of: odoo/odoo#144534
Description of the issue/feature this PR addresses: Change the accuracy of https://github.com/odoo/odoo/blob/2c5ce41c423e6ab92053b1f082086035bdc151f8/addons/product/data/product_data.xml#L37 Current behavior before PR: The accuracy of Min. Quantity of pricelist rules does not change Desired behavior after PR is merged: The accuracy of Min. Quantity of pricelist rules is changed EDIT: same with field `product.supplierinfo.min_qty` (https://github.com/odoo/odoo/blob/3363e55cac2a121c29
Original PR description
Description of the issue/feature this PR addresses: Change the accuracy of https://github.com/odoo/odoo/blob/2c5ce41c423e6ab92053b1f082086035bdc151f8/addons/product/data/product_data.xml#L37 Current behavior before PR: The accuracy of Min. Quantity of pricelist rules does not change Desired behavior after PR is merged: The accuracy of Min. Quantity of pricelist rules is changed EDIT: same with field `product.supplierinfo.min_qty` (https://github.com/odoo/odoo/blob/3363e55cac2a121c29842a0b2463f940bdd866a4/addons/product/models/product_supplierinfo.py#L45), noticed thanks to https://github.com/odoo/odoo/pull/145191#pullrequestreview-1771801838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145191
The aim of this commit is to fix runbot build error. Before the commit: The test could fail if the EUR currency was inactive After the commit: The test activate the currency first runbot-error-build: 51509 Forward-Port-Of: odoo/odoo#145752
Original PR description
The aim of this commit is to fix runbot build error. Before the commit: The test could fail if the EUR currency was inactive After the commit: The test activate the currency first runbot-error-build: 51509 Forward-Port-Of: odoo/odoo#145752
Before this commit: The readonly modifier of the statusbar field was not taken into account, only the "clickable" option was. After this commit: The readonly modifier is now taken into account if the "clickable" option is set to true. I used `this.props.record.isReadonly` and not `props.readonly` to mimick the behaviour of other toggle fields (still editable in readonly mode). Task: [3222998](https://www.odoo.com/mail/view?model=project.task&res_id=3222998&access_token=4820c58b-29b2-4
Original PR description
Before this commit: The readonly modifier of the statusbar field was not taken into account, only the "clickable" option was. After this commit: The readonly modifier is now taken into account if the "clickable" option is set to true. I used `this.props.record.isReadonly` and not `props.readonly` to mimick the behaviour of other toggle fields (still editable in readonly mode). Task: [3222998](https://www.odoo.com/mail/view?model=project.task&res_id=3222998&access_token=4820c58b-29b2-444d-9c3f-9f169aafcc20) Related to https://github.com/odoo/odoo/pull/123668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145057 Forward-Port-Of: odoo/odoo#123880
Currently Team Expense Approver have full access to journal, we shouldn't do that --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143993 Forward-Port-Of: odoo/odoo#143277
Original PR description
Currently Team Expense Approver have full access to journal, we shouldn't do that --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143993 Forward-Port-Of: odoo/odoo#143277
Steps: - Install timesheet_grid. - Start the timer. - Try to add new task without selecting project. Issue: - We can create a new task and afterwards the task would have the projects as private. Fix: - We are taking the canCreateEdit option from props. task-3378532 Forward-Port-Of: odoo/odoo#145714 Forward-Port-Of: odoo/odoo#145184
Original PR description
Steps: - Install timesheet_grid. - Start the timer. - Try to add new task without selecting project. Issue: - We can create a new task and afterwards the task would have the projects as private. Fix: - We are taking the canCreateEdit option from props. task-3378532 Forward-Port-Of: odoo/odoo#145714 Forward-Port-Of: odoo/odoo#145184
Since the update in https://github.com/odoo/odoo/commit/d4b366f2d741f2087a947d61d7e0618492cc2bf1, the POS loyalty program stopped printing customer names on receipts for transactions without points won or spent. Originally, printing a loyalty program also included the customer's name, which users relied on to print the customer's name on receipts. This commit ensures the customer's name is printed on the receipt, regardless of whether any loyalty points were won or spent. opw-3620536 --
Original PR description
Since the update in https://github.com/odoo/odoo/commit/d4b366f2d741f2087a947d61d7e0618492cc2bf1, the POS loyalty program stopped printing customer names on receipts for transactions without points won or spent. Originally, printing a loyalty program also included the customer's name, which users relied on to print the customer's name on receipts. This commit ensures the customer's name is printed on the receipt, regardless of whether any loyalty points were won or spent. opw-3620536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144521
Steps to reproduce: - Decimal Accuracy for Product Price > 4 digits - Purchase a product using a price (1.2345 in my example) - Go to Purchase > Reporting - Enable the List View - Add the field Average Cost (price_average) - This displays as just two decimals Note: can be edited with studio but you can just add the field "price_average" to the "purchase_report_view_tree" view xml Fix: round using product price Accuracy opw-3560792 Forward-Port-Of: odoo/odoo#145006
Original PR description
Steps to reproduce: - Decimal Accuracy for Product Price > 4 digits - Purchase a product using a price (1.2345 in my example) - Go to Purchase > Reporting - Enable the List View - Add the field Average Cost (price_average) - This displays as just two decimals Note: can be edited with studio but you can just add the field "price_average" to the "purchase_report_view_tree" view xml Fix: round using product price Accuracy opw-3560792 Forward-Port-Of: odoo/odoo#145006
Release notes: https://github.com/odoo/owl/releases Commits: - [IMP] types: correctly support Function type for props-validation - [IMP] app: allow to instantiate templates lazily - [FIX] compiler: compile named slot in t-component in named slot - [IMP] devtools: update the devtools documentation - [IMP] owl-vision: syntax scripts, single quotes attributes and slot props highlight and switch below command - [IMP] doc: improve documentation of useExternalListener - [FIX] devtools: remo
Original PR description
Release notes: https://github.com/odoo/owl/releases Commits: - [IMP] types: correctly support Function type for props-validation - [IMP] app: allow to instantiate templates lazily - [FIX] compiler: compile named slot in t-component in named slot - [IMP] devtools: update the devtools documentation - [IMP] owl-vision: syntax scripts, single quotes attributes and slot props highlight and switch below command - [IMP] doc: improve documentation of useExternalListener - [FIX] devtools: remove highlights when out of devtools - [IMP] devtools: highlight component on select - [ADD] owl-vision: vscode extension initial commit Forward-Port-Of: odoo/odoo#145342 Forward-Port-Of: odoo/odoo#145236
When getting a domain from activeFields in Owl, sometimes the value passed is not a list or function. When the field mentioned have a `check_company=True` in the initialization, the domain passed will be in a form of string instead of a list. This commit aims to publicize the domain handler in Field so that it can be used anywhere by calling the function, as getting field's domain is getting increasingly common related enterprise-PR: https://github.com/odoo/enterprise/pull/49456 task
Original PR description
When getting a domain from activeFields in Owl, sometimes the value passed is not a list or function. When the field mentioned have a `check_company=True` in the initialization, the domain passed will be in a form of string instead of a list. This commit aims to publicize the domain handler in Field so that it can be used anywhere by calling the function, as getting field's domain is getting increasingly common related enterprise-PR: https://github.com/odoo/enterprise/pull/49456 task-id: 3549961 Forward-Port-Of: odoo/odoo#140773
Before this commit, if a new order was created with an existing pos_reference, it would not be captured even though it was a completely new order. This occurred because pos_reference was assumed to be unique. However, there have been several customer reports of orders not being captured when the receipt contains a pos_reference that already exists. Some bugs causing duplicate pos_references were found but the root cause remains unclear. With this commit, orders are now synced even if pos_r
Original PR description
Before this commit, if a new order was created with an existing pos_reference, it would not be captured even though it was a completely new order. This occurred because pos_reference was assumed to be unique. However, there have been several customer reports of orders not being captured when the receipt contains a pos_reference that already exists. Some bugs causing duplicate pos_references were found but the root cause remains unclear. With this commit, orders are now synced even if pos_reference matches a previous order. This prevents lost orders and allows customers to access all their receipts via pos_reference lookup. An investigation into the cause of duplicate pos_references needs to continue, but this change unblocks the more serious issue of missing orders. opw-3499011 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134891
Previously, products loaded from the background included the internal reference in their displayed name. This behavior was due to the 'display_default_code' context, which prevents the inclusion of 'default_code' in the product name, not being utilized within the 'get_pos_ui_product_product_by_params' function. opw-3617195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144204
Original PR description
Previously, products loaded from the background included the internal reference in their displayed name. This behavior was due to the 'display_default_code' context, which prevents the inclusion of 'default_code' in the product name, not being utilized within the 'get_pos_ui_product_product_by_params' function. opw-3617195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144204
- refund tax repartition lines lack tax grids -> added - Outgoing credit notes lack base line grids -> should decrease total active transactions -> added. - Purchase taxes 0% G and 0% S should increase total passive transactions, not increase total active transactions -> fixed Task link: https://www.odoo.com/web#id=3175384&model=project.task task-3175384 Forward-Port-Of: odoo/odoo#145381 Forward-Port-Of: odoo/odoo#120928
Original PR description
- refund tax repartition lines lack tax grids -> added - Outgoing credit notes lack base line grids -> should decrease total active transactions -> added. - Purchase taxes 0% G and 0% S should increase total passive transactions, not increase total active transactions -> fixed Task link: https://www.odoo.com/web#id=3175384&model=project.task task-3175384 Forward-Port-Of: odoo/odoo#145381 Forward-Port-Of: odoo/odoo#120928
Issue: ====== Attachment files aren't sent with the event invitation email. Steps to reproduce the issue: ============================= - Add any attachment to the email template : `Calendar: Meeting Invitation` and save it. - Go to website and book an appointment. - Go to Scheduled Actions and run manually email queue manager to send the notification. - The sent email doesn't have the attachement you provided, it has only 1 attachement which is the calendar one. Origin of the issu
Original PR description
Issue: ====== Attachment files aren't sent with the event invitation email. Steps to reproduce the issue: ============================= - Add any attachment to the email template : `Calendar: Meeting Invitation` and save it. - Go to website and book an appointment. - Go to Scheduled Actions and run manually email queue manager to send the notification. - The sent email doesn't have the attachement you provided, it has only 1 attachement which is the calendar one. Origin of the issue: ==================== The notification of the event invitation was taking only the calendar as attachment and ignores the template attachemnt. Solution: ========== Now the calendar event invitation email will take into account the attachment of the email_template. opw-3593140 Forward-Port-Of: odoo/odoo#145403 Forward-Port-Of: odoo/odoo#144002
Create an invoice Send&Print Uncheck 'Generate Facturae edi file' Send Email will be send with only pdf invoice Create 2+ invoices In list view select both, Actions>Send Uncheck 'Generate Facturae edi file' Send Issue: Email will be send with pdf invoice and xml document This occurs because we don't propagate the selection in mass mail mode opw-3530043 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Create an invoice Send&Print Uncheck 'Generate Facturae edi file' Send Email will be send with only pdf invoice Create 2+ invoices In list view select both, Actions>Send Uncheck 'Generate Facturae edi file' Send Issue: Email will be send with pdf invoice and xml document This occurs because we don't propagate the selection in mass mail mode opw-3530043 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#142745
Steps to reproduce: ------------------- - on ecommerce, activate "Extra Info" feature; - go to the extra info form; - write something for "Your Reference"; - press Enter. Issue: ------ The Bad Request message is displayed. Cause: ------ Pressing Enter triggers the form's default submit. To use the controller of the `/website/form/shop.sale.order` route, we need to apply the JS logic of the `s_website_form` widget (the `send` function). Solution: --------- Add an event for the
Original PR description
Steps to reproduce: ------------------- - on ecommerce, activate "Extra Info" feature; - go to the extra info form; - write something for "Your Reference"; - press Enter. Issue: ------ The Bad Request message is displayed. Cause: ------ Pressing Enter triggers the form's default submit. To use the controller of the `/website/form/shop.sale.order` route, we need to apply the JS logic of the `s_website_form` widget (the `send` function). Solution: --------- Add an event for the `submit` which will prevent the default behaviour and send the form data. opw-3591135 Forward-Port-Of: odoo/odoo#145495 Forward-Port-Of: odoo/odoo#142328
Current behaviour: --- When checking the overview of a normal BoM, the product is available if component is in stock Expected behaviour: --- The product should not be available unless BoM type is kit Steps to reproduce: --- 1. Go to Manufacturing 2. Go to Products > Bills of Materials 3. Create a new BoM 4. Product: p1 (and create product p1) 5. Component: p2 (and create product p2) 6. BoM type: Manufacture this product (normal) 7. Save the BoM 8. Click on Overview 9. p1 and
Original PR description
Current behaviour: --- When checking the overview of a normal BoM, the product is available if component is in stock Expected behaviour: --- The product should not be available unless BoM type is kit…
Current behaviour: --- When checking the overview of a normal BoM, the product is available if component is in stock Expected behaviour: --- The product should not be available unless BoM type is kit Steps to reproduce: --- 1. Go to Manufacturing 2. Go to Products > Bills of Materials 3. Create a new BoM 4. Product: p1 (and create product p1) 5. Component: p2 (and create product p2) 6. BoM type: Manufacture this product (normal) 7. Save the BoM 8. Click on Overview 9. p1 and p2 are not available (Normal behavior) 10. Go to the p2 product page 11. Click on Update Quantity > new quantity > Apply all 12. Go back to the p1 BoM 13. Click on Overview 14. p1 and p2 are available 15. p1 should only be available if BoM type is kit Cause of the issue: --- Caused by https://github.com/odoo/odoo/commit/f13b4d1ae8c12a1668222e6994dea26a27c6f5d4 opw-3601298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145108 Forward-Port-Of: odoo/odoo#143421
In Accounting settings set 'Cash Discount Tax Reduction' to Always Create an invoice Add a line with tax Add as payment terms "2/7 Net 30" Confirm Click "Add a credit note" and create the credit note Confirm Issue: Credit note is missing the epd vals from the invocie so the moves cannot fully reconcile opw-3429678 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 an
Original PR description
In Accounting settings set 'Cash Discount Tax Reduction' to Always Create an invoice Add a line with tax Add as payment terms "2/7 Net 30" Confirm Click "Add a credit note" and create the credit note Confirm Issue: Credit note is missing the epd vals from the invocie so the moves cannot fully reconcile opw-3429678 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#145477 Forward-Port-Of: odoo/odoo#131092
Applied fixes: - a lot of translations were outdated, not matching official ones - box 205 was missing - box 289 had translation of missing box 205 - box 200 had translation of the section - boxes 381a and 381b removed, completely outdated: we already removed all other 3X1 boxes. - boxes 200,299,479 had wrong computation - reordering lines to match the report Source: https://www.estv.admin.ch/estv/fr/accueil/taxe-sur-la-valeur-ajoutee/decompter-tva/formulaires-tva.html task-3349511
Original PR description
Applied fixes: - a lot of translations were outdated, not matching official ones - box 205 was missing - box 289 had translation of missing box 205 - box 200 had translation of the section - boxes 381a and 381b removed, completely outdated: we already removed all other 3X1 boxes. - boxes 200,299,479 had wrong computation - reordering lines to match the report Source: https://www.estv.admin.ch/estv/fr/accueil/taxe-sur-la-valeur-ajoutee/decompter-tva/formulaires-tva.html task-3349511 Forward-Port-Of: odoo/odoo#144880 Forward-Port-Of: odoo/odoo#129717
If you have the backend in a language A but the website in English only, you can: 1) modify a record's (event, product...) name in language A (say "New Name"). 2) visit the page `/new-name-11` => the server will redirect you to the English page `/origin-11`, with the only slug that actually exists on the website. Chrome caches the redirection. 3) give the same name in English as in language A, try to visit => the server now wants to access `/new-name-11` => Chrome uses the cache to red
Original PR description
If you have the backend in a language A but the website in English only, you can: 1) modify a record's (event, product...) name in language A (say "New Name"). 2) visit the page `/new-name-11` => the…
If you have the backend in a language A but the website in English only, you can:
1) modify a record's (event, product...) name in language A (say "New Name").
2) visit the page `/new-name-11` => the server will redirect you to the English page `/origin-11`, with the only slug that actually exists on the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
At the time of this commit, the flow described here should be expected of users, because the translation UI in the backend is not clear: the default field displayed is in language A event though the website does not use it, and the way to update translations is not obvious (you have to click on the language tag, which doesn't look like a button).
After this commit, if we detect that behavior, we reload the iframe with a new query parameter, making the URL brand-new for Chrome.
opw-3479651
Forward-Port-Of: odoo/odoo#142577Steps: - Open sales. - Go to products. - Create a new product. - Keep the 'Can be sold' option unchecked. Issue: - If a product is not sellable then the user should not be able to create invoicing policy 'Based on Timesheets' or 'Based on Milestones'. Fix: - We are raising the user error 'This option is only for sellable products.' when a user tries to select any of these two options. task-3378532 Forward-Port-Of: odoo/odoo#144751 Forward-Port-Of: odoo/odoo#126531
Original PR description
Steps: - Open sales. - Go to products. - Create a new product. - Keep the 'Can be sold' option unchecked. Issue: - If a product is not sellable then the user should not be able to create invoicing policy 'Based on Timesheets' or 'Based on Milestones'. Fix: - We are raising the user error 'This option is only for sellable products.' when a user tries to select any of these two options. task-3378532 Forward-Port-Of: odoo/odoo#144751 Forward-Port-Of: odoo/odoo#126531
Following fdb692c25b50: - when creating/unarchiving an employee, we should only create global time-off of the same company as the employee itself - when computing the working hours relative to the GTO, if we had both calendar GTO and company GTO (not linked to a specific calendar), we were not correctly creating calendar GTO; we should merge those intervals intead of company GTO interval simply overwriting calendar GTO intervals Task-Id: 3619083 --- I confirm I have signed the CLA
Original PR description
Following fdb692c25b50: - when creating/unarchiving an employee, we should only create global time-off of the same company as the employee itself - when computing the working hours relative to the GTO, if we had both calendar GTO and company GTO (not linked to a specific calendar), we were not correctly creating calendar GTO; we should merge those intervals intead of company GTO interval simply overwriting calendar GTO intervals Task-Id: 3619083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144573
Steps: - Open Project - Go to Tasks > My Tasks or All Tasks - Create New Task - Create Project from Quick Create - Clicking on Save, will give a Validation Error Issue: - Validation Error is raised and thus, we aren't able to add the project and thus create a task. Cause: - Due to the addition of context, the default_type_ids isn't obtained, and thus the SQL error occurs as the name of the task stage isn't set which is a mandatory field. Fix: - removing the context from the for
Original PR description
Steps: - Open Project - Go to Tasks > My Tasks or All Tasks - Create New Task - Create Project from Quick Create - Clicking on Save, will give a Validation Error Issue: - Validation Error is raised and thus, we aren't able to add the project and thus create a task. Cause: - Due to the addition of context, the default_type_ids isn't obtained, and thus the SQL error occurs as the name of the task stage isn't set which is a mandatory field. Fix: - removing the context from the form view of Quick Create Task: 3378510 Forward-Port-Of: odoo/odoo#125857
When a tour fails, the tour system is supposed to log the failing step (with the 3 previous/next steps). Before this commit, this didn't work, and the first 3 steps were always logged, no matter which step failed. This didn't work because to determine the failing step, we try to find the step from the list of steps, with reference matching (steps are objects). However, since [1], steps are obtained from a getter which calls the steps function of the tour, so they always get a new version o
Original PR description
When a tour fails, the tour system is supposed to log the failing step (with the 3 previous/next steps). Before this commit, this didn't work, and the first 3 steps were always logged, no matter…
When a tour fails, the tour system is supposed to log the failing step (with the 3 previous/next steps). Before this commit, this didn't work, and the first 3 steps were always logged, no matter which step failed. This didn't work because to determine the failing step, we try to find the step from the list of steps, with reference matching (steps are objects). However, since [1], steps are obtained from a getter which calls the steps function of the tour, so they always get a new version of the steps. This commit fixes the issue by memoizing the steps, such that the function is called only once, and we keep the same references to the step objects. Note that this could be reworked in master to make it more robust (e.g. finding steps based on ids). [1] https://github.com/odoo/odoo/commit/81be42d8f9421e796087325c99aa4289d3912352 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#145273
Forward-Port-Of: odoo/odoo#145192
Original PR description
Forward-Port-Of: odoo/odoo#145192