Friday, June 21, 2024
35 changes · saas-17.1
Miscellaneous changes
Steps to reproduce ================== - Use a webkit based browser (safari or epiphany) - Go to accounting > configuration > journals - Open the cash record - Switch to the incoming payments tab - In the optional column dropdown, enable the outstanding receipts accounts => The column is hidden but should be displayed Cause of the issue ================== The table width was computed with a fixed table layout. At that point in safari, the width was not yet correctly computed.
Original PR description
Steps to reproduce ================== - Use a webkit based browser (safari or epiphany) - Go to accounting > configuration > journals - Open the cash record - Switch to the incoming payments tab - In the optional column dropdown, enable the outstanding receipts accounts => The column is hidden but should be displayed Cause of the issue ================== The table width was computed with a fixed table layout. At that point in safari, the width was not yet correctly computed. Solution ======== We can revert commit 4163f1f4ff3f28c04cfde5427e6b25323d62a857: [FIX] web: prevent inline x2many list view overflows The original issue fixed by that commit isn't present anymore. It has probably been fixed due to some unrelated code changes or browser update. opw-3869696 Forward-Port-Of: odoo/odoo#170283 Forward-Port-Of: odoo/odoo#170139
- In Odoo v16 and above, the Place of Supply information was not displayed on the invoice report, unlike in previous versions. - This PR rectifies the issue, ensuring that the Place of Supply is correctly printed on the invoice report, maintaining consistency with earlier versions. **task**:3983822 Forward-Port-Of: odoo/odoo#170221 Forward-Port-Of: odoo/odoo#169202
Original PR description
- In Odoo v16 and above, the Place of Supply information was not displayed on the invoice report, unlike in previous versions. - This PR rectifies the issue, ensuring that the Place of Supply is correctly printed on the invoice report, maintaining consistency with earlier versions. **task**:3983822 Forward-Port-Of: odoo/odoo#170221 Forward-Port-Of: odoo/odoo#169202
**Steps to reproduce:** - Install Invoicing - Go to "Invoicing / Configuration / Settings" - Deactivate "Document Digitalization" - Create an invoice - Upload a PDF via paperclip button or drag and drop in the chatter **Issue:** The preview box appears but it is empty. **Cause:** In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post
Original PR description
**Steps to reproduce:** - Install Invoicing - Go to "Invoicing / Configuration / Settings" - Deactivate "Document Digitalization" - Create an invoice - Upload a PDF via paperclip button or drag and drop in the chatter **Issue:** The preview box appears but it is empty. **Cause:** In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post_refresh" option. **Solution:** Add "post_refresh" option for "message_ids" field in the view as it is done when "account_invoice_extract" module is installed. opw-3887671 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169612
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and Start the repair - try to end the repair **Problem:** A traceback is triggered: “raise ValueError("Expected singleton: %s" % self) Value Error: Expected singleton: stock.location() “ When the "action_repair_end" is called, a move is created with the kit product, and
Original PR description
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and…
**Steps to reproduce the bug:**
- Create a consumable product “Kit 1” with the following BoM:
- component: X1
- Create a repair order to repair one unit of Kit 1:
- Don’t add any part
- confirm and Start the repair
- try to end the repair
**Problem:**
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“
When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80
Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74
So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94
The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052
If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:
“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“
opw-[3942297](https://www.odoo.com/web#id=3942297&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#168227**Steps to reproduce the bug:** - Create a storable product P1: - uom = KG - tracked by lot: L1 - update the quantity to 50 kg - Create a storable product P2 with BoM: - quantity: 1 unit of P2 - Component: - 50 000 g of P1 - create a MO to produce one unit of P2 - Need 50 000 g of P1, select the lot L1 in the detailed operation **Problem:** - only 50 g of P1 is reserved intsead of 50 000g. opw-3935230 Forward-Port-Of: odoo/odoo#168055
Original PR description
**Steps to reproduce the bug:**
- Create a storable product P1:
- uom = KG
- tracked by lot: L1
- update the quantity to 50 kg
- Create a storable product P2 with BoM:
- quantity: 1 unit of P2
- Component:
- 50 000 g of P1
- create a MO to produce one unit of P2
- Need 50 000 g of P1, select the lot L1 in the detailed operation
**Problem:**
- only 50 g of P1 is reserved intsead of 50 000g.
opw-3935230
Forward-Port-Of: odoo/odoo#168055Before commit: To reproduce the error: A device may send non-JSON data to the IoT controller, or the CDN might return an error in a non-JSON format. We just get a very non-explicit error: "Expecting value: line 1 column 1 (char 0)". After commit: We add a catch for non-JSON data and log the error along with the incorrect data to have more information. opw-3876631 Forward-Port-Of: odoo/odoo#169938
Original PR description
Before commit: To reproduce the error: A device may send non-JSON data to the IoT controller, or the CDN might return an error in a non-JSON format. We just get a very non-explicit error: "Expecting value: line 1 column 1 (char 0)". After commit: We add a catch for non-JSON data and log the error along with the incorrect data to have more information. opw-3876631 Forward-Port-Of: odoo/odoo#169938
This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing. 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#169290 Forward-Port-Of: odoo/odoo#167955
Original PR description
This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing. 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#169290 Forward-Port-Of: odoo/odoo#167955
Since 17.0, the account_token field is limited to 43 characters But some database created before that version might still have some `iap.account` records with token longer than 34 characters. If the neutralization script tries to add `+disabled` (9 characters) to such records, it fails. This prevents the creation of duplicates on the SaaS and PaaS until the invalid records are purged for the database, which is not really obvious if you don't already know the details of the implementatio
Original PR description
Since 17.0, the account_token field is limited to 43 characters But some database created before that version might still have some `iap.account` records with token longer than 34 characters. If the neutralization script tries to add `+disabled` (9 characters) to such records, it fails. This prevents the creation of duplicates on the SaaS and PaaS until the invalid records are purged for the database, which is not really obvious if you don't already know the details of the implementation of the `iap.account` model. With this commit, the neutralization script will only try to retain the original value of the token (with `+disabled` appended) if it is going to succeed, and falls back to a dummy value in other cases. opw-3999439 Forward-Port-Of: odoo/odoo#170004
PURPOSE The card is simply too wide for the display in mobile view. SPECIFICATIONS - made the avatar card responsive - enabled the avatar card popover for m2x avatar user widget - close avatar card when clicking on 'send message' Task-3713375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155822
Original PR description
PURPOSE The card is simply too wide for the display in mobile view. SPECIFICATIONS - made the avatar card responsive - enabled the avatar card popover for m2x avatar user widget - close avatar card when clicking on 'send message' Task-3713375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155822
(note for reviewer: I reset my branch on 15.0) The `werkzeug.proxy_fix.orig` is set when running in --proxy-mode, it holds the original value of various headers before the ProxyFix class changed them according to the `X-Forwarded-` headers. It is a dictionnary with the following entries: orig_remote_addr = environ_get("REMOTE_ADDR") orig_wsgi_url_scheme = environ_get("wsgi.url_scheme") orig_http_host = environ_get("HTTP_HOST") "werkzeug.proxy_fix.orig": { "RE
Original PR description
(note for reviewer: I reset my branch on 15.0) The `werkzeug.proxy_fix.orig` is set when running in --proxy-mode, it holds the original value of various headers before the ProxyFix class changed them…
(note for reviewer: I reset my branch on 15.0)
The `werkzeug.proxy_fix.orig` is set when running in --proxy-mode, it holds the original value of various headers before the ProxyFix class changed them according to the `X-Forwarded-` headers.
It is a dictionnary with the following entries:
orig_remote_addr = environ_get("REMOTE_ADDR")
orig_wsgi_url_scheme = environ_get("wsgi.url_scheme")
orig_http_host = environ_get("HTTP_HOST")
"werkzeug.proxy_fix.orig": {
"REMOTE_ADDR": orig_remote_addr,
"wsgi.url_scheme": orig_wsgi_url_scheme,
"HTTP_HOST": orig_http_host,
"SERVER_NAME": environ_get("SERVER_NAME"),
"SERVER_PORT": environ_get("SERVER_PORT"),
"SCRIPT_NAME": environ_get("SCRIPT_NAME"),
}
All those sub-entries are already allow-listed by the Odoo's HTTPRequest class.
Accessing those values is handy when debugging the --proxy-mode, it allows to see at a glance if the proxy-mode was effective for this request: the `werkzeug.proxy_fix.orig` entry is present; or not: the entry is absent.
Forward-Port-Of: odoo/odoo#169446
Forward-Port-Of: odoo/odoo#168841The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf (due to `update_available_quantity` that do a `_gather` on current stock). All the metrics below are made with 50 000 SN already in stock Before (in seconds): || Receipt | Delivery | |--------|--------|--------| |100| 1.63 | 34.21 | |5000| 87.04 | 242.56 | |30 000| 563.75 | T.O. | After:
Original PR description
The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf…
The purpose of this PR is to be able to process a lot of serial numbers at once. In receipt and deliveries In the current situation, the number of serial already in stock has an impact on the perf (due to `update_available_quantity` that do a `_gather` on current stock). All the metrics below are made with 50 000 SN already in stock Before (in seconds): || Receipt | Delivery | |--------|--------|--------| |100| 1.63 | 34.21 | |5000| 87.04 | 242.56 | |30 000| 563.75 | T.O. | After: || Receipt | Delivery | |--------|--------|--------| |100| 0.91 | 5.62 | |5000| 47.21 | 56.28 | |30 000| 195.27 | 307.80 | By operations/ receipts (for 5000): | | action_assign | button_validate | total | |--------|--------|--------|--------| | Before patch | 5.38 | 82.02 | 87.04 | | After patch | 3.82 | 43.39 | 47.21 | By operations/ deliveries (for 5000): | | action_assign | button_validate | total | |--------|--------|--------|--------| | Before patch | 180.06 | 62.50 | 242.56 | | After patch | 20.51 |35.77 | 56.28 | The main issues: - The constraint check on quant/stock.move.line are done one by one since there is nothing done in batch, same for computed field (Not fixed here)  - The put away takes an important amount of times without any putaways rules  - The optimisation made in #116803 was a good idea but it was only use in action_assign. `_action_assign` use strict=False in `_gather` (mts case). It means a child_of operator is in the domain, and it will perform an extra query anyway - The lot_name matching to lot_id is made `stock.move.line` by `stock.move.line` on 30 000, half of the time is spent to find them.  After some testing. The quant_cache could contain too many items than needed by the current operation. Example receive 1 serial number (that will not have an existing quant) will use a quant_cache with all the serial number of the products. As a result, the group by will be super slow. Allow to add an extra domain, to limit the cache size. /!\ could be dangerous if it filter out too much  Forward-Port-Of: odoo/odoo#158229 Forward-Port-Of: odoo/odoo#146494
Hongkong was removed from tzdata in ubuntu Noble, `Asia/Honk_Kong` must be used instead. Forward-Port-Of: odoo/odoo#170146
Original PR description
Hongkong was removed from tzdata in ubuntu Noble, `Asia/Honk_Kong` must be used instead. Forward-Port-Of: odoo/odoo#170146
### Steps to reproduce (on mobile mode): - Go to Expenses app - Create a new expense - Select 'Company' for the 'Paid By' field - Action > Create Report - Click on the field 'Payment Method' - The view displayed does not show the journals, so there can be several 'Manual' for example ### Cause: There are no kanban view for account.payment.method.line and the default one only shows the name and not the journal. ### Solution: Create a new kanban view for account.payment.method.line t
Original PR description
### Steps to reproduce (on mobile mode): - Go to Expenses app - Create a new expense - Select 'Company' for the 'Paid By' field - Action > Create Report - Click on the field 'Payment Method' - The view displayed does not show the journals, so there can be several 'Manual' for example ### Cause: There are no kanban view for account.payment.method.line and the default one only shows the name and not the journal. ### Solution: Create a new kanban view for account.payment.method.line that displays the journal. opw-3896011 Forward-Port-Of: odoo/odoo#167797
Commit 95726f3d99ba7cf5796a9acd1c13a631db63fbd7 made it so that rewards are archived instead of unlinked when linked to a specific SO/PO, but forgot to bypass access rights to search the linked PO/SO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170094
Original PR description
Commit 95726f3d99ba7cf5796a9acd1c13a631db63fbd7 made it so that rewards are archived instead of unlinked when linked to a specific SO/PO, but forgot to bypass access rights to search the linked PO/SO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170094
Before this commit: The version of the IoT was ambiguous and was needed to be updated manually for windows. As windows IoT does not have the concept of "image" (as it depends on the installer build) the version should give this information. This information can be found in odoo release.py file Benefit from this PR to add more details on the IoT box version to also give more information as an IoT box can be on a certain image and "code release" independently. The image shown on the homepage
Original PR description
Before this commit: The version of the IoT was ambiguous and was needed to be updated manually for windows. As windows IoT does not have the concept of "image" (as it depends on the installer build) the version should give this information. This information can be found in odoo release.py file Benefit from this PR to add more details on the IoT box version to also give more information as an IoT box can be on a certain image and "code release" independently. The image shown on the homepage is the same as before, but the detailed/revision information is now sent to the odoo's synced server in order to be visible and used by the support After this commit: Windows IoT version: - Before: W22_11 - After: W22.11 (detailed version: `W22.11-16.0+e-20240412` ) IoT box version: - Before: 24.01 - After: L24.01 (detailed version: `L24.01-16.0#71bd27465` ) Forward-Port-Of: odoo/odoo#169368 Forward-Port-Of: odoo/odoo#163697
The is_explicit attribute was useful to prevent saving a session when the session_id was coming from an untrusted source (e.g. a client forged http header). We removed the feature to set explicit headers, the attribute is gone, we forgot to adapt this one. Forward-Port-Of: odoo/odoo#169185
Original PR description
The is_explicit attribute was useful to prevent saving a session when the session_id was coming from an untrusted source (e.g. a client forged http header). We removed the feature to set explicit headers, the attribute is gone, we forgot to adapt this one. Forward-Port-Of: odoo/odoo#169185
To display rewards for gift cards and e-wallets in debug mode (where rules and rewards were hidden by default), a kanban view for rewards was duplicated in a previous bugfix (related to Commit 3e1b12961d1a2c4bd83863a151ac1bb780e3abf1) inside `loyalty_program_view_form`. This led to an error when trying to render the rewards kanban view a second time in debug mode. To solve this, the kanban view for rewards has been moved directly into the `loyalty_program_gift_ewallet_view_form`, replacing bo
Original PR description
To display rewards for gift cards and e-wallets in debug mode (where rules and rewards were hidden by default), a kanban view for rewards was duplicated in a previous bugfix (related to Commit 3e1b12961d1a2c4bd83863a151ac1bb780e3abf1) inside `loyalty_program_view_form`. This led to an error when trying to render the rewards kanban view a second time in debug mode. To solve this, the kanban view for rewards has been moved directly into the `loyalty_program_gift_ewallet_view_form`, replacing both rules and rewards by just rewards (in debug mode only). This prevents duplication and rendering errors. opw-3903363 Forward-Port-Of: odoo/odoo#169877 Forward-Port-Of: odoo/odoo#164396
Issue: ====== Clicking enter in a banner inside a list breaks the layout in chrome browser. Steps to reproduce the issue: ============================= - Open chrome browser - Go to to-do - Create a list and add 1 item - Click enter (Second element of the list) and add a banner in the item - Click enter - Doesn't work as expected Origin of the issue: ==================== This is a browser issue, chrome in this specific case doesn't work properly, all the events until `textInput
Original PR description
Issue: ====== Clicking enter in a banner inside a list breaks the layout in chrome browser. Steps to reproduce the issue: ============================= - Open chrome browser - Go to to-do - Create a…
Issue:
======
Clicking enter in a banner inside a list breaks the layout in chrome browser.
Steps to reproduce the issue:
=============================
- Open chrome browser
- Go to to-do
- Create a list and add 1 item
- Click enter (Second element of the list) and add a banner in the item
- Click enter
- Doesn't work as expected
Origin of the issue:
====================
This is a browser issue, chrome in this specific case doesn't work properly, all the events until `textInput` are called when clicking `enter` but the last event is never triggerged which is the `input` event. The specific case can be reproduced with this:
```
<div contenteditable="true">
<ul>
<div contenteditable="false">
<div contenteditable="true">
<p>
text[]
</p>
</div>
</div>
</ul
</div>
```
Solution:
==========
We manually trigger the `input` event in this specific case.
Issue:
======
List inside a banner under a list doesn't align correctly
steps to reproduce the issue:
=============================
- Go to do
- Add a list and first item
- Add a banner
- Add a list inside the banner
- It's not correctly centered
Origin of the issue:
====================
Since the list inside the banner is considered nested list under the top
list, the `margin-bottom` is removed.
Solution:
=========
Reassign the style again when we are inside the banner.
task-3857296
Forward-Port-Of: odoo/odoo#162204Commit [1] introduced a way for an editable list view to open the record inside a form view in the current window (adding itself to the breadcrumb) when clicked. It's done by adding a `open_form_view` attribute on the tree node, which then adds automatically a "View" button/action on each tree lines. But there was an unseen issue where when that x2m (tree) field was set as readonly, the button would not be shown, preventing the navigation. [1]: https://github.com/odoo/odoo/commit/258e6a
Original PR description
Commit [1] introduced a way for an editable list view to open the record inside a form view in the current window (adding itself to the breadcrumb) when clicked. It's done by adding a `open_form_view` attribute on the tree node, which then adds automatically a "View" button/action on each tree lines. But there was an unseen issue where when that x2m (tree) field was set as readonly, the button would not be shown, preventing the navigation. [1]: https://github.com/odoo/odoo/commit/258e6a019a21042bf4f6cf70fcce386d37afd50c task-3973116 Forward-Port-Of: odoo/odoo#170106
When unlocking a picking and adding a new line, the 'picked' field would be False for both the new stock.move and stock.move.line. The main issue it creates is that no stock.valuation.layer would be created on stock_account. https://github.com/odoo/odoo/assets/29302288/f11b7122-dd64-40f3-a0c3-1de6f442c9b7 OPW-3980565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169816
Original PR description
When unlocking a picking and adding a new line, the 'picked' field would be False for both the new stock.move and stock.move.line. The main issue it creates is that no stock.valuation.layer would be created on stock_account. https://github.com/odoo/odoo/assets/29302288/f11b7122-dd64-40f3-a0c3-1de6f442c9b7 OPW-3980565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169816
Have a list view grouped by 2 fields (e.g. Contacts: Salesperson > name). Open a group which contains more groups than the limit (set the groups_limit attribute on the arch if necessary). Next to the name of the group, the total number of records belonging to that group is displayed (e.g. Mitchel Admin (32)). In the group header row, the pager allows to browser the inner **groups**, so the total displayed there is the total number of inner groups in that group (e.g. 1-10 / 31). From that poi
Original PR description
Have a list view grouped by 2 fields (e.g. Contacts: Salesperson > name). Open a group which contains more groups than the limit (set the groups_limit attribute on the arch if necessary). Next to the…
Have a list view grouped by 2 fields (e.g. Contacts: Salesperson > name). Open a group which contains more groups than the limit (set the groups_limit attribute on the arch if necessary). Next to the name of the group, the total number of records belonging to that group is displayed (e.g. Mitchel Admin (32)). In the group header row, the pager allows to browser the inner **groups**, so the total displayed there is the total number of inner groups in that group (e.g. 1-10 / 31). From that point, clicking on a column header to sort by a given field produces a reload, and the group pager is updated with the wrong total: it now displays the number of records, not the number of groups (1-10 / 32 in the example). This commit fixes that issue. The test also hihglighted another issue: when reloaded, we sometimes have to keep former groups that became empty and that weren't returned by the last call to web_read_group (e.g. we drag and dropped the last record from a group to another group). We only do that if search query parameters didn't change. However, we forgot to take the orderBy into account, so when sorting groups, groups that were no longer on the current page were still displayed, with count 0. This commit also fixes that issue. 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#170099
Previously, the validation error message contained HTML content. This PR converts the error message into plain text. Task-3989829 Forward-Port-Of: odoo/odoo#169733
Original PR description
Previously, the validation error message contained HTML content. This PR converts the error message into plain text. Task-3989829 Forward-Port-Of: odoo/odoo#169733
When the arguments for the creation of the SpreadsheetPivotTable are computed, an array was created for each subgroups (due to `concat`). This allows to reduce by +/- 62% the time spent in the creation of the arguments. It was done by using `push` instead of `concat`. Note that `splice` has been evaluated but it was sightly slower than `push`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confir
Original PR description
When the arguments for the creation of the SpreadsheetPivotTable are computed, an array was created for each subgroups (due to `concat`). This allows to reduce by +/- 62% the time spent in the creation of the arguments. It was done by using `push` instead of `concat`. Note that `splice` has been evaluated but it was sightly slower than `push`. 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#170159
Activate a second lang (ex French) and set it to the demo user Set "Cash Discount Tax Reduction" to "Always" Create an invoice with tax Set Payment term to "2/7 Net 30" [1] Go to "journal items" tab Early payment discount lines are set correctly Now with the demo user create a credit note for the invoice Issue: Additional journal item is created, which cancels out the tax refund. This occurs because in https://github.com/odoo-dev/odoo/commit/5a256af35e5d612efed9ed8af1cf23fd62bd83f4
Original PR description
Activate a second lang (ex French) and set it to the demo user Set "Cash Discount Tax Reduction" to "Always" Create an invoice with tax Set Payment term to "2/7 Net 30" [1] Go to "journal items" tab Early payment discount lines are set correctly Now with the demo user create a credit note for the invoice Issue: Additional journal item is created, which cancels out the tax refund. This occurs because in https://github.com/odoo-dev/odoo/commit/5a256af35e5d612efed9ed8af1cf23fd62bd83f4 we addressed a duplicated key in the `existing` dict with a workaround: we add a translated 'Discount' term to the line name and if we detect it later at tax key creation we change the display_type. Unfortunately this works only if the two operations are performed with the same lang context. [1] Payment terms: 30 Days, 2% Early Payment Discount under 7 days opw-3922267 Forward-Port-Of: odoo/odoo#170058 Forward-Port-Of: odoo/odoo#169881
Incorporate Andrea Manenti (maneandrea) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170040
Original PR description
Incorporate Andrea Manenti (maneandrea) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170040
### Steps to reproduce the issue: 1. Go to _Accounting > Customers > Follow-up Reports_ select one of the reports 2. Click on "Follow up" 3. Open the template in the Content Template field 4. Empty the To (Partners) field in this template 5. Save and close 6. Close the Follow Up and reopen it 5. There is no address in the field ### Explanation: With previous fix, we removed the `default_get` value but did not add a default one in the compute. ### Suggested fix: The default v
Original PR description
### Steps to reproduce the issue: 1. Go to _Accounting > Customers > Follow-up Reports_ select one of the reports 2. Click on "Follow up" 3. Open the template in the Content Template field 4. Empty the To (Partners) field in this template 5. Save and close 6. Close the Follow Up and reopen it 5. There is no address in the field ### Explanation: With previous fix, we removed the `default_get` value but did not add a default one in the compute. ### Suggested fix: The default value will be the same as the one previously in `default_get`. The purpose is to restore the previous workflow and then add the template's values. opw-3878125 Forward-Port-Of: odoo/enterprise#65038 Forward-Port-Of: odoo/enterprise#64902
When settling a sale order with recurring product, the qty invoiced is not correctly update on the sale order. Steps to reproduce: ------------------- * Install Point of Sale and Sale Subscription * Create a recurring product A * Create a sale order with the product A and select any subscription plan * Open a PoS session, settle the order, validate it and invoice it * Go back to the sale order > Observation: The invoiced quantity is still 0 Why the fix: ------------ Before this fi
Original PR description
When settling a sale order with recurring product, the qty invoiced is not correctly update on the sale order. Steps to reproduce: ------------------- * Install Point of Sale and Sale Subscription * Create a recurring product A * Create a sale order with the product A and select any subscription plan * Open a PoS session, settle the order, validate it and invoice it * Go back to the sale order > Observation: The invoiced quantity is still 0 Why the fix: ------------ Before this fix the `_get_subscription_qty_invoiced` method was not considering the pos_order_lines linked to the order_lines. It was happening because here https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/sale_subscription/models/sale_order_line.py#L189-L196 The order lines with recurring product where not considered in the normal invoiced quantity computation. opw-3992577 Forward-Port-Of: odoo/enterprise#64891
Resolve issue when having a positive equity capital in the chosen report year and having a negative equity capital in the latest comparison period. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#64748
Original PR description
Resolve issue when having a positive equity capital in the chosen report year and having a negative equity capital in the latest comparison period. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#64748
In accounting, when exporting journal report to pdf, the Taxes Applied table size is limited thus forcing long number to wrap. Steps to reproduce: 1.go to Accounting > Reporting > Audit Reports > Journal Report 2.click on Pdf button 3.the "Taxes Applied" table will be spanning accross 2 column of the parent table leading to wrapped values Cause: "Taxes Applied" and "Tax Grid" are sharing the same row to render 2 different table and there is not enough room especially if the numbers are
Original PR description
In accounting, when exporting journal report to pdf, the Taxes Applied table size is limited thus forcing long number to wrap. Steps to reproduce: 1.go to Accounting > Reporting > Audit Reports > Journal Report 2.click on Pdf button 3.the "Taxes Applied" table will be spanning accross 2 column of the parent table leading to wrapped values Cause: "Taxes Applied" and "Tax Grid" are sharing the same row to render 2 different table and there is not enough room especially if the numbers are long. Solution: Up the colspan for "Taxes Applied" to 3, not the ideal solution if each column are diplayed and filled with long numbers but it is stable friendly. + this issue is fixed in 17.3 opw-3959560 Forward-Port-Of: odoo/enterprise#64467
Forward-Port-Of: odoo/enterprise#64863
Original PR description
Forward-Port-Of: odoo/enterprise#64863
This commit fixes an issue where the retweeted message would only display a part of the retweeted message while twitter displays it in full. This is a limitation of the Twitter API which only sends a limited part of the tweet. To fix this, we are setting the message value to the text of the referenced tweet. task-3653108 Forward-Port-Of: odoo/enterprise#59579 Forward-Port-Of: odoo/enterprise#55642
Original PR description
This commit fixes an issue where the retweeted message would only display a part of the retweeted message while twitter displays it in full. This is a limitation of the Twitter API which only sends a limited part of the tweet. To fix this, we are setting the message value to the text of the referenced tweet. task-3653108 Forward-Port-Of: odoo/enterprise#59579 Forward-Port-Of: odoo/enterprise#55642
Only load relevant MOs based on the workcenters that are shown in the view and reintroduce a limit to the amount of MOs that can be loaded simultaneously into the view. task-3895017 Forward-Port-Of: odoo/enterprise#64551
Original PR description
Only load relevant MOs based on the workcenters that are shown in the view and reintroduce a limit to the amount of MOs that can be loaded simultaneously into the view. task-3895017 Forward-Port-Of: odoo/enterprise#64551
Versions -------- - 15.0+ Steps ----- 1. Sync with Google Calendar; 2. create a recurrent all day event in google calendar; 3. make sure it shows as "busy"; 4. make an appointment via website on that day. Issue ----- You are allowed to make an appointment on slots that overlap the synced event. Cause ----- Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end. Commi
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Sync with Google Calendar; 2. create a recurrent all day event in google calendar; 3. make sure it shows as "busy"; 4. make an appointment via website on that…
Versions -------- - 15.0+ Steps ----- 1. Sync with Google Calendar; 2. create a recurrent all day event in google calendar; 3. make sure it shows as "busy"; 4. make an appointment via website on that day. Issue ----- You are allowed to make an appointment on slots that overlap the synced event. Cause ----- Recurrent day events synced via Google Calendar have their start & end date equal to each other, so the event's "end date" could be 24 hours before the actual end. Commit ad4219876cee4f4b996a7cc72fd176b51be3a063 added an the `_slot_availability_prepare_values_meetings` method, optimized to not include conditions on `start_date` and `allday`. Instead, it filters event by date ranges. In our scenario, an `allday` event with start & end dates set to something like `2022-02-14 00:00:00`, may get excluded from the search when this is also the value of the starting point of the search, due to `stop` not being strictly greater than the starting point. Solution -------- Do an inclusive range search instead of an exclusive one. opw-3793009 Forward-Port-Of: odoo/enterprise#65023 Forward-Port-Of: odoo/enterprise#63761
This PR update the Demo Campaign Double Opt-in's Trigger Value to 0 Hour, so that subscribers of a newsletter get a close-to instant confirmation instead of an hour later. Task-3976448 Forward-Port-Of: odoo/enterprise#64998
Original PR description
This PR update the Demo Campaign Double Opt-in's Trigger Value to 0 Hour, so that subscribers of a newsletter get a close-to instant confirmation instead of an hour later. Task-3976448 Forward-Port-Of: odoo/enterprise#64998
Added support for currency_rate from the world oldest central bank, Sveriges Riksbank. Forward-Port-Of: odoo/enterprise#64344
Original PR description
Added support for currency_rate from the world oldest central bank, Sveriges Riksbank. Forward-Port-Of: odoo/enterprise#64344