Friday, February 24, 2023
54 changes · master
New functionality added to Odoo
This change adds a demo express checkout flow so businesses can preview and test the customer checkout experience without configuring a real payment provider. It helps teams understand how express checkout works in website sales and delivery scenarios before going live.
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
Enhancements to existing features
The state selection dropdown now keeps the current choice visible in the list and marks it with a checkmark. This makes the control clearer and removes the need for an unintuitive tooltip, improving day-to-day usability for users changing statuses.
Original PR description
This commit revamps the UX of the StateSelection field widget. Now, instead of filtering the options by removing the current selected value, the field displays the entire list in the dropdown, and the selected item has a checkmark to indicate its status. This allows us to remove the tooltip, since its presence was not useful anymore, and was unintuitive to use. This changes required to adapt some tests asserting its presence, as well as the number of items shown in the dropdown menu. task #3177182
Resolved issues and error corrections
Weekly filters now start on the correct day for the user's language and country settings, such as Sunday for U.S. English and Monday for Belgian French. This makes weekly views align with dashboard reporting and avoids confusing date ranges in business workflows like accounting bills.
Original PR description
Steps to reproduce: - Make sure language preference is 'en_US' - In accounting, in the dashboard click on bills - Filter 'due_date' by week Issue: The start day is Monday and should be, for 'en_US',…
Features or functions removed from Odoo
Odoo has removed the PayPal quick onboarding option from website payment settings because PayPal no longer allows merchants to receive payments without an account. Businesses using PayPal will now need to complete the standard account-based setup to accept payments.
Original PR description
PayPal no longer supports receiving payments without an account. task-3166217 See also: - https://github.com/odoo/upgrade/pull/4354
Code cleanup and technical improvements
This update reorganizes how Odoo’s web interface passes field display details to its field components. It supports future improvements to forms, lists, and kanban views, especially where the same field appears multiple times with different display rules, without changing visible behavior for users now.
Original PR description
Miscellaneous changes
 Forward-Port-Of: odoo/odoo#113308
Original PR description
 Forward-Port-Of: odoo/odoo#113308
The portal contact section now only shows phone and city/location icons when those details are actually available. This removes confusing empty indicators and makes customer contact information look cleaner and more accurate.
Original PR description
Description of the issue/feature this PR addresses: in portal, under your contact section, the icon of location/city and phone is displaying even when the city and phone doesn't have values. the pr will display the icons when the field have values in it. Current behavior before PR: the icons are showing without field values  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website blog styling has been simplified by removing custom CSS that made blog pages look inconsistent. Blog layouts now rely more on standard Bootstrap spacing, giving visitors a cleaner and more consistent reading experience.
Original PR description
Blogs had custom CSS style that were not beautiful; the standard bootstrap interlines is much better. Removing unnecessary CSS lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Expense processing now creates easier-to-track accounting documents depending on who paid: employee-paid expenses use purchase orders, while company-paid expenses create payment-like entries. This reduces confusion from hidden purchase receipts, avoids gaps in document sequences, and makes payment status easier to understand.
Original PR description
Rework of the hr.expense workflow so that: - expenses paid by employee generate purchase.order - expenses paid by company generate entry that look like payments Main reason being that purchase.receipt are not active by default. That makes the entry hard to find, holes in sequences, inconsitency with payment states. It also remove the refusal of expenses as this was dead / inaccessible code, only reports can be refused. task-id: 3126550 [community](https://github.com/odoo/odoo/pull/110518) [enterprise](https://github.com/odoo/enterprise/pull/36090)
The Argentine localization content has been moved from Spanish source text to English source text, with translations handled separately. This makes the localization easier to maintain consistently while preserving native-language support for users.
Original PR description
Before this PR, all this localisation was written in Spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that. task-id: 3179209 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Course section pages now display how many slides they contain and the estimated time needed to complete them, making it easier for learners to plan their progress. Time estimates from video and document providers are rounded up to full minutes, and course content can be searched with additional filters such as responsible person, course, and tags.
Original PR description
This commit intends to add information about the number of slides, as well as the time needed to finish said slides to the slide sections. We now also round completion time values up to minute when getting said values from Youtube, Google drive or Vimeo. Task-3054391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM lead generation buttons are now hidden in views where they are not relevant, reducing clutter and potential confusion for sales users. Some creation options are also disabled in these contexts to keep lead generation workflows focused and consistent.
Original PR description
Remove the "generate leads" buttons from most crm lead views: we do not show buttons if active_model is set to something else than crm.lead. It is both done in the kanban and in the list views. Some create are also set to False. Task-3107232
This update adds a demo express checkout flow so users can see how express checkout works without connecting a real payment provider. It helps sales and implementation teams demonstrate the payment experience more easily in demo environments.
Original PR description
Demo data without forms 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
Payment providers can now define extra transaction statuses only for the specific flows that need them, instead of applying those allowances across all providers. This reduces unnecessary flexibility in payment handling and helps make refunds and transactions behave more consistently by provider.
Original PR description
Some providers require additional allowed states due to their refund or transaction process justifying it. Until now, these extra states were specified in the `payment` module, which was not ideal as it allowed every provider in every flow to accept these additional states. With this commit, additional states are now specified only in the corresponding flow of a provider that requires them. task-2869678
Survey managers can now filter results using all question types, including text, number, date, and datetime answers. This makes it easier to narrow survey analysis to specific responses and get more relevant insights from completed surveys.
Original PR description
Purpose ======= Improve the results page filter to allow the filtering on questions of type text_box, char_box, numerical_box, date and datetime. Specifications ============== Updating the URL filters representation to avoid passing the question types directly in the URL parameters. Answer matching per question type: - char_box, text_box: 'ilike' - numerical_box, date, datetime: '=' Adding a new filter restricts the current filter results. Handling the filters depending on the 2 different answer models: 'survey.question.answer': matrix, simple_choice, multiple_choice 'survey.user_input.line': char_box, text_box, numerical_box, date, datetime. The filters can be combined but their query count doesn't add up if their related answers data are stored in the same model. Task-3138245
The web editor toolbar and command menu have been cleaned up and made easier to use, especially on mobile devices. The update fixes visual alignment, dropdown behavior, and related display issues in mass mailing so editing content is smoother across screen sizes.
Original PR description
Prior to this PR, there were unnecessary scss for the floating toolbar and the powerbox in the web editor. First commit also fixes some design issues like alignement for the icons in the list of the powerbox, box shadows, and the responsiveness of the floating toolbar on mobile. In commit [1], the toolbar dropdown had the display static added, but it causes problems to the responsiveness. 2th commit put the display back to dynamic on the dropdown and so, fixes the dropdown not showing on mobile because of the overflow-x on auto. The dynamic state also allows the dropdown to change direction (dropdown to dropup) when there's not enough space for the content of the dropdown. 3th commit adds IsMobile 4th commit uses isMobile on the all editor toolbars (frontend and backend) The layout of the toolbar, for mobile, is modified for a better behaviour and design. Prior to this, it's was a horizontal scroll. [1]: 459d4e27a860f3f0308ee0984de6f789baa65424 task-3087826
Appraisal survey results now work with the updated survey filtering experience. This helps users view and narrow appraisal feedback results consistently after the broader Survey changes.
Original PR description
Purpose ======= Updating the module to the new filter results modifications done in Survey. Specifications ============== Adapting the _get_results_page_user_input_domain method to handle the new search domain implementation. Task-3138245
Odoo now keeps the Amazon feed reference created when a delivery is confirmed and checks its final processing status. This helps users see whether Amazon synchronization succeeded or failed, so they can correct delivery information and resend it when needed.
Original PR description
With the Amazon Connector, confirming a delivery sends a so-called "feed" to Amazon. When the feed is created, Amazon responds to the request with only the feed id. It is then processed asynchronously by Amazon and its final status is never communicated by Amazon to Odoo, hence preventing the user from being aware of synchronization issues. Keeping the feed id allows us to query Amazon about its status and process it to know if the synchronization succeeded or not, to keep track of what happens to the picking, and inform the user that he needs to change something to his picking before sending the information back to Amazon should the need arises. task-2801067 See also: - https://github.com/odoo/upgrade/pull/4146 - https://github.com/odoo/documentation/pull/3193
The expense OCR sample workflow was simplified to match the updated expense process. Sample tests no longer create fake payments or accounting entries, reducing unnecessary complexity without changing day-to-day expense handling.
Original PR description
During refactoring of hr_expense (replacement of purchase receipt), we decided that there is no point in creating (fake) payments / moves while testing the OCR with expense samples. task-id: 3126550 [community](https://github.com/odoo/odoo/pull/110518)
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue:
The start day is Monday and should be, for 'en_US', Sunday as it is the case in the dashboard view in accounting (see appendix)
Cause:
The query uses the `date_trunc('week', date)` which in postgress retrieves the first day of the week as Monday.
Solution:
Create an offset in the query depending on the first day of the locale variable.
Note:
the `web/tests/test_read_progress_bar.py` has been modified: since the default language is 'en_US' there will be an offset of one day.
To make it less confusing, I used only two anglo-saxons countries so the day offset is not the variable tested.
(for this matter, pleaser refer to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
```
First day of the week as in Babel:
>>> import babel
>>> locale = babel.Locale('en', 'US')
>>> locale.first_week_day
6
>>> locale.days['format']['wide'][locale.first_week_day]
'Sunday'
>>> locale = babel.Locale('fr', 'BE')
>>> locale.first_week_day
0
>>> locale.days['format']['wide'][locale.first_week_day]
'lundi'
```
opw-2747066This fix limits extra record-specific information sent when forms load related data. It makes form loading behavior more consistent and prepares the web client for a future streamlined data-loading approach.
Original PR description
The form view currently reads its data as follows: 1) read the main record, which returns [id1, id2...] for x2manys and [id, display_name] for many2ones. 2a) read x2manys records, with the context…
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be evaluated (some placeholder values need to be replaced by actual values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record as eval context. For 3, there an additional key "parent" in the eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a single rpc, returning the main record and its related records, with all the values required by the UI. To achieve that, we must ensure that sub records are never read with a dynamic context depending on the parent record.
This commit thus directly imposes the limitation, by removing from the eval context the record related data when it is used to evaluate the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
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-prWork order blocking reasons in Manufacturing can now appear in the user's selected language. This improves clarity for multilingual teams and helps shop floor users understand why work is blocked.
Original PR description
Blocking reasons on workorders are not translatable, this fixes that. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Reports and views that group information by week now use the correct first day of the week for the user's locale. This makes weekly figures align with local business expectations and reduces confusion when comparing date-based results.
Original PR description
Companion of https://github.com/odoo/odoo/pull/93053
This commit is part of the preliminary work to rewrite the form, list and kanban model. We want this new Model to only be aware of field related information it needs (whereas in its current…
This commit is part of the preliminary work to rewrite the form, list and kanban model. We want this new Model to only be aware of field related information it needs (whereas in its current implementation, the model stores all the information extracted from the field node in the arch). This would allow to properly manage multiple occurrences of the same field in views, that is, each occurrence would be represented by a field component (if visible of course), and that field component would use the field information of the arch node it represents. To this end, we want fields from not using anymore information stored in activeFields in the record datapoint. Instead, we now call extractProps with the whole fieldInfo (the information extracted from the arch), s.t. each field can generate the props it needs from those information (e.g. sub views for x2manys). This commit doesn't remove the use of record.activeFields in concrete fields (this will come later), but reworks the fieldInfo object generated by parseFieldNode, and provide it to the calls of extractProps. In fieldInfo, the `options` key is no longer inside `attrs`, as it is now top-level, alongside several other generic keys that have been processed (like on_change, modifiers...). For that reason, a lot of extractProps definitions had to be adapted. Part of task 3179751
This update reorganizes product attribute code into smaller, clearer files without changing product behavior. It helps make future maintenance and improvements to product configuration easier and safer for the development team.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reorganizes how dynamic placeholders are handled in emails and editor fields, making the feature easier to maintain without changing the main user workflow. It also adds automated checks for the placeholder dropdown to help prevent future regressions.
Original PR description
Refactor the Dynamic Placeholder hook to have better separation of concern from the Field that need it. task-3081325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This internal cleanup makes dialog handling available by default in control panel test setup. It helps keep tests for views, search menus, timesheets, projects, and dialogs more consistent and easier to maintain without changing day-to-day user workflows.
Original PR description
From a practical point of view, it seems better to also add the dialog service in the service registry when calling setupControlPanelServiceRegistry.
This change updates internal test setup so the dialog capability is registered only once when preparing view control panels. It reduces the risk of crashes during testing and keeps spreadsheet, cohort, pivot, and map view behavior stable.
Original PR description
The dialog service is now always added in the service registry when calling setupControlPanelServiceRegistry. So it cannot be added again (without option force=true) without causing a crash.
This change aligns several Odoo apps with an updated internal way of passing field configuration data in the web interface. It should help keep custom views and field behavior consistent with the main platform changes, with little direct impact on day-to-day users.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/113092, where fieldInfo and the API of extractProps have been slightly reworked. Part of task 3179751
As the tour `shop_editor` is very small, it finishes before the editor itself is fully loaded. As a consequence, some threads are remaining on the server side and can lead to a complete failure of the test. This seems to particularly affects builds on Bookwork with werkzeug 2.2.2 and python 3.11 as it leads to werkzeug requests timeout. With this commit, a step is added at the beginning of the test to ensure that the editor is loaded before beginning the test by itself. Failed build
Original PR description
As the tour `shop_editor` is very small, it finishes before the editor itself is fully loaded. As a consequence, some threads are remaining on the server side and can lead to a complete failure of the test. This seems to particularly affects builds on Bookwork with werkzeug 2.2.2 and python 3.11 as it leads to werkzeug requests timeout. With this commit, a step is added at the beginning of the test to ensure that the editor is loaded before beginning the test by itself. Failed build sample [here](https://runbot.odoo.com/runbot/build/23617288) Forward-Port-Of: odoo/odoo#112538
Bug === If the Reference field is in a list view, and has a default value, an error is raised if we create a new record without editing the reference value. This is because the ORM return a string "model,id" in the onchange method and this value is wrongly parsed in that case. Task-2234179 Forward-Port-Of: odoo/odoo#113226
Original PR description
Bug === If the Reference field is in a list view, and has a default value, an error is raised if we create a new record without editing the reference value. This is because the ORM return a string "model,id" in the onchange method and this value is wrongly parsed in that case. Task-2234179 Forward-Port-Of: odoo/odoo#113226
Using a lazy `?` quantifier lead to poor matching performances and was not needed technically. Using `*` instead of `+` lead to a lot of false positives when trying to write records with an empty value for `data-last-history-steps`. It is currently unclear how to reach such a case but in the meantime it is better to allow people to write the record as such rather than being completely locked with no possibility of saving. Co-authored-by: Olivier Dony <odo
Original PR description
Using a lazy `?` quantifier lead to poor matching performances and
was not needed technically.
Using `*` instead of `+` lead to a lot of false positives when trying
to write records with an empty value for `data-last-history-steps`.
It is currently unclear how to reach such a case but in the meantime
it is better to allow people to write the record as such rather than
being completely locked with no possibility of saving.
Co-authored-by: Olivier Dony <odo@openerp.com>
Forward-Port-Of: odoo/odoo#113412
Forward-Port-Of: odoo/odoo#113365## Current behaviour When trying the resend a snailmail that had a format error, by adding a cover we get an error that a record we trying to access is deleted. ## Expected behaviour We shouldn't delete the letter that we are trying to resend. ## Steps to reproduce - Install Invoicing - Add an IAP account with some credits - Create a contact with a reallllyyyy long address, to overfill the fields. - Create an invoice for that customer, try to print/send a snailmail - It should fail
Original PR description
## Current behaviour When trying the resend a snailmail that had a format error, by adding a cover we get an error that a record we trying to access is deleted. ## Expected behaviour We shouldn't…
## Current behaviour When trying the resend a snailmail that had a format error, by adding a cover we get an error that a record we trying to access is deleted. ## Expected behaviour We shouldn't delete the letter that we are trying to resend. ## Steps to reproduce - Install Invoicing - Add an IAP account with some credits - Create a contact with a reallllyyyy long address, to overfill the fields. - Create an invoice for that customer, try to print/send a snailmail - It should fail without a message, then scroll down to the red paperplane, add the cover and update resend, you get an error about the missing record. ## Reason for the problem This legacy code, so maybe in the past it used to work a bit differently. When trying to resend the letter, we are unlinking it's attachment (reasons for that are unknown to me), which is linked with a `Many2One` with letter with a cascading delete, so we end up deleting the `snailmail_letter` that we are iterating over, then when trying to write, it throws the error. ## Fix Remove the link between the attachment and the letter before the deletion of the `attachment_id`, so the letter is not being deleted. ## Affected versions - 14.0 - 15.0 - saas-15.2 - 16.0 - saas-16.1 - master --- opw-3111774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113005
A set iteration was creating a random number of queries on some tests. This was noticed in TestEventPerformance were a random additionnal query could appear in default_get depending on _get_description and _get_default_stage_id order. This commit uses a list to get a deterministic order. It looks like the set was not useful anyway. Forward-Port-Of: odoo/odoo#113532
Original PR description
A set iteration was creating a random number of queries on some tests. This was noticed in TestEventPerformance were a random additionnal query could appear in default_get depending on _get_description and _get_default_stage_id order. This commit uses a list to get a deterministic order. It looks like the set was not useful anyway. Forward-Port-Of: odoo/odoo#113532
If one of the theme was not migrated to the new tx api, still support the previous notation. Happened on the design-theme repository Forward-Port-Of: odoo/odoo#113535
Original PR description
If one of the theme was not migrated to the new tx api, still support the previous notation. Happened on the design-theme repository Forward-Port-Of: odoo/odoo#113535
Courtesy of Marianna (cima) Forward-Port-Of: odoo/odoo#113524
Original PR description
Courtesy of Marianna (cima) Forward-Port-Of: odoo/odoo#113524
Starting from [1], the `_updateColorpicker` method was added on the "link tools" widget to update colorpickers with the selected link colors (and it will create the colorpicker for each CSS property on widget `start`). Following this update, the code on [2] and [3] added some fixes to handle the async parts of `_updateColorpicker`. [3] was done very recently, more than one year later after the introduction of [1]. It turned a synchronous method into an asynchronous one (rightfully cons
Original PR description
Starting from [1], the `_updateColorpicker` method was added on the "link tools" widget to update colorpickers with the selected link colors (and it will create the colorpicker for each CSS property…
Starting from [1], the `_updateColorpicker` method was added on the "link tools" widget to update colorpickers with the selected link colors (and it will create the colorpicker for each CSS property on widget `start`). Following this update, the code on [2] and [3] added some fixes to handle the async parts of `_updateColorpicker`. [3] was done very recently, more than one year later after the introduction of [1]. It turned a synchronous method into an asynchronous one (rightfully considering the async calls to `_updateColorpicker` that were inside). As a fix, this commit will try to re-made it a synchronous method, and other parts related to `_updateColorpicker` too. The goal of this commit is to separate the link tools colorpicker "creation" code (`_addColorPicker` now) from colorpicker's "update" code. These changes are supposed to fix a race condition issue that appeared on 16.0, but since the code is the same on 15.0 and subject to the same issues, we target 15.0 with this fix. Hopefully, this prepares for an easier refactoring in master. [1]: https://github.com/odoo/odoo/commit/26d37812f0217ae913c8ddf761bcb26b5c44bff5 [2]: https://github.com/odoo/odoo/pull/78301/commits/6f1a6b76642db2e4f81cf3474ad0ec745a4bb3c9 [3]: https://github.com/odoo/odoo/commit/d15fdca644ef9ed1dfb011d3790f403e0157f55b runbot-5753 Forward-Port-Of: odoo/odoo#112744 Forward-Port-Of: odoo/odoo#109250
Reproduction: 1. Install Sales 2. Go to the quotations 3. Drag the column “name” and change the size 4. Check any sale order in checkbox 5. The column size is reset to default Reason: the keepColumnWidths parameter isn’t set to True after changing the size. This happens to all the list views Fix: we freeze the list after resizing the columns. Remove the extra keepColumnWidths setting in reordering since it's already set to true after resizing. Also added tests to check the column si
Original PR description
Reproduction: 1. Install Sales 2. Go to the quotations 3. Drag the column “name” and change the size 4. Check any sale order in checkbox 5. The column size is reset to default Reason: the keepColumnWidths parameter isn’t set to True after changing the size. This happens to all the list views Fix: we freeze the list after resizing the columns. Remove the extra keepColumnWidths setting in reordering since it's already set to true after resizing. Also added tests to check the column size is kept after toggling the checkboxes A similar fix is here: https://github.com/odoo/odoo/pull/10902 opw-3113822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112187
[CLA] Clean-up of the CLA for brain-tec AG. - Renamed brain-tec.md to braintec-group.md and removed the contributors who never contributed. - Created a new file braintec.md and added the currently needed contributors there. - Due to our rebranding and the associated change of the domain, this adjustment was necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113381
Original PR description
[CLA] Clean-up of the CLA for brain-tec AG. - Renamed brain-tec.md to braintec-group.md and removed the contributors who never contributed. - Created a new file braintec.md and added the currently needed contributors there. - Due to our rebranding and the associated change of the domain, this adjustment was necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113381
Steps to reproduce: Create an expense with a product which has a cost. Issue: There is no label that explains the amount displayed. Solution: Correct the label display. opw-3132937 Forward-Port-Of: odoo/odoo#112753 Forward-Port-Of: odoo/odoo#112070
Original PR description
Steps to reproduce: Create an expense with a product which has a cost. Issue: There is no label that explains the amount displayed. Solution: Correct the label display. opw-3132937 Forward-Port-Of: odoo/odoo#112753 Forward-Port-Of: odoo/odoo#112070
When selecting the content of a tab with Chrome, if the selection reaches the end of the tab content and there is additional content after the Tabs snippet, the selected range also includes the next inactive tabs that are hidden. Because of this, when replacing that selection, the next inactive tabs are removed, and the Tabs snippet is corrupted. This commit avoids this by marking the `.tab-pane`s as non-editable while keeping its `.oe_structure` editable. This makes the selection adjustment
Original PR description
When selecting the content of a tab with Chrome, if the selection reaches the end of the tab content and there is additional content after the Tabs snippet, the selected range also includes the next…
When selecting the content of a tab with Chrome, if the selection reaches the end of the tab content and there is additional content after the Tabs snippet, the selected range also includes the next inactive tabs that are hidden. Because of this, when replacing that selection, the next inactive tabs are removed, and the Tabs snippet is corrupted. This commit avoids this by marking the `.tab-pane`s as non-editable while keeping its `.oe_structure` editable. This makes the selection adjustment mechanism stop within the active tab pane. Steps to reproduce: - Use Chrome. - Drop two Tabs blocks inside a web page. - Select the first tab of the first one. - Select the last word, including the dot. (Double-click the word and drag beyond the dot before releasing the mouse button.) - Change the selected text's color. => The content of the second and third tab also had the chosen color. - Select the text in the first tab with a triple click. - Type something to replace the text. => The content of the second and third tab were removed and clicking on the tab's header did therefore not reach them anymore. opw-3117305 Forward-Port-Of: odoo/odoo#113551 Forward-Port-Of: odoo/odoo#109430
ValueError External ID not found in the system "stock.stock_replenishment_product_template_action" occurs when we open the forecast report of the product. This is because the code is not going to the else part because the exception is generated if the "stock_replenishment_product_template_action" template is not found. sentry traceback: 
Original PR description
ValueError External ID not found in the system "stock.stock_replenishment_product_template_action" occurs when we open the forecast report of the product. This is because the code is not going to the else part because the exception is generated if the "stock_replenishment_product_template_action" template is not found. sentry traceback:  This commit sets "raise_if_not_found=False" if the template is not found, it cannot raise an error. sentry-3788512070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113512
The `format_float` function is calling `float_repr`, which should not be used for rounding operation (see its docstring). Instead, we should use the `float_round` function. opw-3171987 Forward-Port-Of: odoo/odoo#113216
Original PR description
The `format_float` function is calling `float_repr`, which should not be used for rounding operation (see its docstring). Instead, we should use the `float_round` function. opw-3171987 Forward-Port-Of: odoo/odoo#113216
The presence of the history ids in the html resulted in false positive in the `_isDirty()` comparison. This lead to unwanted writes when switching records, even when no change were made. task-3186072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113530
Original PR description
The presence of the history ids in the html resulted in false positive in the `_isDirty()` comparison. This lead to unwanted writes when switching records, even when no change were made. task-3186072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113530
Current behavior: When there is an opening difference, the closing popup does not show it. Steps to reproduce: - Create a new POS session - Add some cash to the register (100€) - Close the session with the same amount - Open the session again - Change the cash amount in the register (80€) - When closing the session the popup should show the -20€ difference opw-3101297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/od
Original PR description
Current behavior: When there is an opening difference, the closing popup does not show it. Steps to reproduce: - Create a new POS session - Add some cash to the register (100€) - Close the session with the same amount - Open the session again - Change the cash amount in the register (80€) - When closing the session the popup should show the -20€ difference opw-3101297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113250 Forward-Port-Of: odoo/odoo#112776
Reverts https://github.com/odoo/odoo/pull/110666 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing > Config > Create 2 workcenters: WC1 and WC2 - Products > New Product > Name: P, type: Storable, Routes: Manufacture - Manufacturing > BoMs > Create > Product: P, Operations Tab, add 2 lines: - 1. operation: OP1, Work Center: WC1, Save - 2. operation: OP2, Work center: WC2, Save - Manual Save BoM, don'
Original PR description
Reverts https://github.com/odoo/odoo/pull/110666 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing > Config >…
Reverts https://github.com/odoo/odoo/pull/110666 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing > Config > Create 2 workcenters: WC1 and WC2 - Products > New Product > Name: P, type: Storable, Routes: Manufacture - Manufacturing > BoMs > Create > Product: P, Operations Tab, add 2 lines: - 1. operation: OP1, Work Center: WC1, Save - 2. operation: OP2, Work center: WC2, Save - Manual Save BoM, don't exit - Components Tab, activate column Consumed in Operation, add 2 lines: - 1. Product: P1, Create and edit > type: Storable - 2. Product: P2, Create and edit > type: Storable - Both lines, quantity: 2. - Each line, Consumed in operations: OP1 and OP2 - Save and exit - Operations > Manufacturing orders > New > Product: P, Quantity: 2 > Confirm - Workorder Tab > open first line tablet view: Quantity = 2.00/2.00 Units > Validate - open second line tablet view: Quantity = 0.00/2.00 Units (!) Issue: The recommended quantity should also be 2.00/2.00 Enterprise PR: https://github.com/odoo/enterprise/pull/37480 Forward-Port-Of: odoo/odoo#113534
Description of the issue/feature this PR addresses: Creating a new partner with no company selected should raise the same VAT partner warning if there is any other partner **in any** company with the same VAT. Current behavior before PR: 1. Create a partner in company A with VAT "test123" 2. Click Save. 3. Create a new partner with company field in blank and set the VAT field to "test123". No duplicated VAT warning appears. Desired behavior after PR is merged: 1. Create a partner in c
Original PR description
Description of the issue/feature this PR addresses: Creating a new partner with no company selected should raise the same VAT partner warning if there is any other partner **in any** company with the same VAT. Current behavior before PR: 1. Create a partner in company A with VAT "test123" 2. Click Save. 3. Create a new partner with company field in blank and set the VAT field to "test123". No duplicated VAT warning appears. Desired behavior after PR is merged: 1. Create a partner in company A with VAT "test123" 2. Click Save. 3. Create a new partner with company field in blank and set the VAT field to "test123". Duplicated VAT warning appears. @ForgeFlow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104367
This commit adds a step in the table of content test to make sure the edit mode is ready before clicking on the first TOC block. This is necessary because the test often failed on the runbot. task-3203031 Forward-Port-Of: odoo/odoo#113472
Original PR description
This commit adds a step in the table of content test to make sure the edit mode is ready before clicking on the first TOC block. This is necessary because the test often failed on the runbot. task-3203031 Forward-Port-Of: odoo/odoo#113472
Steps to reproduce: - create a project with an analytic account; - create sale orders/invoices and purchase order/bills for a project; - use other currencies; - go to the "Project Updates". Issue: The amounts are used without being converted into the currency of the analytic account. Solution: Convert amounts used in the currency of the analytic account. Note: For performance reasons, it is acceptable to fetch all currency on the same date to get the conversion rate. In this c
Original PR description
Steps to reproduce: - create a project with an analytic account; - create sale orders/invoices and purchase order/bills for a project; - use other currencies; - go to the "Project Updates". Issue: The amounts are used without being converted into the currency of the analytic account. Solution: Convert amounts used in the currency of the analytic account. Note: For performance reasons, it is acceptable to fetch all currency on the same date to get the conversion rate. In this case, today's date is the most appropriate (as the project is in progress). opw-3193676 Forward-Port-Of: odoo/odoo#113146
Rename method calls to be consistent with https://github.com/odoo/odoo/pull/112874 opw-3147362 Forward-Port-Of: odoo/enterprise#37497 Forward-Port-Of: odoo/enterprise#37479
Original PR description
Rename method calls to be consistent with https://github.com/odoo/odoo/pull/112874 opw-3147362 Forward-Port-Of: odoo/enterprise#37497 Forward-Port-Of: odoo/enterprise#37479
Reverts https://github.com/odoo/enterprise/pull/35867 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing > Config > Create 2 workcenters: WC1 and WC2 - Products > New Product > Name: P, type: Storable, Routes: Manufacture - Manufacturing > BoMs > Create > Product: P, Operations Tab, add 2 lines: - 1. operation: OP1, Work Center: WC1, Save - 2. operation: OP2, Work center: WC2, Save - Manual Save BoM,
Original PR description
Reverts https://github.com/odoo/enterprise/pull/35867 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing >…
Reverts https://github.com/odoo/enterprise/pull/35867 because of breaking behaviour introduced in https://github.com/odoo/enterprise/pull/35696 - Install quality_mrp_workorder - Manufacturing > Config > Create 2 workcenters: WC1 and WC2 - Products > New Product > Name: P, type: Storable, Routes: Manufacture - Manufacturing > BoMs > Create > Product: P, Operations Tab, add 2 lines: - 1. operation: OP1, Work Center: WC1, Save - 2. operation: OP2, Work center: WC2, Save - Manual Save BoM, don't exit - Components Tab, unlock column Consumend in Operation, add 2 lines: - 1. Product: P1, Create and edit > type: Storable - 2. Product: P2, Create and edit > type: Storable - Both lines, quantity: 2. - Each line, Consumed in operations: OP1 and OP2 - Save and exit - Operations > Manufacturing orders > New > Product: P, Quantity: 2 > Confirm - Workorder Tab > open first line tablet view: Quantity = 2.00/2.00 Units > Validate - open second line tablet view: Quantity = 0.00/2.00 Units (!) Issue: The recommended quantity should also be 2.00/2.00 Odoo PR: https://github.com/odoo/odoo/pull/113534 Forward-Port-Of: odoo/enterprise#37480
To avoid MemoryErrors for unncessary updates. Similar to #36592 Forward-Port-Of: odoo/enterprise#37489
Original PR description
To avoid MemoryErrors for unncessary updates. Similar to #36592 Forward-Port-Of: odoo/enterprise#37489
When we create a delivery guide 2.0 in v16, the barcode is not being printed on the PDF. This is because the path is wrong Before:  After:  Latam Task: https://latam-localizations.odoo.com/web#id=978&cids=1&model=project.task&view_type=form Forward-Port-Of: od
Original PR description
When we create a delivery guide 2.0 in v16, the barcode is not being printed on the PDF. This is because the path is wrong Before:  After:  Latam Task: https://latam-localizations.odoo.com/web#id=978&cids=1&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#37502
`sale_subscription` module got some refactoring in v16 [1] and got some issues on translations. 1. Invoice line description must be based on Order line description, not on fresh value `product_desc = ...`. Fix it by using `self.name` 2. Phrase `1 month` in invoice line description wasn't translated, because technical value of selection field `unit` was used: `self.order_id.recurrence_id.unit`. Fix it by using adding new computed field `duration_display`, which is based on `_get
Original PR description
`sale_subscription` module got some refactoring in v16 [1] and got some issues on translations. 1. Invoice line description must be based on Order line description, not on fresh value `product_desc =…
`sale_subscription` module got some refactoring in v16 [1] and got some issues on translations. 1. Invoice line description must be based on Order line description, not on fresh value `product_desc = ...`. Fix it by using `self.name` 2. Phrase `1 month` in invoice line description wasn't translated, because technical value of selection field `unit` was used: `self.order_id.recurrence_id.unit`. Fix it by using adding new computed field `duration_display`, which is based on `_get_unit_label`, which is copy-pasted and adjusted method of `product.pricing` model. Original method is kept because of stable version policy. STEPS: 1. Activate second language 2. Create partner with that language 3. Create recurring product, translate name and Sale Description 4. Create quotation template 5. Create SO from quotation template, confirm, create invoice [1]: https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd opw-3112359 Forward-Port-Of: odoo/enterprise#36776
Credit notes should not have the detraction section, there is no validation for this and SUNAT accepts credit notes with this section because they actually ignore it, but the problem is when you use another currency, SUNAT expects the entire XML to be in the same currency, but since detractions are always in PEN, the validation of the currencies takes place and we get the error 2071 (2071|La moneda debe ser la misma en todo el documento. Salvo las percepciones que sólo son en moneda nacional - D
Original PR description
Credit notes should not have the detraction section, there is no validation for this and SUNAT accepts credit notes with this section because they actually ignore it, but the problem is when you use another currency, SUNAT expects the entire XML to be in the same currency, but since detractions are always in PEN, the validation of the currencies takes place and we get the error 2071 (2071|La moneda debe ser la misma en todo el documento. Salvo las percepciones que sólo son en moneda nacional - Detalle: xxx.xxx.xxx ticket : 20230000000000129911014 error: Error NC (codigo: 2071): 2071 (nodo: "cbc:Amount/currencyID" valor: "PEN")). Task Latam: https://latam-localizations.odoo.com/web#id=966&cids=1&model=project.task&view_type=form Legal Reference: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia%2Bxml%2Bnota%20de%20cr%C3%A9dito%2Bversion%202-1%2B1%2B0_0_0.pdf Forward-Port-Of: odoo/enterprise#36563
Enterprise part of odoo/odoo#113308   Forward-Port-Of: odoo/enterprise#37448
Original PR description
Enterprise part of odoo/odoo#113308   Forward-Port-Of: odoo/enterprise#37448