Wednesday, October 4, 2023
45 changes · master
Enhancements to existing features
This update lets interface widgets receive dynamic information about whether a field should be read-only for the current record. It makes the web interface more consistent and easier to extend when widgets need to adapt to business rules.
Original PR description
As with fields, dynamicProps will be accessible to widgets from extractProps. This commit will make readonly accessible as the first dynamicProps. We'll be able to add more when we need them. DynamicInfo.readonly is true if the field is readonly independently of the record. 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
Several areas of Odoo were updated to use standard browser or JavaScript classes instead of custom Odoo-specific ones. This is an internal cleanup that should make the code easier to maintain without changing day-to-day user behavior.
Original PR description
This commit replaces some odoo classes by native ones. They are simple classes with no big extensions or not at all. task 3439226
This update removes an older internal shortcut used to trigger actions and updates affected areas to use the current approach. It helps simplify the code behind navigation and workflows without introducing a direct change for end users.
Original PR description
This commit removes the event `do-action` listened on `core.bus` and adpats the place where it was triggered. task 3439226
Delivery operations using carrier rate lookup only can now be validated without requiring a customer contact. This aligns the screen rules with the actual shipping process, reducing unnecessary blocking steps for warehouse users.
Original PR description
The requirement of partner_id was put long ago because send_to_shipper() method requires it. But if you look into the python code, you see in _send_confirmation_email() method that the requirement to enter into send_to_shipper() is `integration_level == 'rate_and_ship'` instead of `delivery_type not in ['fixed', 'base_on_rule']`. It means that, with this change, if we have a `delivery_type not in ['fixed', 'base_on_rule']`, we should be able to validate the picking without partner if we have `integration_level == 'rate'`. See python code requirement:  **Description of the issue/feature this PR addresses:** We adapt view requirement to the python requirement. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Removed obsolete background service compatibility code that is no longer needed. This simplifies maintenance for the platform without changing day-to-day user workflows.
Original PR description
This commit removes the legacy service mappers which are useless now. task: 3439226
This update removes outdated service mapping code that is no longer needed. It helps keep the system simpler and easier to maintain without changing day-to-day user workflows.
Original PR description
This commit removes the legacy service mappers which are useless now. task: 3439226
This update replaces some custom Odoo code classes with standard native ones where no special behavior was needed. It is an internal cleanup that should make the Belgian POS blackbox code easier to maintain without changing day-to-day user workflows.
Original PR description
This commit replaces some odoo classes by native ones. They are simple classes with no big extensions or not at all. task 3439226
This update removes an older behind-the-scenes way of launching actions and updates the affected barcode, manufacturing, quality control, and Studio screens to use the newer approach directly. It should make these areas easier to maintain without changing day-to-day user workflows.
Original PR description
This commit removes the event `do-action` listened on `core.bus` and adpats the place where it was triggered. task 3439226
It seems that the check register report was missing some translation terms, it's because this report is present in the l10n_us_reports localisation and so it's not updated each version. In this PR, we will add the pot file. task: 3491716
Original PR description
It seems that the check register report was missing some translation terms, it's because this report is present in the l10n_us_reports localisation and so it's not updated each version. In this PR, we will add the pot file. task: 3491716
Resolved issues and error corrections
This update improves the wording of an accounting payment error so users better understand what went wrong. Clearer guidance can reduce confusion and help users resolve payment registration issues more quickly.
Original PR description
The message error was not clear, so I changed the message to a clearer explanation of the user error. Signed-off-by: Maximilien La Barre <malb@odoo.com> -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
An unused accounting report setting has been removed because it is no longer populated by the reporting system. This keeps the accounting reporting code cleaner and reduces the chance of confusion from inactive options.
Original PR description
This field is never set since reportalypse and so, need to be removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change streamlines how Odoo processes and reuses view layouts across several apps. It reduces repeated internal conversions, making the code easier to maintain and helping future access-rights and view-related improvements be implemented more safely.
Original PR description
*board,mail,project This commit aims to simplify the XMLParser logic and the way archs are manipulated in views, motivated by [1] where we had to modify the arch in View to insert access right…
Miscellaneous changes
Reproduction: 1. Go to any record with a chatter 2. Open full composer 3. Enter a special case for the text using shortcuts (CTRL+I for italic, CTRL+B for bold, etc) 4. exit the special case with the same shortcut 5. JS error Reason: A selection is not null check is missing in the condition Related PR: https://github.com/odoo/odoo/pull/136777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137379
Original PR description
Reproduction: 1. Go to any record with a chatter 2. Open full composer 3. Enter a special case for the text using shortcuts (CTRL+I for italic, CTRL+B for bold, etc) 4. exit the special case with the same shortcut 5. JS error Reason: A selection is not null check is missing in the condition Related PR: https://github.com/odoo/odoo/pull/136777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137379
Messages now correctly highlight every mention when the same person or channel is mentioned more than once. This makes conversations clearer and helps users reliably see all intended mentions.
Original PR description
Before this commit, when mentioning a same user in a message twice, only the 1st `@` text was highlighted as a mention. This commit fixes the issue by highlighting all matching mentions of user and channel. Task-3531939
The self-order settings now show the “upgrade to enterprise” label in the correct place for the pay-after-selection option. This helps businesses clearly identify which payment setting requires Enterprise, reducing confusion during configuration.
Original PR description
After merging of the mobile and kiosk app for self order (https://github.com/odoo/odoo/pull/136051), the pay after selection that requires the "upgrade to enterprise" label was misplace. This fix restores the misplaced label. **Before:** <img width="446" alt="Screenshot 2023-10-03 at 14 14 25" src="https://github.com/odoo/odoo/assets/3245568/9220c0df-9ba2-4296-b819-860f78f6d348"> **After:** <img width="469" alt="Screenshot 2023-10-03 at 14 12 34" src="https://github.com/odoo/odoo/assets/3245568/4af2e1cb-c18a-472c-8ae2-302fe09fc39f">
This fix prevents negative stock quantities from being copied into new detailed operation lines. When a negative stock entry is selected, the quantity now starts at zero, reducing the risk of confusing or incorrect inventory operations.
Original PR description
Choosing a negative quant to create a new move line in the detailled operation should not take the negative quantity. This commit set 0 instead. 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 adjusts the stock availability display so the forecast icon lines up neatly with the related reservation text. It improves visual clarity for users reviewing stock moves without changing any business workflow or data.
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 fixes an issue where the copy-and-close action in appointment invitations could stay disabled even after users resolved the alerts blocking it. The button state now updates correctly as appointment invite conditions change, helping users complete the invite flow without refreshing or reopening the form.
Original PR description
Since the new Relational Model, if the <a> in AppointmentInviteCopyClose is disabled, it is not possible to enable it when you resolve alerts. Why: --- Before the new Relational Mode, the entire view was re-rendered each time the record was updated. AppointmentInviteCopyClose was therefore rendered and the callback in useEffect was called. This is no longer the case, only the Components that observe the data modified on the record are rendered. Solution: --------- We're going to use the dynamicProps.readonly which will be recalculated each time a change occurs in its condition. So we'll pass the readonly attribute to the <widget> with the condition the combination of all the conditions that can display an alert and cause the <a> to be disabled.
The timesheet list now shows the related helpdesk ticket field when users work from the My Timesheets menu. This helps teams link time entries to support tickets more easily and avoids missing context in timesheet records.
Original PR description
Steps: - Install Timesheets and Helpdesk - Open helpdesk and go to any project - Enable timesheet from settings - Now, go to timesheets - Go to my_timesheets list view Issue: - Ticket field is missing in dropdown. Cause: - List view inheriting the primary view. Fix: - Change the ref attribute in inherit field to extended view and add view for helpdesk_ticket_id. task-3478920
*board,mail,project This commit aims to simplify the XMLParser logic and the way archs are manipulated in views, motivated by [1] where we had to modify the arch in View to insert access right information. First, the xml utils have been reworked. The XMLParser class has been removed. The xml utils module already exported a parseXML and a serializeXML functions, this commit adds visitXML, s.t. the whole XMLParser feature is fully replaced by the 3 functions. Second, concrete views now receive the arch in props as an XMLDocument, as the arch is parsed once for all in View. With this, we were able to remove serializing/parsing back and forth at several places, where we needed to extract information for sub-parts of an arch individually (e.g. View, x2many subviews, list view groupby). Third, even though this change has been driven by the one above and wasn't initally wanted, the view compiler cache and API have been simplified. The cache is now flat, there's an entry in the cache for each template that has been compiled. Moreover, the useViewCompiler hook no longer takes the cache key in params, as it can directly compute it itself (the key being the outerHTML of the template). [1] https://github.com/odoo/odoo/pull/135145
This refactoring simplifies how Odoo Discuss prepares and stores message-related data, especially for guest and registered users. It reduces internal complexity and helps keep chat, live chat, and notification behavior consistent without introducing a visible feature change.
Original PR description
1. simplify message reaction formatter (personas) Data was formatted to have "partners" and "guests" entries, both of which contribute to personas. To avoid some post-processing of data in JS, it's best to format data to immediately include type of persona. 2. include "guestAuthor" in "author" data of message Discuss models in JS group partners and guests into a single model Persona, to make feature works regardless on whether user is authenticated or not. This commit simplifies code by removing data `guestAuthor` in message formatted data, and instead `author` contains author data in all cases, whether the author is a partner or guest. 3. simplify insert (remove id, redundant with preinsert) - Also rename `Follower.isActive` to `Follower.is_active`, for even simpler `Follower.insert()`
This update removes an obsolete internal error-identification step from the Point of Sale code. It reflects earlier POS refactoring work and helps keep the system simpler without changing day-to-day user behavior.
Original PR description
After the the POS refactoring, there are no more errors of type `legacy`, so the function `identifyError`, whose objective was to identify the `legacy` errrors, is now completely useless. We thus remove it. Task: 3524670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update modernizes how several Odoo Enterprise views read and adjust their screen layouts after related platform API changes. It mainly keeps marketing automation, reporting, planning-style views, maps, and Studio compatible and easier to maintain, with little expected day-to-day user impact.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/136376. We had to adapt view arch parsers and uses of xml utils as their API changed.
Description of the issue/feature this commit addresses: As of the first October 2023, some Japanese companies will start using "T" as country code in their Tax ID. The current vat check only allows the country code to be used in the Tax ID which means that "T" is refused. --- Desired behavior after the commit is merged : This commit makes it possible for Japanese companies to use "T" as a country code in their Tax ID. --- Note about the changes : The "check_vat_t" method which
Original PR description
Description of the issue/feature this commit addresses: As of the first October 2023, some Japanese companies will start using "T" as country code in their Tax ID. The current vat check only allows…
Description of the issue/feature this commit addresses:
As of the first October 2023, some Japanese companies will start using "T" as country code in their Tax ID. The current vat check only allows the country code to be used in the Tax ID which means that "T" is refused.
---
Desired behavior after the commit is merged :
This commit makes it possible for Japanese companies to use "T" as a country code in their Tax ID.
---
Note about the changes :
The "check_vat_t" method which redirects to "simple_vat_check('jp',vat)" uses an external library in 14.0 and 15.0 as no "check_vat_jp" is available in Odoo in those versions. This is done for all countries which do not have a specific check method implemented. As no method is implemented in Odoo to check Japan in 14.0 and 15.0, any code can be used as a country code in the Tax ID and no change would be needed IF the user uses the version of the external library specified in the requirements (stdnum v1.8). But if he uses a more recent version which has a restriction for Japan (1.14 or above) then he won't be able to use "T" as a country code even in 14.0 and 15.0. This would be typically ignored as it would mean the user did not pay attention to the requirements but since it is a legal change, it has been taken into account.
(Runbot runs the requirements version (1.8) so testing in 14.0 makes no difference at all. Starting from 16.0, the modification is noticable on the runbot. PO is okay with it)
---
task-3515786
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#137299
Forward-Port-Of: odoo/odoo#136146**current behavior before PR:** When pasting text from outside odoo, it often includes additional tags such as `<b>` and `<P>`, along with unwanted styles. **Desired behavior after PR is merged:** When pasting text from outside odoo, those extra tags and styles are now removed. task-3378093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#136341 Forward-Port-Of: odoo/odoo#127393
Original PR description
**current behavior before PR:** When pasting text from outside odoo, it often includes additional tags such as `<b>` and `<P>`, along with unwanted styles. **Desired behavior after PR is merged:** When pasting text from outside odoo, those extra tags and styles are now removed. task-3378093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#136341 Forward-Port-Of: odoo/odoo#127393
Prior to this commit, when closing the pos, if an order contained a product with a tax present in the parent company, the tax would not be found. Steps to reproduce: - create a tax in pos of company - create a branch company - set a product in pos of branch company with tax from parent company - sell that product in pos - close pos, error close popup will show up Since a company is allowed to access the taxes of its parent, the filter has been changed to check the taxes of the pare
Original PR description
Prior to this commit, when closing the pos, if an order contained a product with a tax present in the parent company, the tax would not be found. Steps to reproduce: - create a tax in pos of company - create a branch company - set a product in pos of branch company with tax from parent company - sell that product in pos - close pos, error close popup will show up Since a company is allowed to access the taxes of its parent, the filter has been changed to check the taxes of the parent companies of the company. Task-3502993 Forward-Port-Of: odoo/odoo#136792
This PR adds the verification for user input fields related to Six terminals on the IoT box homepage. Since we are moving Six to IoT it can be dangerous to call C functions with wrong arguments (this can lead to leaks, errors and crashes) Before accepting user input we now check if it's valid and only accept the terminal id if it's solely composed of digits. [Related PR on Worldline-lib](https://github.com/odoo/worldline-lib/pull/4) [task-3031744](https://www.odoo.com/web#id=3031744&cids
Original PR description
This PR adds the verification for user input fields related to Six terminals on the IoT box homepage. Since we are moving Six to IoT it can be dangerous to call C functions with wrong arguments (this can lead to leaks, errors and crashes) Before accepting user input we now check if it's valid and only accept the terminal id if it's solely composed of digits. [Related PR on Worldline-lib](https://github.com/odoo/worldline-lib/pull/4) [task-3031744](https://www.odoo.com/web#id=3031744&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#136629 Forward-Port-Of: odoo/odoo#135667
Before this commit, in a Email Marketing form sheet, there was a margin-left spacing on alerts and unnecessary old CSS rules. This commit addresses and corrects that spacing issue. task-3488229 <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img width="1726" alt="Capture d’écran 2023-08-29 à 09 05 01" src="https://github.com/odoo/odoo/assets/80678921/9eee3c71-3ef9-42d0-a9c1-3f7b78bcb9c8"> </td> <td><img width="1726" alt="Capture d’écran 2023-08-29 à 09 05 07" sr
Original PR description
Before this commit, in a Email Marketing form sheet, there was a margin-left spacing on alerts and unnecessary old CSS rules. This commit addresses and corrects that spacing issue. task-3488229 <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img width="1726" alt="Capture d’écran 2023-08-29 à 09 05 01" src="https://github.com/odoo/odoo/assets/80678921/9eee3c71-3ef9-42d0-a9c1-3f7b78bcb9c8"> </td> <td><img width="1726" alt="Capture d’écran 2023-08-29 à 09 05 07" src="https://github.com/odoo/odoo/assets/80678921/adaf0f1d-5849-4d07-af97-0b9610ade412"> </td> </table> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#133786
Previous fix odoo/odoo#135784 added a test to repair that references a sale_order_line field that only exists when the sale_margin module is installed. Unfortunately there isn't already a common module that requires both repair + sale_margin and runbot doesn't do single module app tests so this test slipped through the cracks. To avoid the error when the nightly single module tests occur, we avoid running the test when sale_margin is installed since it will still run during standard runbot te
Original PR description
Previous fix odoo/odoo#135784 added a test to repair that references a sale_order_line field that only exists when the sale_margin module is installed. Unfortunately there isn't already a common module that requires both repair + sale_margin and runbot doesn't do single module app tests so this test slipped through the cracks. To avoid the error when the nightly single module tests occur, we avoid running the test when sale_margin is installed since it will still run during standard runbot tests and ensure that the bug doesn't return. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137453
Exportation of services should be No Sujeto por reglas de Localisacion and not No Sujeto for 7,14. 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#137164 Forward-Port-Of: odoo/odoo#137125
Original PR description
Exportation of services should be No Sujeto por reglas de Localisacion and not No Sujeto for 7,14. 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#137164 Forward-Port-Of: odoo/odoo#137125
[FIX] web_editor, *: store the correct mimetype of an image with a shape *: base Steps to reproduce the bug: - Add an image on the website. - Replace it by a "jpeg". Note that the mimetype of the image is "image/webp" at the upload since [1]. - Add a shape on the image. - Save and Edit. -> If you check on the available "Format", the mimetype of the "Original" is "webp" but it should be "jpeg". Before this commit, there were two types of mimetype data attribute: - "mimetype": t
Original PR description
[FIX] web_editor, *: store the correct mimetype of an image with a shape *: base Steps to reproduce the bug: - Add an image on the website. - Replace it by a "jpeg". Note that the mimetype of the…
[FIX] web_editor, *: store the correct mimetype of an image with a shape *: base Steps to reproduce the bug: - Add an image on the website. - Replace it by a "jpeg". Note that the mimetype of the image is "image/webp" at the upload since [1]. - Add a shape on the image. - Save and Edit. -> If you check on the available "Format", the mimetype of the "Original" is "webp" but it should be "jpeg". Before this commit, there were two types of mimetype data attribute: - "mimetype": the current mimetype of the image. - "originalMimetype": the mimetype of the image without a shape. Before [1], it was also the mimetype of the original image. However, since [1], the user has the possibility to change the mimetype of the image so the "originalMimetype" attribute does not always refer to the mimetype of the original image anymore. To resolve the problem, another data attribute has to be introduced. Here is a summary of the mimetype related attribute: - `mimetypeBeforeConversion`: the mimetype of the original image. It is needed in order to be able to change the format of an image and come back to the original one. - `originalMimetype`: the mimetype of the image before a shape has been applied. It is needed when removing a shape to recover the correct mimetype. - `mimetype`: the current mimetype of an image. In the case of an uploaded "jpeg" image on which a shape has been applied, `mimetypeBeforeConversion` is "image/jpeg", `originalMimetype` is "image/webp" (since [1]) and `mimetype` is "image/svg+xml". The `loadImageInfo()` has been adapted to also handle the case of an image that has already been loaded but that does not have the `mimetypeBeforeConversion` attribute (for example all the images that were uploaded on the website before this commit). In this case, the mimetype attribute is kept and not set to the original one as the user could have changed it. [1]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d task-3449866 Forward-Port-Of: odoo/odoo#137217
## [FIX] account : Deprecated accounts shall not appear in suggestions ### [Genesis] while forward-porting tests for an issue (not present in the master anymore), found changes causing the following error: ValueError: not enough values to unpack (expected 4, got 3) in line: kind, rhs_table, condition, condition_params = query._joins['account_move_line__account_id'] Follow orginal PR (#135884) to learn more. ### [Problem] To reproduce: - run odoo master with module: ac
Original PR description
## [FIX] account : Deprecated accounts shall not appear in suggestions ### [Genesis] while forward-porting tests for an issue (not present in the master anymore), found changes causing the following…
## [FIX] account : Deprecated accounts shall not appear in suggestions
### [Genesis]
while forward-porting tests for an issue (not present in the master
anymore), found changes causing the following error:
ValueError: not enough values to unpack (expected 4, got 3)
in line:
kind, rhs_table, condition, condition_params = query._joins['account_move_line__account_id']
Follow orginal PR (#135884) to learn more.
### [Problem]
To reproduce:
- run odoo master with module: account_accountant
- go to: invoicing app -> Vendors -> Bills -> New
- pick a vendor -> add a line -> click on dropdown in the Account column
- upload and observe an ERROR
### [Solution]
- Since query._join will always return 3-element tuple, I'm removing additional variable "condition_params"
- query._joins can't be filled with Strings, it needs SQL instances; replacing strings with odoo.tools.sql.SQL objects
- forwarding tests checking for deprecated accounts
### [Testing]
Created test in test_account_account:
It runs function with modified sql query twice:
- with certain account not deprecated -> extected that this account appears in the results
- with the same account deprecated -> extected that this account won't appears in the results
opw-3485768
Forward-Port-Of: odoo/odoo#136562
Forward-Port-Of: odoo/odoo#135884Since this commit [1], 3 bugs have appeared with the colorpicker of the transparent header and 1 bug with the colorpicker of color combinations presets. 1rst bug fix was moved to https://github.com/odoo/odoo/pull/134202 Steps to reproduce the second bug: - Go to Website edit mode. - Click on the header. - Choose "Over The content" for the "Header Position" option of the header. - Open the colorpicker (below the "Header Position" selector). - Bug: we shouldn't be able to choose anyt
Original PR description
Since this commit [1], 3 bugs have appeared with the colorpicker of the transparent header and 1 bug with the colorpicker of color combinations presets. 1rst bug fix was moved to…
Since this commit [1], 3 bugs have appeared with the colorpicker of the transparent header and 1 bug with the colorpicker of color combinations presets. 1rst bug fix was moved to https://github.com/odoo/odoo/pull/134202 Steps to reproduce the second bug: - Go to Website edit mode. - Click on the header. - Choose "Over The content" for the "Header Position" option of the header. - Open the colorpicker (below the "Header Position" selector). - Bug: we shouldn't be able to choose anything other than a gray. This bug occurs because, before the conversion to owl, the colorpicker widget was added conditionally in JavaScript (so the widget was not included if the option "custom" color was excluded). However, in the current version, the color picker is inside the 'web_editor.ColorPalette' XML without any condition to display it or not. Steps to reproduce the 3rd bug: - Go to Website edit mode. - Click on the header. - Choose "Over The content" for the "Header Position" option of the header. - Change the color of the header by picking a color in the "Background" sub option (below the "Header Position" selector). - Save and Edit. - Go with your mouse over the different colors of the colorpicker (at least 2). - Bug: an infinite loader appears on the iframe and prevents from editing the background color. Steps to reproduce the color combinations bug: - Go to Website edit mode. - Drop a Call to action snippet. - Change the background color and try to select another preset. - Bug: the color of the text and buttons is updated, but not the background color. Both of these 2 bugs happen after commit [1] because the colorpicker widget is started before the ColorPalette component is attached to the DOM (which only happens once the user opens the picker). However, the colorNames are only set after the setup() of the ColorPalette. Initializing the colorNames with possible default values is thus necessary to avoid bugs on `_computeWidgetState()`. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997 [documentation]: https://github.com/odoo/owl/blob/master/doc/reference/props.md#good-practices task-3440939 Forward-Port-Of: odoo/odoo#129930
Before fix: only select activities done today or in the future so it does not reflect the expected behavior of the filter. After fix: have expected data with a suitable filter name OPW: [3504670](https://www.odoo.com/web?debug=1#id=3504670&cids=2&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137363
Original PR description
Before fix: only select activities done today or in the future so it does not reflect the expected behavior of the filter. After fix: have expected data with a suitable filter name OPW: [3504670](https://www.odoo.com/web?debug=1#id=3504670&cids=2&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137363
## Before this commit: When returning a dropshipping, the valuation layers created do not have the correct accounts on it: - Valuation -> Input for the first SVL - Output -> Valuation for the second SVL ## After this commit: For a dropshipped move, valuation layers have the following chain of accounts: - Input -> Valuation for the first SVL - Valuation -> Output for the second SVL Therefore, the return should have it reversed: - Output -> Valuation for the first SVL - Va
Original PR description
## Before this commit: When returning a dropshipping, the valuation layers created do not have the correct accounts on it: - Valuation -> Input for the first SVL - Output -> Valuation for the second SVL ## After this commit: For a dropshipped move, valuation layers have the following chain of accounts: - Input -> Valuation for the first SVL - Valuation -> Output for the second SVL Therefore, the return should have it reversed: - Output -> Valuation for the first SVL - Valuation -> Input for the second SVL ## Steps to reproduce: 1. Create a dropship product with automated inventory valuation 2. Create a Sales Order, go on the PO and confirm it 3. Set quantities and validate dropshipping 4. Return delivered product (dropship return) opw-3391174 Forward-Port-Of: odoo/odoo#137325 Forward-Port-Of: odoo/odoo#132864
When user tries to apply any Group By as date or datetime in the pivot view and the column value of pivot view is also a date or dateime, the traceback will be generated. To reproduce the issue: - Install Point of Sale - Go to 'Reporting' and click on 'Orders' - Select pivot view - Go to Group By and select 'Order Date' same as column value - Issue can be produce in the same way in other modules, such as - 'sale', 'sale_subscription', 'crm', 'planning', 'hr_expense' etc. Error: ```
Original PR description
When user tries to apply any Group By as date or datetime in the pivot view and the column value of pivot view is also a date or dateime, the traceback will be generated. To reproduce the issue: -…
When user tries to apply any Group By as date or datetime in the pivot view and the column value of pivot view is also a date or dateime, the traceback will be generated.
To reproduce the issue:
- Install Point of Sale
- Go to 'Reporting' and click on 'Orders'
- Select pivot view
- Go to Group By and select 'Order Date' same as column value
- Issue can be produce in the same way in other modules, such as - 'sale', 'sale_subscription', 'crm', 'planning', 'hr_expense' etc.
Error:
```
File "odoo/http.py", line 2134, in __call__
response = request._serve_db()
File "odoo/http.py", line 1710, 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 1737, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1938, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 457, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 430, in _call_kw_model
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 2593, in read_group
self._read_group_format_result(rows_dict, lazy_groupby)
File "odoo/models.py", line 2428, in _read_group_format_result
range_end = value + interval
TypeError: can only concatenate str (not "relativedelta") to str
```
The issue is occurring because we are getting duplicate values in groupby like ['date:month', 'date:month'] while calling orm method over here - https://github.com/odoo/odoo/blob/6cf3b617d8082df5820283d07e6623b7684cefdd/addons/web/static/src/core/orm_service.js#L143
To solve this issue groupby has been passed into a Set so that no duplicate values occurs in groupby.
sentry-4262719543
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#134087When sending an invoice, if an error was raised in the middle of the process we wrongly displayed the banner "This invoice is being sent in the background". task-id:3515915 Forward-Port-Of: odoo/odoo#136653
Original PR description
When sending an invoice, if an error was raised in the middle of the process we wrongly displayed the banner "This invoice is being sent in the background". task-id:3515915 Forward-Port-Of: odoo/odoo#136653
Steps to reproduce: - Create a two-layers Bill of Material (BoM and child BoM). - Create a Manufacturing Order with the top-level BoM and open the Overview. - Click 'Unfold', then hit the 'Replenish' button on the component. - Select 'Manufacture' as preferred route and confirm. Issue: The newly created Manufacturing Order is correctly added in the report but already unfolded, which can greatly change the visibility of the report if it has lots of components. This is due to an `undefine
Original PR description
Steps to reproduce: - Create a two-layers Bill of Material (BoM and child BoM). - Create a Manufacturing Order with the top-level BoM and open the Overview. - Click 'Unfold', then hit the 'Replenish' button on the component. - Select 'Manufacture' as preferred route and confirm. Issue: The newly created Manufacturing Order is correctly added in the report but already unfolded, which can greatly change the visibility of the report if it has lots of components. This is due to an `undefined` value in the ComponentsBlock fold indexes as they were not updated after the new props update. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137153
Steps to reproduce: - Set up an Italian language company with Italian localisation. - Set up an English language customer. - Set up an Italian language supplier. - Set up a product with dropshipping options. - Set up a sales order for the product to be dropshipped direct from the Italian supplier to the English customer. - Print the DDT report. Bug: The report will be printed in Italian. Fix: same as delivery slip reuse _get_report_lang opw-3526633 Forward-Port-Of: odoo/odoo#13
Original PR description
Steps to reproduce: - Set up an Italian language company with Italian localisation. - Set up an English language customer. - Set up an Italian language supplier. - Set up a product with dropshipping options. - Set up a sales order for the product to be dropshipped direct from the Italian supplier to the English customer. - Print the DDT report. Bug: The report will be printed in Italian. Fix: same as delivery slip reuse _get_report_lang opw-3526633 Forward-Port-Of: odoo/odoo#137555
How to reproduce: - go to a record with an html field on firefox (i.e. lead) - go to knowledge from there, on an article with a template (clipboard) block - click on the `Use as ...` button Current behavior: - error in the console - the content is not added to the destination `html_field` Expected behavior: - content is properly pasted in the destination `html_field` Technical explanation: `:has` is not available on Firefox in a `querySelector` task-3526189 Forward-Port-Of: o
Original PR description
How to reproduce: - go to a record with an html field on firefox (i.e. lead) - go to knowledge from there, on an article with a template (clipboard) block - click on the `Use as ...` button Current behavior: - error in the console - the content is not added to the destination `html_field` Expected behavior: - content is properly pasted in the destination `html_field` Technical explanation: `:has` is not available on Firefox in a `querySelector` task-3526189 Forward-Port-Of: odoo/enterprise#48101
Initialization of `token` and `vatRateMapping` need to be done before the super call in `setup` method. The bug causes issues for `initVatRates`, which will not be able to load the valid VAT rates. Forward-Port-Of: odoo/enterprise#46681
Original PR description
Initialization of `token` and `vatRateMapping` need to be done before the super call in `setup` method. The bug causes issues for `initVatRates`, which will not be able to load the valid VAT rates. Forward-Port-Of: odoo/enterprise#46681
What are the steps to reproduce the issue? 1. Create an asset model with different Fixed Asset Account and Depreciation Account 2. Create an asset using the newly created asset model What is the current behavior that you observe? Fixed Asset Account and Depreciation Account are the same What would be your expected behavior in this case? The accounts should match the ones in the asset model The solution: Add the changes the fixed asset account in the onchange of the model. Also ens
Original PR description
What are the steps to reproduce the issue? 1. Create an asset model with different Fixed Asset Account and Depreciation Account 2. Create an asset using the newly created asset model What is the current behavior that you observe? Fixed Asset Account and Depreciation Account are the same What would be your expected behavior in this case? The accounts should match the ones in the asset model The solution: Add the changes the fixed asset account in the onchange of the model. Also ensures that if the asset is generated from a bill, we don't override it with the account from the model. If the fixed assets account is not defined in the model, it will put it empty in the asset, which will trigger the compute to take the one from the depreciation account. We will not keep the one that was defined on the asset, as the model should take precedence. opw-2929933 opw-3203232 Forward-Port-Of: odoo/enterprise#48307 Forward-Port-Of: odoo/enterprise#30053
6c570325dc64adba441c748d834cee2c0fe488b7 changed the way javascript handles options. They are now generated by a different RPC call than the lines. It is hence not possible anymore to assign option keys within the functions computing the lines (or more generally speaking, subfunctions called by _get_report_information). Because of that, the column_headers option key of the consolidation report was always computed with a standard value, causing the report's custom components to crash when tryi
Original PR description
6c570325dc64adba441c748d834cee2c0fe488b7 changed the way javascript handles options. They are now generated by a different RPC call than the lines. It is hence not possible anymore to assign option keys within the functions computing the lines (or more generally speaking, subfunctions called by _get_report_information). Because of that, the column_headers option key of the consolidation report was always computed with a standard value, causing the report's custom components to crash when trying to opening it. Forward-Port-Of: odoo/enterprise#48306
Account 128 Accounting changes affecting retained earnings was previously omitted from the balance sheet. This commit adds it in 'Results carried forward'. (Since accounts 121 and 128 are the only ones starting with 12, we use the account code 12 to refer to them both.) This is part of the wider task of re-balancing the balance sheets. I've verified that with this change, the balance sheet is indeed balanced. taskid:3239795 Forward-Port-Of: odoo/enterprise#46956
Original PR description
Account 128 Accounting changes affecting retained earnings was previously omitted from the balance sheet. This commit adds it in 'Results carried forward'. (Since accounts 121 and 128 are the only ones starting with 12, we use the account code 12 to refer to them both.) This is part of the wider task of re-balancing the balance sheets. I've verified that with this change, the balance sheet is indeed balanced. taskid:3239795 Forward-Port-Of: odoo/enterprise#46956
Currently our pos_six module doens't work anymore because Google Chrome blocks communication to the devices on local network. To bypass this we migrate the module to enterprise and use IoT to still support Six terminals integration. This PR targets a stable version because we currently have no payment terminal solution for Switzerland [task-3031744](https://www.odoo.com/web#id=3031744&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) Forward-Port-Of: odoo/ent
Original PR description
Currently our pos_six module doens't work anymore because Google Chrome blocks communication to the devices on local network. To bypass this we migrate the module to enterprise and use IoT to still support Six terminals integration. This PR targets a stable version because we currently have no payment terminal solution for Switzerland [task-3031744](https://www.odoo.com/web#id=3031744&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#47900 Forward-Port-Of: odoo/enterprise#47086
The test test_depreciation_schedule_hierarchy fails undeterministically. This is due to the fact that a savepoint in _autopost_draft_entries take an env at random. This could cause the context to contain the value delay_account_group_sync which would make the account not have groups. Linked to runbot error 24474 Forward-Port-Of: odoo/enterprise#46910
Original PR description
The test test_depreciation_schedule_hierarchy fails undeterministically. This is due to the fact that a savepoint in _autopost_draft_entries take an env at random. This could cause the context to contain the value delay_account_group_sync which would make the account not have groups. Linked to runbot error 24474 Forward-Port-Of: odoo/enterprise#46910