Monday, May 3, 2021
37 changes · master
Enhancements to existing features
The web interface can now load complete groups of templates in one request instead of fetching individual files. This improves efficiency for parts of Odoo that load on demand and ensures template customizations are applied consistently.
Original PR description
Previously, lazy-loading xml templates was only possible by fetching the xml file directly, this meant that it was impossible to lazy-load an entire bundle's templates with a single request. Additionally, requesting the xml files directly meant that no inheritance was applied, causing the need for a separate inheritance system using t-jquery on the client-side. This commit alters the /web/webclient/qweb route so that it now takes an optional bundle id, meaning that it is now possible to lazy-load the xml from arbitrary bundles. task-2497943
When an individual contact is linked to a company but has no company image set, the contact card now shows a company-style placeholder instead of a generic camera icon. This makes company-related contacts easier to recognize visually and improves consistency in the contact overview.
Original PR description
taskid: 2491161 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
Project configuration screens were made easier to use with clearer labels, better field placement, and updated helper text for stages and tags. These changes help users manage task stages and categorize work more efficiently, while also cleaning up unused styling.
Original PR description
Purpose of the task is to do a generic UX improvement in project Specification: -------------- 1) Stages(project.task.type) * List view: - move the 'folded in kanban' field to the right of the…
Purpose of the task is to do a generic UX improvement in project Specification: -------------- 1) Stages(project.task.type) * List view: - move the 'folded in kanban' field to the right of the project_ids one - remove the description field from the list view - make the list view editable in batch * Form view: - rename 'stage name' into 'name' - move the sequence field below the 'rating email template' one - change the copy of the tooltips to: "At each stage, employees can block tasks or mark them as ready for the next step. You can customize here the labels for each state." - the tags should be colored according to the project's color - reduce the space in between the icons and the name of the states - add some space in between the legend_done field and the description - when creating a new mail template, set 'project.task' as model_id of the template * move the 'Stages' menu into below the 'Projects' one * add the project_ids field to the kanban view * search: rename 'Tasks Stages' into 'Name' 2) Tags(project.tags): - configuration > tags menu: change the helper to: "Tags are perfect for categorizing your tasks." - add an optional list view -> only the color field should be optional and displayed by default - new tags should be created at the top of the list - Also removed some of the unused(deprecated) css which are not applied anywhere in the project. TaskID: 2508642
This change improves how Odoo Mail processes automatic field updates so required-field checks happen at the right time. It reduces false validation errors and avoids unnecessary checks on records removed during the same update cycle, making mail-related interactions more reliable.
Original PR description
There is currently a limitation with required fields because an "on change" compute might trigger the check for "required" before all the actual computes have been done, leading to the required field check incorrectly failing. The main goal is to ensure the "on change" computes are done after all the other computes and after the check for required fields. A check has also been added to ensure no "real" compute can trigger update cycle side-effects anymore. Opportunity is also taken to prevent from checking for required fields on a record that was deleted as part of the same update cycle. Somewhat part of task-2278551
Odoo’s internal registry setup was optimized so servers can start faster, especially when many modules are installed. The change reduces repeated setup work across registries and improves bootstrapping time, while keeping behavior largely unchanged for business users.
The mail app now handles thread viewer updates through each related model rather than relying on many shared dependencies. This makes the thread viewing experience easier to maintain and adapt across different areas of Odoo, with minimal direct impact on end users.
Original PR description
Instead of thread viewer having many dependencies, this allows models "having the thread viewer feature" to keep their own logic for themselves. The "create or update" part has to be done manually in this case (as opposed to using "insert") because thread viewer has no clear identifying data, since it would depend on which model is using it in the first place.
This update supports faster setup of core system components by making some internal field behavior explicit. It helps improve reliability during system startup and module loading, with no expected day-to-day workflow changes for users.
Original PR description
Companion of https://github.com/odoo/odoo/pull/69924.
The Helpdesk stage form now aligns its legend fields more consistently, matching the layout used in project stages. This makes the configuration screen cleaner and easier for users to read without changing any underlying helpdesk behavior.
Original PR description
Currently, in the helpdesk stages legend_* fields are not properly aligned. so in this commit, align the legend fields on helpdesk stage same as aligned in the project stages. TaskID: 2508642
Resolved issues and error corrections
Fixed an issue in the Calendar view where hovering over a responsible person could show a default camera image instead of the correct avatar. This restores the expected visual preview and helps users quickly identify people in the calendar sidebar.
Original PR description
delete redundant '}' added by another developer by accident taskid: 2504659
Miscellaneous changes
Documents a known limitation in Odoo's web JavaScript tooling around exported objects that contain comments. This helps developers avoid patterns that can cause generated code to be incorrect, reducing troubleshooting time for web customizations.
Original PR description
Before this commit, the js_transpiler did not convert object exports containing a comment. This commit will modify the regex EXPORT_OBJECT_RE and EXPORT_FROM_RE so that they match all characters…
Before this commit, the js_transpiler did not convert object exports
containing a comment.
This commit will modify the regex EXPORT_OBJECT_RE and EXPORT_FROM_RE
so that they match all characters between { and }.
Example:
```js
export {
a // this is a comment
}
export {
a // this is a comment
}
```
Output before this commit (no modification is applied)
```js
export {
a // this is a comment
}
export {
a // this is a comment
} from "@addon/path"
```
Output after this commit
```js
Object.assign(__exports, {
a // this is a comment
})
{const {
a // this is a comment
} = require("@addon/path");Object.assign(__exports, {
a // this is a comment
})};
```
Limitation:
It is still impossible to have a comment containing `}` inside
an exported object. The js_tranpiler will generate wrong code
if this happens.
Example:
```js
export {
a // this is a comment with }
}
```
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-prOriginal PR description
This proposes a new implementation of * the "discovery" of fields on a given model; * the setup of fields; * the sharing of fields across registries. This new implementation makes the registry…
This proposes a new implementation of * the "discovery" of fields on a given model; * the setup of fields; * the sharing of fields across registries. This new implementation makes the registry loading faster. Our benchmark is two registries with 296 modules (all community modules). Both registries have the same models, so we can see how sharing across registries can save time and/or memory. Here are time measurements for loading both registries (from scratch): Time | before | after | difference ---|---|---|--- Loading Odoo modules | 1176ms | 1339ms | +14% Loading registry 1 | 2042ms | 1067ms | -48% Loading registry 2 | 990ms | 970ms | -2% As we can see, there is some extra work done when loading Odoo modules, but this extra work is done once for all registries using those modules. However, this price is largely compensated by the speedup when loading a registry. Notice also that the net time to load a registry no longer depends whether other registries are present in the server. Overall, the loading of the first registry goes from 3218ms to 2406ms, which is 25% faster. In other words, the bootstrapping time of a server is smaller.
This fixes spelling and grammar mistakes in the Project onboarding tour messages. The change makes the guided setup text easier to understand for users, with no change to functionality.
Original PR description
There are some grammatical mistakes and spelling mistakes in the tour message. This commit fixes these mistakes. TaskID: 2508637 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Helpdesk Sales Timesheet app now correctly waits for the related Helpdesk Sales app to be installed first. This prevents rare installation crashes and avoids running tests unexpectedly outside normal test mode.
Original PR description
1) This PR add a mandatory dependency between helpdesk_sale and helpdesk_sale_timesheet in order to make sure the first is installed before the second. 2) This PR removes a non-mandatory import which implies that tests are executed even when --test-enable is not added.
The Sign app now hides an unnecessary extra options button in the signer list for system administrators. This avoids confusion by removing a control that does not apply to this signer display.
Original PR description
An optionalColumnsDropdwon (ellipsis-v icon) will be added to a listview if the user is a system admin. The signer_ids is shown as a listview, but not a normal table here. We just hide the optionalColumnsDropdown button only for this field. taskid: 2508599
What are the steps to reproduce your issue ? 1. Create a contact and set 'VAT' to "20AAACT2803M2ZO". The 'GST Treatment' will be automatically set correctly. 2. Create a sale order for this new contact. GST Treatment is automatically filled in correctly. 3. Confirm the order. 4. Create an invoice. What is currently happening ? The related invoice does not fetch the 'GST Treatment' automatically What are you expecting to happen ? The related invoice must
Original PR description
What are the steps to reproduce your issue ?
1. Create a contact and set 'VAT' to "20AAACT2803M2ZO". The 'GST Treatment' will be automatically set correctly.
2. Create a sale order for this new contact. GST Treatment is automatically filled in correctly.
3. Confirm the order.
4. Create an invoice.
What is currently happening ?
The related invoice does not fetch the 'GST Treatment' automatically
What are you expecting to happen ?
The related invoice must set the 'GST Treatment' automatically.
opw-2499503
Forward-Port-Of: odoo/odoo#69392On creating a new note, the focus was automatically set into the "tags" field. This was inconvenient and was replaced with an autofocus on the note itself so we the user can immediately start typing. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70179
Original PR description
On creating a new note, the focus was automatically set into the "tags" field. This was inconvenient and was replaced with an autofocus on the note itself so we the user can immediately start typing. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70179
Steps to follow to reproduce the bug : - Install the Repairs and Accounting application - Create a new user and give him only access to Accounting - Connect with this user - Create a draft invoice - Try to delete it - Access rights error is triggered. Problem: When we delete an invoice and the Repairs app is installed, we check if it is not an invoice related to a repair. But the user does not have access to “repair.order”, so we can not check the field "repair_ids". opw-2507867
Original PR description
Steps to follow to reproduce the bug : - Install the Repairs and Accounting application - Create a new user and give him only access to Accounting - Connect with this user - Create a draft invoice - Try to delete it - Access rights error is triggered. Problem: When we delete an invoice and the Repairs app is installed, we check if it is not an invoice related to a repair. But the user does not have access to “repair.order”, so we can not check the field "repair_ids". opw-2507867 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#69701
- Create SO with deliverable product, confirm - Change delivery Address on SO and on Transfer - Inventory > Stock moves (debug mode) - Group by > Picking and Destination address The address shows is the original and not the updated one. opw-2429018 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:
Original PR description
- Create SO with deliverable product, confirm - Change delivery Address on SO and on Transfer - Inventory > Stock moves (debug mode) - Group by > Picking and Destination address The address shows is the original and not the updated one. opw-2429018 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#66630 Forward-Port-Of: odoo/odoo#66031
- Create a service product with cost 0 - Create a sales quotation - Add the service product, change the cost to a positive quantity - Save and Confirm. Purchase Price (cost) will be reset to 0 opw-2481564 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#69966
Original PR description
- Create a service product with cost 0 - Create a sales quotation - Add the service product, change the cost to a positive quantity - Save and Confirm. Purchase Price (cost) will be reset to 0 opw-2481564 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#69966
425000 current assets rather than current liabilities. 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#70163
Original PR description
425000 current assets rather than current liabilities. 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#70163
Before this commit, if any workorder is stared to produce, qty producing was 0. After this commit, if product tracking is none then system will suggest the remaining qty of workorder to produce when user is start it. TaskId - 2480775 Forward-Port-Of: odoo/odoo#70153
Original PR description
Before this commit, if any workorder is stared to produce, qty producing was 0. After this commit, if product tracking is none then system will suggest the remaining qty of workorder to produce when user is start it. TaskId - 2480775 Forward-Port-Of: odoo/odoo#70153
Odoo task : https://www.odoo.com/web#id=2499653&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70189
Original PR description
Odoo task : https://www.odoo.com/web#id=2499653&action=333&active_id=1695&model=project.task&view_type=form&cids=1&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70189
Previously, when toggling on background shapes, they always had the default colours. In 1e30bce81eb8deb732747f8964ebd7fcd78c802c we made it so that when you toggle on a shape on a section, it would automatically reuse the colors of the surrounding shapes if any. Unfortunately, when the "implicit" colors were also the default colors, they were still marked on the shape, and it got an explicit background image that would no longer react to changes in the palette. This was caused by the
Original PR description
Previously, when toggling on background shapes, they always had the default colours. In 1e30bce81eb8deb732747f8964ebd7fcd78c802c we made it so that when you toggle on a shape on a section, it would…
Previously, when toggling on background shapes, they always had the default colours. In 1e30bce81eb8deb732747f8964ebd7fcd78c802c we made it so that when you toggle on a shape on a section, it would automatically reuse the colors of the surrounding shapes if any. Unfortunately, when the "implicit" colors were also the default colors, they were still marked on the shape, and it got an explicit background image that would no longer react to changes in the palette. This was caused by the fact that the call to _getDefaultColors returns an empty object when the section doesn't already have a shape-container, this was not a problem before since we were not passing in any colors when creating the initial shape previously, the the aforementioned change made it so that we did. This commit fixes the issue by creating the shape-container before calling the method that will set the colors on the shape, this way getDefaultColors works as expected, and the colors are not marked on the section when they are the default ones, restoring the ability of the shape colors to adapt to the palette task-2500607 Co-authored-by: Tom De Caluwé <tdc@odoo.com> Forward-Port-Of: odoo/odoo#68893
Add the name of argument, if not `precision_digits` is used in `float_compare`. Description of the issue/feature this PR addresses: The float compare doesn't work properly. Current behavior before PR: Wrong products_availability_state Desired behavior after PR is merged: Good products_availability_state @amoyaux -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70161
Original PR description
Add the name of argument, if not `precision_digits` is used in `float_compare`. Description of the issue/feature this PR addresses: The float compare doesn't work properly. Current behavior before PR: Wrong products_availability_state Desired behavior after PR is merged: Good products_availability_state @amoyaux -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70161
Without this commit, User was not allowed to create Unbuild Order for the product without BoMs from Unbuild Orders menu. But User was able to create Unbuild Order using 'Unbuild Order' button on MO. With this commit, We are allowing user to select Products without BoMs to make this behavior consistent so user can create Unbuild Order from Unbuild Orders menu. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70217
Original PR description
Without this commit, User was not allowed to create Unbuild Order for the product without BoMs from Unbuild Orders menu. But User was able to create Unbuild Order using 'Unbuild Order' button on MO. With this commit, We are allowing user to select Products without BoMs to make this behavior consistent so user can create Unbuild Order from Unbuild Orders menu. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70217
Steps to follow to reproduce the bug: - Install Inventory and Purchase - In the inventory settings, Enable the "Landed Costs" option - Go to Purchase > create a Service type product - In the Purchase tab > Enable "is landed cost" option and choose "by quantity" in the default split method - Go to Orders > Requests for quotation > Create a new RFQ > add Any product and confirm the order - Validate receipt of the product - Create a bill > add the Service you created at the beginning - Crea
Original PR description
Steps to follow to reproduce the bug: - Install Inventory and Purchase - In the inventory settings, Enable the "Landed Costs" option - Go to Purchase > create a Service type product - In the Purchase tab > Enable "is landed cost" option and choose "by quantity" in the default split method - Go to Orders > Requests for quotation > Create a new RFQ > add Any product and confirm the order - Validate receipt of the product - Create a bill > add the Service you created at the beginning - Create Landed Costs Problem: we do not use the split method landed cost of the product, we automatically set it to "equal" opw-2465753 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#69973
When selling a tracked product that comes from a specific place in the warehouse, the module will ignore this information and set the parent warehouse as source location. To reproduce the error: (Use demo data) 1. In Settings, enable "Multi-Warehouses" 2. Create a product P: - Product Type: Storable Product - Available in Pos: True - Tracking: By Unique Serial Number 3. Update its quantity: - Location: WH/Stock/Shelf 1 - Serial Number: USN01 - Qty: 1 4. St
Original PR description
When selling a tracked product that comes from a specific place in the
warehouse, the module will ignore this information and set the parent
warehouse as source location.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Multi-Warehouses"
2. Create a product P:
- Product Type: Storable Product
- Available in Pos: True
- Tracking: By Unique Serial Number
3. Update its quantity:
- Location: WH/Stock/Shelf 1
- Serial Number: USN01
- Qty: 1
4. Start a POS session
5. Sell P
- Enter the same serial number
6. Go back to quantity update page for product P
Error: The quantity for "WH/Stock/Shelf 1, USN01" is still 1, it should
be 0. Moreover, a new line appeared: "WH/Stock, USN01, -1" which is
incorrect. The POS module considered that the product sold came from
WH/Stock instead of WH/Stock/Shelf 1.
OPW-2473002
Forward-Port-Of: odoo/odoo#70169
Forward-Port-Of: odoo/odoo#69750Some feature descriptions and titles have been reworded. A sentence has been added below the title to indicate that choices made on this screen are not definitive. Task ID: 2451965 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#70237
Original PR description
Some feature descriptions and titles have been reworded. A sentence has been added below the title to indicate that choices made on this screen are not definitive. Task ID: 2451965 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#70237
Issue - In CRM settings, activate 'Leads' feature - Go to CRM -> Leads and open a Lead. - In customer section; - Select 'Link to an existing customer' - Select 'Deco Addict' as customer if related to an existing customer, neither the action or partner_id field is set to the right value. Cause Due to missing 'lead_id' field in template, the partner_id field is not recomputed since action is not recomputed. Solution Add 'lead_id' field as invisible. opw-243972
Original PR description
Issue - In CRM settings, activate 'Leads' feature - Go to CRM -> Leads and open a Lead. - In customer section; - Select 'Link to an existing customer' - Select 'Deco Addict' as customer if related to an existing customer, neither the action or partner_id field is set to the right value. Cause Due to missing 'lead_id' field in template, the partner_id field is not recomputed since action is not recomputed. Solution Add 'lead_id' field as invisible. opw-2439722 Forward-Port-Of: odoo/odoo#68618
*: website, website_event Remove some dead code introduced by the new editor merge at [1]. [1]: https://github.com/odoo/odoo/commit/499e8860f194a7eb09a2e224b713a362923d77ac Forward-Port-Of: odoo/odoo#70238
Original PR description
*: website, website_event Remove some dead code introduced by the new editor merge at [1]. [1]: https://github.com/odoo/odoo/commit/499e8860f194a7eb09a2e224b713a362923d77ac Forward-Port-Of: odoo/odoo#70238
Description of the issue/feature this PR addresses: The cookie bar alter the behaviour of the web_editor, messing the cookie bar up Current behavior before PR: When a user enables the cookie bar, the drop zone for snippets becomes the cookie bar and every snippets a user drops will end up in the cookie bar until he hides it. The cookie bar doesn't treat snippets nicely. Desired behavior after PR is merged: When the users enables the editor the cookie bar is hidden. -- I confirm I
Original PR description
Description of the issue/feature this PR addresses: The cookie bar alter the behaviour of the web_editor, messing the cookie bar up Current behavior before PR: When a user enables the cookie bar, the drop zone for snippets becomes the cookie bar and every snippets a user drops will end up in the cookie bar until he hides it. The cookie bar doesn't treat snippets nicely. Desired behavior after PR is merged: When the users enables the editor the cookie bar is hidden. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#68938
When changing the product price precision, this can lead to incorrect stock valuations. To reproduce the error: (Enable debug mode) 1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy 2. Edit Product Price: - Digits: 4 3. Create a Product Category PC: - Costing Method: FIFO 4. Create a Product P: - Product Type: Storable Product - Product Category: PC 5. Create a RfQ with product P: - Quantity: 1000 - Unit Price: 0.035 6. Confirm Order,
Original PR description
When changing the product price precision, this can lead to incorrect stock valuations. To reproduce the error: (Enable debug mode) 1. Go to Settings > Technical > Database Strucutre > Decimal…
When changing the product price precision, this can lead to incorrect
stock valuations.
To reproduce the error:
(Enable debug mode)
1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy
2. Edit Product Price:
- Digits: 4
3. Create a Product Category PC:
- Costing Method: FIFO
4. Create a Product P:
- Product Type: Storable Product
- Product Category: PC
5. Create a RfQ with product P:
- Quantity: 1000
- Unit Price: 0.035
6. Confirm Order, Receive Products, Validate
7. Click on Valuation
Error: The total value is equal to $40 instead of $35. The calculation
was done after rounding the unit price: $0.035 becomes $0.04, then
1000*0.04=$40.
When confirming the RfQ, a stock move is created. To do so, the method
`_get_stock_move_price_unit` is called. When validating the delivery, it
recomputes the unit price thanks to method `_get_price_unit`. In both
situation, and if the line has taxes, the method `compute_all` is called
like this:
```python
price_unit = line.taxes_id.with_context(round=False).compute_all(price_unit,
currency=line.order_id.currency_id, quantity=1.0)['total_void']
```
But here is the problem. In this method, total amount is computed with
this line:
```python
base = currency.round(price_unit * quantity)
```
However, `quantity` is equal to 1 and the multiplication is rounded
using the currency precision. As a result, `base` is equal to $0.04.
Then, all computations will use this value and will be incorrect.
This fix applies the real quantity so `base` will have the correct
value:
```
base = currency.round(price_unit * quantity)
= currency.round(0.035 * 1000)
= 35
```
OPW-2472192
Forward-Port-Of: odoo/odoo#70080
Forward-Port-Of: odoo/odoo#69297Previous to this PR: the tag CodImpAdic is used only for taxes with specific codes (24, 25, 26, 27). This tax is needed in the invoice lines, where this kind of tax applies. As we need the flexibility to add more taxes (i.e. meat taxes), and as they have different codes, it is more flexible if we using groups instead of tax codes. This way, we can add withholding taxes in a flexible fashion. Forward-Port-Of: odoo/enterprise#17454
Original PR description
Previous to this PR: the tag CodImpAdic is used only for taxes with specific codes (24, 25, 26, 27). This tax is needed in the invoice lines, where this kind of tax applies. As we need the flexibility to add more taxes (i.e. meat taxes), and as they have different codes, it is more flexible if we using groups instead of tax codes. This way, we can add withholding taxes in a flexible fashion. Forward-Port-Of: odoo/enterprise#17454
Steps to reproduce the bug: - Go to Accounting > Reporting > Trial Balance Bug: A traceback was raised opw:2516847 Forward-Port-Of: odoo/enterprise#17954
Original PR description
Steps to reproduce the bug: - Go to Accounting > Reporting > Trial Balance Bug: A traceback was raised opw:2516847 Forward-Port-Of: odoo/enterprise#17954
Before this, when a workorder was started to produce, qty producing was 0. After this commit, system will suggest the qty to produce instead of 0. TaskId - 2480775 Forward-Port-Of: odoo/enterprise#18063
Original PR description
Before this, when a workorder was started to produce, qty producing was 0. After this commit, system will suggest the qty to produce instead of 0. TaskId - 2480775 Forward-Port-Of: odoo/enterprise#18063
Forward-Port-Of: odoo/enterprise#18065
Original PR description
Forward-Port-Of: odoo/enterprise#18065
Open Web shop, add item to cart, go to checkout Add a shipping address different from the billing address and proceed to payment screen. The system will use the billing address to process DHL shipping opw-2504690 Forward-Port-Of: odoo/enterprise#17948 Forward-Port-Of: odoo/enterprise#17911
Original PR description
Open Web shop, add item to cart, go to checkout Add a shipping address different from the billing address and proceed to payment screen. The system will use the billing address to process DHL shipping opw-2504690 Forward-Port-Of: odoo/enterprise#17948 Forward-Port-Of: odoo/enterprise#17911
Before this commit, when the user who has no access right in Sales app and mark as done a task with some materials, when we generate new SOLs for timesheets in the task, the total amount of the SO is recompute and if we do not add sudo then we compute the total amount of SO based on the SOLs that we have generated and not all SOLs in the SO. This commit changes the sudo(False) in sudo() when we prefetch the SOLs of the SO to prefetch and keep the sudo in all SOLs. Thus, the recompute of
Original PR description
Before this commit, when the user who has no access right in Sales app and mark as done a task with some materials, when we generate new SOLs for timesheets in the task, the total amount of the SO is…
Before this commit, when the user who has no access right in Sales app and mark as done a task with some materials, when we generate new SOLs for timesheets in the task, the total amount of the SO is recompute and if we do not add sudo then we compute the total amount of SO based on the SOLs that we have generated and not all SOLs in the SO. This commit changes the sudo(False) in sudo() when we prefetch the SOLs of the SO to prefetch and keep the sudo in all SOLs. Thus, the recompute of total amount will be good. Step to reproduce the bug: 1) Login in Odoo with an user who has no access right in Sales and Accounting apps 2) Go to Field Services App 3) Create a fsm task 4) Define a partner in this task and add some materials 5) Return on the task and click on "mark as done" button 6) Logout and login with an user who can see the SO generated with this task and you will see the total amount is not the one expected. Related PR: #16348 Forward-Port-Of: odoo/enterprise#17988