Friday, February 9, 2024
44 changes · saas-17.1
Enhancements to existing features
JavaScript test suites can now send key progress details directly to runbot build pages. This makes it easier for teams to spot missing or slow test runs without digging through full technical logs.
Original PR description
The purpose of this PR is to allow to write a log from a JS test with the RUNBOT level.
That way a JS test could write useful information that will be available on the runbot build page.
By convention, a JS `console.dir` will be converted into a python loglevel `RUNBOT` (25) instead
of a simple `INFO`.
e.g.:
`console.dir('15 tests passed');`
will lead to a log on a runbot build page like:
`15 tests passed`
(with the usual meta information)This update makes cache invalidation activity easier to track in production once the system registry is ready. It helps technical teams investigate and optimize performance without changing business workflows.
Original PR description
before this commit, ormcache invalidation was only logged in the debug mode. This commit allows ormcache invalidation to be logged when the registry is ready in production, which helps developers to trace/optimize ormcache invalidation. 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
Financial reports now use shorter labels for journal, analytic, and options filters, helping users see and navigate report controls more easily. This improves the reporting interface by saving space, especially in crowded report headers.
Resolved issues and error corrections
This fix prevents an upgrade or module update from failing when administrator settings were already created by another module. It avoids creating a duplicate settings record, improving reliability during installations and upgrades.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: This traceback raised because data is already present in with user_id 2 because if we will install ``mail`` freshly…
Description of the issue/feature this PR addresses:
Current behavior before PR:
This traceback raised because data is already present in with user_id 2 because if we will install ``mail``
freshly this entry will generate due to this function [``_find_or_create_for_user``](https://github.com/odoo/odoo/blob/3adeb31b9028bd70f0a692d9c13f96b29dc1cf87/addons/mail/models/res_users_settings.py#L27C9-L27C33) call from [here](https://github.com/odoo/odoo/blob/fa9e4cb93f26ada5d68de4696033da4f1db2e1ab/addons/mail/models/res_users.py#L188)
with no ir_model_data entry and while updating newly record introduce [here](https://github.com/odoo/odoo/blob/f839688c1cefc5113bbefe1aecfaef97067f6e59/odoo/addons/base/data/res_users_data.xml#L26) in saas-17.1 it creating new entry in res_users_setting and its voilating the unique constraint of the [user_id](https://github.com/odoo/odoo/blob/f839688c1cefc5113bbefe1aecfaef97067f6e59/odoo/addons/base/models/res_users_settings.py#L14)
Desired behavior after PR is merged:
for prevent voilation of unique constraint used forcecreate="0"
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line 119, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line 422, in load_modules
loaded_modules, processed_modules = load_module_graph(
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/convert.py", line 569, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/saas-17.1/odoo/addons/base/data/res_users_data.xml:26, somewhere inside
<record id="user_admin_settings" model="res.users.settings">
<field name="user_id" ref="base.user_admin"/>
</record>
```
TBG-1066
upg-1311090,1311854
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMiscellaneous changes
…fter refusal Before this commit, if a public holiday was created on dates overlapping an existing validated leave, the timesheet entries for the public holiday would not be created as they already existed for the leave. If the leave was then refused or cancelled, the timesheet records linked to it would be removed and the employee would have missing timesheet entries for the public holiday. This commit fixes this behavior by recreating the public holiday timesheet records for the affected
Original PR description
…fter refusal Before this commit, if a public holiday was created on dates overlapping an existing validated leave, the timesheet entries for the public holiday would not be created as they already existed for the leave. If the leave was then refused or cancelled, the timesheet records linked to it would be removed and the employee would have missing timesheet entries for the public holiday. This commit fixes this behavior by recreating the public holiday timesheet records for the affected employees when refusing their leave. opw-3550523 linked to com: https://github.com/odoo/odoo/pull/145522 Forward-Port-Of: odoo/odoo#153118 Forward-Port-Of: odoo/odoo#151522
This change updates Odoo's core utility behavior and its related test coverage. It appears to be a small internal adjustment intended to improve reliability without introducing a visible business workflow change.
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
Restaurant staff can now print receipts for orders that have already been paid without triggering an error. This helps avoid disruption during checkout and keeps receipt handling reliable after payment.
Original PR description
Before this commit, an error was raised when attempting to print a receipt for a paid order in the restaurant module. opw-3735460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Helpdesk reporting menu now hides the SLA Status Analysis option when SLA policies are turned off for all teams. This prevents users from seeing a report that is not relevant to their current Helpdesk setup.
Original PR description
Steps to reproduce: - Go to Helpdesk - Navigate to Configuration > Teams - Turn off the 'sla policies' from the form view of all teams. - Check in the reporting section the 'sla status analysis' menu item is visible for the teams. Issue: - The 'sla status analysis' menu item shouldn't be visible if the 'sla policies' feature is disabled on all teams Solution: - Updated the visibility of the 'sla status analysis' menu item based on the 'sla policies' by adding the groups task-3549328
The Documents inspector now keeps the trash action available when users select multiple documents. This prevents confusion and lets users delete selected documents without changing their selection.
Original PR description
Purpose ======= Fix the trash button which was disappearing from the inspector when multiple documents are selected. Specifications ============== When only one document is selected, the trash button is displayed next to the "Name" field in the inspector. When multiple documents are selected, this "Name" field is hidden preventing the trash button to be displayed. Moving the trash button next to the "Contact" field when multiple documents are selected for it to keep being accessible. Task-3700965
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail when checking if the user can add a reaction to a message. There are two issues: - This step uses the `contains` helper and specify the live chat `ShadowRoot` as the target. However, the `contains` helper uses a mutation observer that observes the light DOM thus, changes in the shadow root are not correctly observed. - The target passed to the `contains` helper is the `ChatWindow` DOM element but this element can
Original PR description
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail when checking if the user can add a reaction to a message. There are two issues: - This step uses the `contains` helper and specify the live chat `ShadowRoot` as the target. However, the `contains` helper uses a mutation observer that observes the light DOM thus, changes in the shadow root are not correctly observed. - The target passed to the `contains` helper is the `ChatWindow` DOM element but this element can be unmounted in-between. This PR fixes this issue. Forward-Port-Of: odoo/odoo#153382
This commit addresses an issue where, upon application to an invoice, the Receivables, while accurate in terms of Amounts and Due Dates, have incorrect labels. The root cause of this problem was identified in the compute_name method of the account.move.line model. The modifications in this commit rectify the compute_name method to ensure that payment terms labels are computed correctly. task-3636484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su
Original PR description
This commit addresses an issue where, upon application to an invoice, the Receivables, while accurate in terms of Amounts and Due Dates, have incorrect labels. The root cause of this problem was identified in the compute_name method of the account.move.line model. The modifications in this commit rectify the compute_name method to ensure that payment terms labels are computed correctly. task-3636484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153364 Forward-Port-Of: odoo/odoo#147670
I. Commit [1] changed the code in toggleList such that variable block could not be a block. This commit updates the name of variable block to nodeToToggle. II. Previously, when changing the tag of a text node within a list, it transferred the list's attributes to the newly created tag. Ideally, this should only carry over the attributes of paragraph-related elements and not of lists. III. Make sure when changing style of a list item with class `nav-item` to normal wraps the text inside
Original PR description
I. Commit [1] changed the code in toggleList such that variable block could not be a block. This commit updates the name of variable block to nodeToToggle. II. Previously, when changing the tag of a text node within a list, it transferred the list's attributes to the newly created tag. Ideally, this should only carry over the attributes of paragraph-related elements and not of lists. III. Make sure when changing style of a list item with class `nav-item` to normal wraps the text inside of a `<p>` tag. [1]: https://github.com/odoo-dev/odoo/commit/d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9 task-3609500 Forward-Port-Of: odoo/odoo#153328 Forward-Port-Of: odoo/odoo#152871
Do not apply update method to avoid inadvertently overwrite on existing values. opw-3729318 Forward-Port-Of: odoo/odoo#153240
Original PR description
Do not apply update method to avoid inadvertently overwrite on existing values. opw-3729318 Forward-Port-Of: odoo/odoo#153240
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` w
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 -…
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Community part to allow the override for odoo/enterprise#55746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152901 Forward-Port-Of: odoo/odoo#152468
**Steps** to reproduce - Install **Sales**, **Accounting** and **Purchase** apps - Go to **Settings** and activate **Analytic Accounting** option. - Create a product that can be expensed and that is re-invoiced at cost + add cost - Create an SO with another product and add an analytic account (activate analytic accounting if not activated by default) + confirm - Create a PO with the expendable product and add the analytic account in the PO lines - Receive product + create bill - The produ
Original PR description
**Steps** to reproduce - Install **Sales**, **Accounting** and **Purchase** apps - Go to **Settings** and activate **Analytic Accounting** option. - Create a product that can be expensed and that is re-invoiced at cost + add cost - Create an SO with another product and add an analytic account (activate analytic accounting if not activated by default) + confirm - Create a PO with the expendable product and add the analytic account in the PO lines - Receive product + create bill - The product is added in the SO with 0 quantity and if I change the quantity to one, the price is recomputed according to the sales price (instead of taking into account the cost). **Investigation** - The `_compute_price_unit()` method doesn't take into account if the so line has been expensed or not opw-3671812 Forward-Port-Of: odoo/odoo#152406
So far when new employee was created from applicant he got a mail with notification about employee creation. It's not a desired behaviour so this change makes just a log note about it. There was also a needed to make a small change in mailing - message_log_with_view method is no longer private as it needs to be used in this case. task-3621545 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm
Original PR description
So far when new employee was created from applicant he got a mail with notification about employee creation. It's not a desired behaviour so this change makes just a log note about it. There was also a needed to make a small change in mailing - message_log_with_view method is no longer private as it needs to be used in this case. task-3621545 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#150981 Forward-Port-Of: odoo/odoo#146130
Before this commit, users without admin access rights were unable to generate invoices. opw-3701291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153092
Original PR description
Before this commit, users without admin access rights were unable to generate invoices. opw-3701291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153092
Addresses the issue where mandates returned by Stripe were not being saved in the database, rendering them unused. The fix involves retrieving mandate information from the charge object in Stripe, as the mandate data is included in the payment method details of the charge object, rather than in the payment methods object. task-3594745 Forward-Port-Of: odoo/odoo#149153
Original PR description
Addresses the issue where mandates returned by Stripe were not being saved in the database, rendering them unused. The fix involves retrieving mandate information from the charge object in Stripe, as the mandate data is included in the payment method details of the charge object, rather than in the payment methods object. task-3594745 Forward-Port-Of: odoo/odoo#149153
Steps to reproduce: - Create a new purchase tax and archive it - Create a new PO Bug: the archived tax is still sugested on the PO Line Fix: apply same logic as for sales opw-3701429 Forward-Port-Of: odoo/odoo#153156 Forward-Port-Of: odoo/odoo#152076
Original PR description
Steps to reproduce: - Create a new purchase tax and archive it - Create a new PO Bug: the archived tax is still sugested on the PO Line Fix: apply same logic as for sales opw-3701429 Forward-Port-Of: odoo/odoo#153156 Forward-Port-Of: odoo/odoo#152076
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - COA - Taxes - Fiscal position - Tax group - Tax report task: 3682464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151296
Original PR description
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - COA - Taxes - Fiscal position - Tax group - Tax report task: 3682464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151296
### Steps to reproduce * create the following hierarchy of companies: ``` Company └── Branch A └── Branch B ``` * delete `Branch A` From then on, whatever you do will result in a Bad Request response. opw-3662711 Forward-Port-Of: odoo/odoo#149013
Original PR description
### Steps to reproduce
* create the following hierarchy of companies:
```
Company
└── Branch A
└── Branch B
```
* delete `Branch A`
From then on, whatever you do will result in a Bad Request response.
opw-3662711
Forward-Port-Of: odoo/odoo#149013**Current behavior:** Confirming a sale order containing an order line associated with >1 products which are tracked via serial number creates a single repair order. **Expected behavior:** A repair order for each individual product in the line is created. **Steps to reproduce:** 0. Create a storable product which is tracked via serial number and has create_repair set to True. Update on hand stock so there are at least two available and assign them each a serial number.
Original PR description
**Current behavior:** Confirming a sale order containing an order line associated with >1 products which are tracked via serial number creates a single repair order. **Expected behavior:** A repair…
**Current behavior:**
Confirming a sale order containing an order line associated with >1 products which are tracked via serial number creates a single repair order.
**Expected behavior:**
A repair order for each individual product in the line is created.
**Steps to reproduce:**
0. Create a storable product which is tracked via serial number
and has create_repair set to True. Update on hand stock so
there are at least two available and assign them each a
serial number.
1. Make a new sale order with one order line for that product with the product_uom_quantity equal to the quantity created in step 0
2. Confirm the order and open the newly created repair order
3. Select a serial number for the repair order, start the repair, then end the repair to raise the exception
**Cause of the issue:**
Multiple products will be associated with one serial number. In stock_quant.py, the check_quantity() method checks the quantity of product_ids associated with a particular lot_id and location_id. In this instance, quantity will now be >1 which results in the ValidationError exception.
**Fix:**
Make a discrete repair order for each product in the order line when the product has serial tracking. This is more logical than asking a user to select one serial number for many products.
opw-3688072
Forward-Port-Of: odoo/odoo#151041Steps to reproduce: - Create a new user with no affiliated sales team - Activate custom mail server with an alias domain - Login with new user - Check pipeline in CRM - The empty pipeline message will show the wrong alias Issues: The alias displayed is not for the team of the user. opw-3608263 Forward-Port-Of: odoo/odoo#152563 Forward-Port-Of: odoo/odoo#144133
Original PR description
Steps to reproduce: - Create a new user with no affiliated sales team - Activate custom mail server with an alias domain - Login with new user - Check pipeline in CRM - The empty pipeline message will show the wrong alias Issues: The alias displayed is not for the team of the user. opw-3608263 Forward-Port-Of: odoo/odoo#152563 Forward-Port-Of: odoo/odoo#144133
Current behaviour: --- When there is too many product categories, you cannot see the last items, because the scrollbar is hidden. This was made to hide the scrollbar on mobile. Steps to reproduce: --- 1. Go to Point of Sale 2. Configuration > PoS Product Categories 3. Duplicate one category 12 times 4. Dashboard > New Session 5. The list of categories is too long 6. Cannot see the last items Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/60f41b1f831
Original PR description
Current behaviour: --- When there is too many product categories, you cannot see the last items, because the scrollbar is hidden. This was made to hide the scrollbar on mobile. Steps to reproduce: --- 1. Go to Point of Sale 2. Configuration > PoS Product Categories 3. Duplicate one category 12 times 4. Dashboard > New Session 5. The list of categories is too long 6. Cannot see the last items Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/60f41b1f831248c58f554dbe40114ef0d4ce42c0#diff-f23069b3927b8544dd51433e277cf8b650b10a67e5b8648155e427aaa31c19a3R838 Fix: --- Make the scrollbar disappear on mobile, and appear otherwise. opw-3653429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150154 Forward-Port-Of: odoo/odoo#148180
In the commit 671640c part of the commit 6ae9c9c was removed inadvertently. After this commit pickup locations will be displayed when the delivery carrier is pre-selected. Forward-Port-Of: odoo/odoo#153259
Original PR description
In the commit 671640c part of the commit 6ae9c9c was removed inadvertently. After this commit pickup locations will be displayed when the delivery carrier is pre-selected. Forward-Port-Of: odoo/odoo#153259
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#153194
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 Forward-Port-Of: odoo/odoo#153194
**Steps to reproduce the bug:** - Create a storable product: - Unit of Measure: KG - Purchase UoM: Tonne - Vendor: “Azure Interior” Quantity: 6T - Recording rule: Min quantity= 500 - Trigger: Manual - Route: Buy - Go to the replenishment page: - Click on the “i” icon - On the Azure Interior line, click on “Set as supplier” **Problem**: The quantity to order is not updated to 6000 kg because in the "action_set_supplier" function, we compar
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- Unit of Measure: KG
- Purchase UoM: Tonne
- Vendor: “Azure Interior” Quantity: 6T
- Recording rule: Min quantity= 500
- Trigger: Manual
- Route: Buy
- Go to the replenishment page:
- Click on the “i” icon
- On the Azure Interior line, click on “Set as supplier”
**Problem**:
The quantity to order is not updated to 6000 kg because in the "action_set_supplier" function, we compare the quantity of the supplier information with the quantity of the orderpoint without converting the values to the same UoM.
So:
500 < 6 → False
Therefore, the quantity is not updated.
opw-3705090
Forward-Port-Of: odoo/odoo#153202
Forward-Port-Of: odoo/odoo#152722### Steps to reproduce issue: 1. Open CRM and select a list/tree view (opportunities or leads) 2. Select multiple records and try merging them (gear menu) 3. Click on salesperson field 4. Field dropdown contains portal users, should not be the case ### Explanation: `user_id` (salesperson field) in `crm.merge.opportunity` is a many2one related to res.users. Since it is not restricted, every existing user is listed in the selection. ### Suggested fix: In `crm.lead`, its homologou
Original PR description
### Steps to reproduce issue:
1. Open CRM and select a list/tree view (opportunities or leads)
2. Select multiple records and try merging them (gear menu)
3. Click on salesperson field
4. Field dropdown contains portal users, should not be the case
### Explanation:
`user_id` (salesperson field) in `crm.merge.opportunity` is a many2one related to res.users. Since it is not restricted, every existing user is listed in the selection.
### Suggested fix:
In `crm.lead`, its homologous field possesses the domain formula `('share', '=', False)`. https://github.com/odoo/odoo/blob/f987dd26e928bd0394cd0b835cc1d0fdd72e9234/addons/crm/models/crm_lead.py#L105-L108 Copying it into `crm.merge.opportunity` correctly restricts the users selection.
opw-3696148
Forward-Port-Of: odoo/odoo#153059
Forward-Port-Of: odoo/odoo#152429**Description of the issue this PR addresses:** Previously, In RTL mode, the table columns menu were misaligned, causing a visual discrepancy in the UI.Now, Implemented a fix to correctly position the table menu columns in RTL mode, ensuring proper alignment and resolving the visual misalignment issue. task-[3695715](https://www.odoo.com/web#id=3695715&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#151955
Original PR description
**Description of the issue this PR addresses:** Previously, In RTL mode, the table columns menu were misaligned, causing a visual discrepancy in the UI.Now, Implemented a fix to correctly position the table menu columns in RTL mode, ensuring proper alignment and resolving the visual misalignment issue. task-[3695715](https://www.odoo.com/web#id=3695715&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#151955
### Steps to reproduce - Install **sale_purchase_inter_company_rules** module - Go to **Settings** and activate I**nter-Company Transactions** option - Save then Go to **Settings** > **Inter-Company Transactions** and select **Synchronize Sales and Purchase Order** - Notice how **Copy Lots on Delivery Validation** is selected - Save - Now _Unselect_ the **Copy Lots on Delivery Validation**, Then Save - Go back to the Settings, **Copy Lots on Delivery Validation** is **_selected_** althoug
Original PR description
### Steps to reproduce - Install **sale_purchase_inter_company_rules** module - Go to **Settings** and activate I**nter-Company Transactions** option - Save then Go to **Settings** > **Inter-Company Transactions** and select **Synchronize Sales and Purchase Order** - Notice how **Copy Lots on Delivery Validation** is selected - Save - Now _Unselect_ the **Copy Lots on Delivery Validation**, Then Save - Go back to the Settings, **Copy Lots on Delivery Validation** is **_selected_** although it shouldn't ### Investigation - The following line https://github.com/odoo/enterprise/blob/40060d1a78c07aa9420fdc2963f96209e1b3f9d5/sale_purchase_inter_company_rules/models/res_config_settings.py#L26 at the `onchange_rule_type` sets the `copy_lots_delivery` when the settings are loaded back no matter what the value the client had set opw-3702544 Forward-Port-Of: odoo/enterprise#56002
The new design introduced in odoo/enterprise#41534 moved the details inside a column used in the several templates of the appointment flow, updating at each step. However, it is not shown for anytime and custom appointments. In order to avoid a large blank space on the right of the screen and a strange design effect, as well as to give the attendee the available details as soon as they are available, always display the details column. However, as the duration may vary in the custom categor
Original PR description
The new design introduced in odoo/enterprise#41534 moved the details inside a column used in the several templates of the appointment flow, updating at each step. However, it is not shown for anytime and custom appointments. In order to avoid a large blank space on the right of the screen and a strange design effect, as well as to give the attendee the available details as soon as they are available, always display the details column. However, as the duration may vary in the custom category, do not show duration field at time selection for those appointments. Show duration of selected slot on detail screen. Task-3701087 Forward-Port-Of: odoo/enterprise#55138
To reproduce: 1. Install and configure the VoIP module in prod mode 2. Place a call to anyone 3. Block the browser from accessing the microphone Error: Invalid state transition from Terminated to Terminated Fixed in https://github.com/onsip/SIP.js/commit/f06939c119149a3e00ad8acf69f37360d3331a62 Adapt it in old version. Task-2810572 Forward-Port-Of: odoo/enterprise#54467 Forward-Port-Of: odoo/enterprise#53581
Original PR description
To reproduce: 1. Install and configure the VoIP module in prod mode 2. Place a call to anyone 3. Block the browser from accessing the microphone Error: Invalid state transition from Terminated to Terminated Fixed in https://github.com/onsip/SIP.js/commit/f06939c119149a3e00ad8acf69f37360d3331a62 Adapt it in old version. Task-2810572 Forward-Port-Of: odoo/enterprise#54467 Forward-Port-Of: odoo/enterprise#53581
Steps to reproduce: - Change language to French for example - Install accounting - Go to the "Tax Report" - Options will display "With Draft Entries" or "Posted Entries Only" Issue: The terms are not exported since we were using t-esc. Cause: Replace the ternary operator with an t-if and t-else. opw-3356916 Forward-Port-Of: odoo/enterprise#53603 Forward-Port-Of: odoo/enterprise#53142
Original PR description
Steps to reproduce: - Change language to French for example - Install accounting - Go to the "Tax Report" - Options will display "With Draft Entries" or "Posted Entries Only" Issue: The terms are not exported since we were using t-esc. Cause: Replace the ternary operator with an t-if and t-else. opw-3356916 Forward-Port-Of: odoo/enterprise#53603 Forward-Port-Of: odoo/enterprise#53142
Before this commit, the `test_dashboard_ui` test in payroll was relying on sign. However, `hr_payroll` does not depend on sign, which would lead to the test breaking when that module is not installed. This commit adds a check to see if sign is installed before creating the additional data related to it. Forward-Port-Of: odoo/enterprise#56111 Forward-Port-Of: odoo/enterprise#56051
Original PR description
Before this commit, the `test_dashboard_ui` test in payroll was relying on sign. However, `hr_payroll` does not depend on sign, which would lead to the test breaking when that module is not installed. This commit adds a check to see if sign is installed before creating the additional data related to it. Forward-Port-Of: odoo/enterprise#56111 Forward-Port-Of: odoo/enterprise#56051
…s template Have a form view, with a subview form. That subview has a button_box. Before this commit, the button box was compiled in the context of the main view, eventually leading to crashes. After this commit, it is compiled only when navigation to that subview for edition. This issue and the fix are similar to odoo/odoo#149896 opw-3681966 Forward-Port-Of: odoo/enterprise#56191 Forward-Port-Of: odoo/enterprise#56130
Original PR description
…s template Have a form view, with a subview form. That subview has a button_box. Before this commit, the button box was compiled in the context of the main view, eventually leading to crashes. After this commit, it is compiled only when navigation to that subview for edition. This issue and the fix are similar to odoo/odoo#149896 opw-3681966 Forward-Port-Of: odoo/enterprise#56191 Forward-Port-Of: odoo/enterprise#56130
Before this PR: The string for the `tax_unit_id` field was 'VAT Units'. After this PR: The `tax_unit_id` field's string has been renamed 'GST Units'. Task-3726861 Forward-Port-Of: odoo/enterprise#56120
Original PR description
Before this PR: The string for the `tax_unit_id` field was 'VAT Units'. After this PR: The `tax_unit_id` field's string has been renamed 'GST Units'. Task-3726861 Forward-Port-Of: odoo/enterprise#56120
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` w
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Forward-Port-Of: odoo/enterprise#55973 Forward-Port-Of: odoo/enterprise#55746
Versions -------- - saas-16.2+ Steps ----- 1. Create a Sale Order; 2. add a Recurrence & click Save; 3. remove Recurrence & click Confirm; 4. cancel the SO; 5. click Set to Quotation. Issue ----- Sale Order still displays as a Subscription Quotation. Cause ----- The `write` method filters subscriptions on the `is_subscription` field before calling `super().write(vals)`. The `is_subscription` field is dependent on the `recurrence_id` field, so when setting `recurrence_id` to
Original PR description
Versions -------- - saas-16.2+ Steps ----- 1. Create a Sale Order; 2. add a Recurrence & click Save; 3. remove Recurrence & click Confirm; 4. cancel the SO; 5. click Set to Quotation. Issue ----- Sale Order still displays as a Subscription Quotation. Cause ----- The `write` method filters subscriptions on the `is_subscription` field before calling `super().write(vals)`. The `is_subscription` field is dependent on the `recurrence_id` field, so when setting `recurrence_id` to `False`, `is_subscription` should also be `False`. As this computation happens after filtering, `write` still adds a `subscription_state` to the record, despite it not being a subscription. Solution -------- Double check `is_subscription` before adding a `subscription_state` on write. opw-3709457 Forward-Port-Of: odoo/enterprise#56082 Forward-Port-Of: odoo/enterprise#55741
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - Balance sheet - Profit and loss task: 3682464 Forward-Port-Of: odoo/enterprise#55207
Original PR description
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - Balance sheet - Profit and loss task: 3682464 Forward-Port-Of: odoo/enterprise#55207
Be sure that cron is committed before to send email. In case of concurrent update with e.g. bounce, the cron will fail and so the email send again and again... Forward-Port-Of: odoo/enterprise#55774
Original PR description
Be sure that cron is committed before to send email. In case of concurrent update with e.g. bounce, the cron will fail and so the email send again and again... Forward-Port-Of: odoo/enterprise#55774
Create an invoice for a customer who lives in the UE but his/her VAT number has not been verified by the VIES system, so the transaction with this partner should be considered with fiscal position 'Regimen Nacional' because the IVA should appear as a domestic customer. When creating the invoice with fiscal position 'Regimen Nacional', ensure field for tax report 349 is empty in the tab 'AEAT data' as well as tax in the invoice exists. Open Tax Report 349 Issue: There will be values for thes
Original PR description
Create an invoice for a customer who lives in the UE but his/her VAT number has not been verified by the VIES system, so the transaction with this partner should be considered with fiscal position 'Regimen Nacional' because the IVA should appear as a domestic customer. When creating the invoice with fiscal position 'Regimen Nacional', ensure field for tax report 349 is empty in the tab 'AEAT data' as well as tax in the invoice exists. Open Tax Report 349 Issue: There will be values for these 2 lines which should not be there, as this specific invoice should not appear in tax report 349 opw-3673456 Forward-Port-Of: odoo/enterprise#56103 Forward-Port-Of: odoo/enterprise#55504
It is possible that two expressions (possibly of different report, linked together by a cross_report expression) needing to be evaluated at the same time share the same tax tags formula. When this case happens, the result of the engine function should be in the form {(formula, recordset_of_expr_1_and_2): result} (assuming there is no other expression to evaluate, for the sake of simplicity). Before this fix, in this situation, the engine instead returned: { (formula, expr_1): result,
Original PR description
It is possible that two expressions (possibly of different report, linked together by a cross_report expression) needing to be evaluated at the same time share the same tax tags formula. When this…
It is possible that two expressions (possibly of different report, linked together by a cross_report expression) needing to be evaluated at the same time share the same tax tags formula. When this case happens, the result of the engine function should be in the form {(formula, recordset_of_expr_1_and_2): result} (assuming there is no other expression to evaluate, for the sake of simplicity).
Before this fix, in this situation, the engine instead returned: {
(formula, expr_1): result,
(formula, expr_2): result,
(formula, recordset_of_expr_1_and_2): empty_value,
}
Because of that, the report ended up evalutating these expressions with an empty result. This was spotted when forward-porting https://github.com/odoo/enterprise/commit/c8beb3559b9199fc2f72773dd5dedf871cf2406b , since the new error it introduces raised in such case, since the value initially computed for expr_1/expr_2 got overwritten.
This was wrong, and was due to the fact the result dict was first initialized using the full key of the formulas_dict (hence grouping expr_1 and expr_2 into a common recordset), and then wrongly iterated on all the expressions contained in the keys. We fix that by using the full key everywhere.
Forward-Port-Of: odoo/enterprise#56162Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsDataPointMixin mixin. Task-3700259 Forward-Port-Of: odoo/enterprise#56139 Forward-Port-Of: odoo/enterprise#55011
Original PR description
Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsDataPointMixin mixin. Task-3700259 Forward-Port-Of: odoo/enterprise#56139 Forward-Port-Of: odoo/enterprise#55011
Steps to reproduce: ------------------- - install documents and fleet apps; - be a user who is not in the `base.user_admin` group; - have admin rights to fleet and document; - put a document in the "Fleet" workspace; - click on "Link to a vehicle" button; Issue: ------ - First issue: An access error is triggered when we want to get the `model` field for an `ir.model` record. - Second issue: When a `Reference` field has the `model_field` option, a read on `ir.model` is triggered and a
Original PR description
Steps to reproduce: ------------------- - install documents and fleet apps; - be a user who is not in the `base.user_admin` group; - have admin rights to fleet and document; - put a document in the…
Steps to reproduce: ------------------- - install documents and fleet apps; - be a user who is not in the `base.user_admin` group; - have admin rights to fleet and document; - put a document in the "Fleet" workspace; - click on "Link to a vehicle" button; Issue: ------ - First issue: An access error is triggered when we want to get the `model` field for an `ir.model` record. - Second issue: When a `Reference` field has the `model_field` option, a read on `ir.model` is triggered and as we don't have the rights, this causes an access error. Solution: --------- Work on the `ir.model` record in sudo. Do not use the `model_field` option and use a default value for the `Reference` field which expects a string like `"model,id"`. Note: ----- This solution avoids adding a new access right for `ir.model` as follows: ```csv access_ir_model,access_ir_model,base.model_ir_model,documents.group_documents_user,1,0,0,0 ``` opw-3502558 Forward-Port-Of: odoo/enterprise#56147 Forward-Port-Of: odoo/enterprise#50784