Daily updates from Odoo
Tuesday, October 1, 2024
168 changes
9 changes
Miscellaneous changes
Steps: --- - Open POS Restaurant - Edit floor & click on a table - Rapidly click add table multiple times - Multiple tables with the same number are created - Duplicate tables also overlap the original table completely Issue: --- Duplicate tables should not be created. Cause: --- The "Add" button that creates the table calls an async function. Rapid clicks make new calls even before the promises are successful. FIX: --- Disable the button and creation until the previous tabl
Original PR description
Steps: --- - Open POS Restaurant - Edit floor & click on a table - Rapidly click add table multiple times - Multiple tables with the same number are created - Duplicate tables also overlap the original table completely Issue: --- Duplicate tables should not be created. Cause: --- The "Add" button that creates the table calls an async function. Rapid clicks make new calls even before the promises are successful. FIX: --- Disable the button and creation until the previous table is created so that rapid clicks are handled. task-3956310 Forward-Port-Of: odoo/odoo#169937
When computing the cheapest line of an order to apply a discount on it, combo line should be considered as one product as it is done in the sale app. Steps to reproduce: ------------------- * Setup a combo product * Setup a discount program that applies on the cheapest line * Open a PoS and add the combo product > Observation: The discount would be applied on the cheapest product of the combo instead of the whole combo Why the fix: ------------ When we look for the cheapest line an
Original PR description
When computing the cheapest line of an order to apply a discount on it, combo line should be considered as one product as it is done in the sale app. Steps to reproduce: ------------------- * Setup a combo product * Setup a discount program that applies on the cheapest line * Open a PoS and add the combo product > Observation: The discount would be applied on the cheapest product of the combo instead of the whole combo Why the fix: ------------ When we look for the cheapest line and we encounter a combo product we sum all the lines of the combo to compute it's total price opw-4033960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180482
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
Original PR description
When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181129
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181129
Steps to reproduce: 1. Install the `sale_project` module. 2. Create a product with the following properties: - Type: 'Service' - Create on Order: 'Project & Task' 4. Create a sale order and add the product to it. 5. Confirm the sale order. 6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.) The issue arises because the 'Project' smart button remains visible
Original PR description
Steps to reproduce:
1. Install the `sale_project` module.
2. Create a product with the following properties:
- Type: 'Service'
- Create on Order: 'Project & Task'
4. Create a sale order and add the product to it.
5. Confirm the sale order.
6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.)
The issue arises because the 'Project' smart button remains visible in the sale order tab until the page is reloaded, and there are no longer any order lines with a product of type 'Service', resulting in a StopIteration error.
Closes #180340
Forward-Port-Of: odoo/odoo#181946We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKgu
Original PR description
We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKguJqWPVl-g-7H6YqJiWoRNgWCYI/edit?gid=0#gid=0 opw-4072691 Forward-Port-Of: odoo/odoo#181648 Forward-Port-Of: odoo/odoo#178076
Manual back porting the part of 02f78498972a6fc7d560c0e6c0a5b3bf63eb58d3 that add common for account journal dashbaord tests. opw-4182523 Forward-Port-Of: odoo/odoo#182182
Original PR description
Manual back porting the part of 02f78498972a6fc7d560c0e6c0a5b3bf63eb58d3 that add common for account journal dashbaord tests. opw-4182523 Forward-Port-Of: odoo/odoo#182182
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing.
Original PR description
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in…
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing. This is even more obvious on a slow network. The difference between the first time and the others is that the form view used in the quick create must be loaded the first time, and is in cache afterwards. When we click on the "+" icon, the following happens: - we remove sample records from the groups and we enable the quick create in a column => triggers a rendering of the KanbanRenderer - in the same tick, we toggle the useSampleModel flag on the model => triggers a rendering of the Controller After its rendering, the Controller no longer has the classname `o_view_sample_data` which ensures that sample records are displayed as ghosts. After its rendering, the Renderer no longer contains sample records. The flickering occurs when the rendering of the Renderer is async (the one of the Controller being always sync, as it doesn't wait for his children to be re-rendered, as their props didn't change). Indeed, in that case, there's a small timeframe during which the controller no longer has the classname `o_view_sample_data` but the renderer still contains sample records. Normally, the rendering of the Renderer should always be sync. Indeed, we triggered the loadViews in its onWillStart but we didn't wait for the rpc to return (we have a `isLoaded` flag, and we have an empty rendering while `isLoaded` is false). However, when the loadViews is already in the cache, the promise is resolves in the next microTick, and we directly render the component with the state `isLoaded` true, i.e. with the KanbanQuickCreateController. But that component is always async, as it loads the form view data (onchange) in its onWillStart, and must wait for it. As a consequence, in that case, the whole rendering of the Renderer is delayed. To fix the issue, this commit simply ensures that the rendering of the KanbanRecordQuickCreate is **always** sync, by toggling the `isLoaded` flag in onMounted instead of onWillStart. That way, the Renderer is rendered without the sample records in the same animationFrame as the Controller, and only then we toggle the KanbanQuickCreateController. Closes #181743 Task~4196741 Forward-Port-Of: odoo/odoo#182300
Starting from `18.0`, text highlight effects are used for snippets customizations in themes, which means snippets can be provided with highlighted content (in a minimal format) that allows the JS code to rebuild the SVGs later when it's needed: ``` <span class="o_text_highlight o_text_highlight_[highlightId]" style="--text-highlight-width: ...; --text-highlight-color: ...;"> text content ... </span> ``` The highlights code provides some tools to adapt them when the content
Original PR description
Starting from `18.0`, text highlight effects are used for snippets
customizations in themes, which means snippets can be provided with
highlighted content (in a minimal format) that allows the JS code to
rebuild the SVGs later when it's needed:
```
<span class="o_text_highlight o_text_highlight_[highlightId]"
style="--text-highlight-width: ...; --text-highlight-color: ...;">
text content ...
</span>
```
The highlights code provides some tools to adapt them when the content
is changed: add & remove text, resize… But It doesn't handle the case
of a dropped snippet with highlights.
The goal of this commit is to be able to build the highlights of a
snippet once dropped.
Remark: The behavior fixed in this commit wasn't possible until `18.0`
(with themes snippets using highlights) but we target `17.0` to handle
every possible customization that uses the effects before themes
refactoring.
task-4215788
Forward-Port-Of: odoo/odoo#18220856 changes
Miscellaneous changes
When downloading a dashboard's json file in debug mode, we get the initial version of the dashboard file and not the latest (without the revisions). This commit's goal is to prevent downloading the dashboard's json file and displaying a warning message to the user. task-4196930 Forward-Port-Of: odoo/enterprise#70787
Original PR description
When downloading a dashboard's json file in debug mode, we get the initial version of the dashboard file and not the latest (without the revisions). This commit's goal is to prevent downloading the dashboard's json file and displaying a warning message to the user. task-4196930 Forward-Port-Of: odoo/enterprise#70787
[FIX] l10n_ec_edi: Fix wrong condition to display tax totals in PDF [FIX] l10n_mx_edi: Fix broken test after merge: The fix has been added by https://github.com/odoo/enterprise/commit/d5da2b62263f85fbce0f2548085c066cbbf10371 At the same time, this commit has been merged: https://github.com/odoo/enterprise/commit/00cc171c6e122118af72d84bb26ff083c086dff4 Now those tests are skipped on runbot. Let's fix them. [FIX] l10n_mx_edi: Remove date related stuff from MX test files Now we move to o
Original PR description
[FIX] l10n_ec_edi: Fix wrong condition to display tax totals in PDF [FIX] l10n_mx_edi: Fix broken test after merge: The fix has been added by https://github.com/odoo/enterprise/commit/d5da2b62263f85fbce0f2548085c066cbbf10371 At the same time, this commit has been merged: https://github.com/odoo/enterprise/commit/00cc171c6e122118af72d84bb26ff083c086dff4 Now those tests are skipped on runbot. Let's fix them. [FIX] l10n_mx_edi: Remove date related stuff from MX test files Now we move to october, the test is failing on runbot... [IMP] l10n_mx: round_globally in mexico by default Now the round globally is fully managed, let's enforce it in Mexico. Forward-Port-Of: odoo/enterprise#71168
This commit is the counterpart of https://github.com/odoo/odoo/pull/182079 and add the edit button to the newly introduced registry. Forward-Port-Of: odoo/enterprise#71041
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/182079 and add the edit button to the newly introduced registry. Forward-Port-Of: odoo/enterprise#71041
Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649 Forward-Port-Of: odoo/enterprise#71174
Original PR description
Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649 Forward-Port-Of: odoo/enterprise#71174
Sections and notes in the SO are badly displayed in the sale order line list in the spreadsheet. They should be excluded from the list (domain on display type). (or maybe later, change the default list fields to make it pretty somehow?) Task: 4200539 Forward-Port-Of: odoo/enterprise#71086
Original PR description
Sections and notes in the SO are badly displayed in the sale order line list in the spreadsheet. They should be excluded from the list (domain on display type). (or maybe later, change the default list fields to make it pretty somehow?) Task: 4200539 Forward-Port-Of: odoo/enterprise#71086
Before this PR: - The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action. - As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`. - So, the customer selection step was not properly highlighted or explained. After this PR: - Added `content` and `position` attributes to the child step triggered by `.o_field_w
Original PR description
Before this PR: - The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action. - As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`. - So, the customer selection step was not properly highlighted or explained. After this PR: - Added `content` and `position` attributes to the child step triggered by `.o_field_widget[name="partner_id"] input`, ensuring the tooltip appears with the correct message and placement. - The step now properly displays the tooltip when the customer selection field is focused. task-4159812 Forward-Port-Of: odoo/enterprise#70941 Forward-Port-Of: odoo/enterprise#69768
We don't need to create an empty move to compute the suitable journal_id. Task-4216195 Forward-Port-Of: odoo/enterprise#71172
Original PR description
We don't need to create an empty move to compute the suitable journal_id. Task-4216195 Forward-Port-Of: odoo/enterprise#71172
Before this commit there were two issues: - add a menu on a card - try to remove or add a field elsewhere in the card => the xpath of the last operation was always wrong. This was because the normlalise function got confused and refused to actually add the menu template before the card template. - web_ribbon was appended to the card => this cause the style to be broken. Albeit the ribbon widget makes sense at the top of the card template, it should not break the style in those proport
Original PR description
Before this commit there were two issues: - add a menu on a card - try to remove or add a field elsewhere in the card => the xpath of the last operation was always wrong. This was because the normlalise function got confused and refused to actually add the menu template before the card template. - web_ribbon was appended to the card => this cause the style to be broken. Albeit the ribbon widget makes sense at the top of the card template, it should not break the style in those proportions. So, a small fix is done in studio to add the ribbon at the top of the card, but we strongly recommend a fix that will enable to put it anywhere as a direct child of the relevant view node. task-4207793 Forward-Port-Of: odoo/enterprise#70797
The quarter filter was not properly calculating the quarters. It was taking periods of 3 months not based on quarter but based on the current date. The months are now properly calculated based on the quarter. Forward-Port-Of: odoo/enterprise#71185
Original PR description
The quarter filter was not properly calculating the quarters. It was taking periods of 3 months not based on quarter but based on the current date. The months are now properly calculated based on the quarter. Forward-Port-Of: odoo/enterprise#71185
Prior to the fix, portal users would get an access rights error whenever they would group or search sale order. That was because the ``sale_order_id`` field was only given access to sale and accounting users. That was the case since the helpdesk app was first created. All users, including portal, have access to the ``sale_order_line`` field, thus the restriction on the ``sale_order_id`` field are not anymore necessary. We "fix" the access right error by basically removing the group restric
Original PR description
Prior to the fix, portal users would get an access rights error whenever they would group or search sale order. That was because the ``sale_order_id`` field was only given access to sale and accounting users. That was the case since the helpdesk app was first created. All users, including portal, have access to the ``sale_order_line`` field, thus the restriction on the ``sale_order_id`` field are not anymore necessary. We "fix" the access right error by basically removing the group restriction on the ``sale_order_id`` field in the helpdesk.ticket model. task-4207628 Forward-Port-Of: odoo/enterprise#70889
Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4
Original PR description
Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4145124 Forward-Port-Of: odoo/enterprise#70832 Forward-Port-Of: odoo/enterprise#69658
It's more confusing than helpful to enable the filter automatically. Task-4216195 Forward-Port-Of: odoo/enterprise#71170
Original PR description
It's more confusing than helpful to enable the filter automatically. Task-4216195 Forward-Port-Of: odoo/enterprise#71170
Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612 Forward-Port-Of: odoo/enterprise#70641 Forward-Port-Of:
Original PR description
Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612 Forward-Port-Of: odoo/enterprise#70641 Forward-Port-Of: odoo/enterprise#69878
Before this commit, the test `test_ytd_02_reset_date` was using a date relative to today's date; however this can bring errors. This commit sets a fixed date for the test in order to avoid that. Forward-Port-Of: odoo/enterprise#71110
Original PR description
Before this commit, the test `test_ytd_02_reset_date` was using a date relative to today's date; however this can bring errors. This commit sets a fixed date for the test in order to avoid that. Forward-Port-Of: odoo/enterprise#71110
Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098 Forward-Port-Of: odoo/enterprise#70331
Original PR description
Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098 Forward-Port-Of: odoo/enterprise#70331
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen: 1. sla_ids which registers SLA policy types, has duplicate entries.
Original PR description
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements -…
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen: 1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set. 2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well. 3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities. opw-4037262 Forward-Port-Of: odoo/enterprise#70946 Forward-Port-Of: odoo/enterprise#69352
Steps to reproduce: - Planning > Configuration > Employees > New - Schedule > By resource > Filter for your employee - Click on the employee's Gantt line and assign a shift - Click the shift > Edit > Click the looping arrow next to date - Your shift should now be recurring over the coming weeks - Go to the 2nd week > Edit the shift's end date - Check 'All shifts' at the top and save There are 2 issues here: 1. A MissingError is raised 2. Even when bypassing that error, the planning i
Original PR description
Steps to reproduce: - Planning > Configuration > Employees > New - Schedule > By resource > Filter for your employee - Click on the employee's Gantt line and assign a shift - Click the shift > Edit >…
Steps to reproduce: - Planning > Configuration > Employees > New - Schedule > By resource > Filter for your employee - Click on the employee's Gantt line and assign a shift - Click the shift > Edit > Click the looping arrow next to date - Your shift should now be recurring over the coming weeks - Go to the 2nd week > Edit the shift's end date - Check 'All shifts' at the top and save There are 2 issues here: 1. A MissingError is raised 2. Even when bypassing that error, the planning is regenerating the slots from the original slot's start date to the 2nd slot's end date. (i.e. for a weekly recurrence you will now have 2 week long slots instead of the expected 1 week) Both happen because when editing the start/end date of a recurring shift we simply unlink the existing ones and regenerate them from the original slot. Since they are unlinked we can no longer access the shift we were trying to edit (the 2nd occurrence) resulting in the MissingError. And because we regenerate from the first slot despite taking values from the second, we stretch the original slot, which is repercuted on every subsequently generated slot's dates. opw-4154647 Forward-Port-Of: odoo/enterprise#71051 Forward-Port-Of: odoo/enterprise#70292
- When you select based on achievement save, then draft again and change it into based on achievement to based on targets - When I try commission plan based on MRR and try to sell sub, I don't see my commission in "my commission" Forward-Port-Of: odoo/enterprise#71169
Original PR description
- When you select based on achievement save, then draft again and change it into based on achievement to based on targets - When I try commission plan based on MRR and try to sell sub, I don't see my commission in "my commission" Forward-Port-Of: odoo/enterprise#71169
The purpose of this commit is to add a dialog plugin that will centralise the behaviour shared between dialogs opened from the editor. The behaviour shared by all the editor dialogs is the repositioning of the selection in the editable when a dialog closes. Forward-Port-Of: odoo/enterprise#71040
Original PR description
The purpose of this commit is to add a dialog plugin that will centralise the behaviour shared between dialogs opened from the editor. The behaviour shared by all the editor dialogs is the repositioning of the selection in the editable when a dialog closes. Forward-Port-Of: odoo/enterprise#71040
Fixes persistent cache ================= Before this commit, an old instance of `LazyBarcodeCache` was used by `BarcodeObject` when an operation is done after another operation without any browser's refresh between them. Cleans `processBarcode` =================== Makes some cleans/improvements/fixes of the `processBarcode` code: - Does nothing if no barcode is given; - Moves all cleaning stuff in its own method, `postProcessBarcode`, so this way this is better organized and easier to o
Original PR description
Fixes persistent cache ================= Before this commit, an old instance of `LazyBarcodeCache` was used by `BarcodeObject` when an operation is done after another operation without any browser's…
Fixes persistent cache ================= Before this commit, an old instance of `LazyBarcodeCache` was used by `BarcodeObject` when an operation is done after another operation without any browser's refresh between them. Cleans `processBarcode` =================== Makes some cleans/improvements/fixes of the `processBarcode` code: - Does nothing if no barcode is given; - Moves all cleaning stuff in its own method, `postProcessBarcode`, so this way this is better organized and easier to override. Fixes failing test tours =============== Following https://github.com/odoo/enterprise/pull/68825, the Barcode app code `processBarcode` is now slightly slower. In consequence, some not so precise triggers in the tours run too faster and don't correctly wait the previous trigger's action to be completed. This commit makes those triggers more precise. Runbot build error: - 99509 `test_receipt_reserved_2_partial_put_in_pack` - 99513 `test_setting_group_lines_by_product` - 99515 `test_inventory_adjustment_tracked_product` - 99520 `test_put_in_pack_before_dest` - 99521 `test_split_line_on_exit_for_delivery` - 99523 `test_split_line_reservation` - 99525 `test_barcode_batch_delivery_1` - 99529 `test_put_in_pack_from_multiple_pages` - 99531 `test_put_in_pack_scan_suggested_package` - 99536 `test_picking_type_mandatory_scan_complete_flux` - 99537 `test_put_in_pack_before_dest` (from picking batch) Forward-Port-Of: odoo/enterprise#70853
Before this PR When multiple appointments are selected and duplicated a traceback occurs. **Technical** **_get_default_range_slots** method in appointment_hr expects single record, so when appointment_hr is installed and try to duplicate the record singelton traceback occurs. After this PR Without any traceback, appointments can be duplicated. Task-4210180 Forward-Port-Of: odoo/enterprise#70537
Original PR description
Before this PR When multiple appointments are selected and duplicated a traceback occurs. **Technical** **_get_default_range_slots** method in appointment_hr expects single record, so when appointment_hr is installed and try to duplicate the record singelton traceback occurs. After this PR Without any traceback, appointments can be duplicated. Task-4210180 Forward-Port-Of: odoo/enterprise#70537
Community PR: odoo/odoo#180327 Task-4173210 Forward-Port-Of: odoo/enterprise#70099
Original PR description
Community PR: odoo/odoo#180327 Task-4173210 Forward-Port-Of: odoo/enterprise#70099
In this PR, we fix the creation of shortcuts in My drive when the target are in non-writable folders. In a second commit, we fix and test the initial data folder_id passed to open the side panel on the right folder or section at the app's initialization. Task-4216195 Forward-Port-Of: odoo/enterprise#71125
Original PR description
In this PR, we fix the creation of shortcuts in My drive when the target are in non-writable folders. In a second commit, we fix and test the initial data folder_id passed to open the side panel on the right folder or section at the app's initialization. Task-4216195 Forward-Port-Of: odoo/enterprise#71125
Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices. Related https://github.com/odoo/enterprise/pull/69359 Forward-Port-Of: odoo/enterprise#70971 Forward-Port-Of: odoo/enterprise#70698
Original PR description
Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices. Related https://github.com/odoo/enterprise/pull/69359 Forward-Port-Of: odoo/enterprise#70971 Forward-Port-Of: odoo/enterprise#70698
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the compute_taxes method. Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py => We should have only one mechanism. Then, another problem is the whole logic to compute the round_globally is wrong. Instead of: - compute the tax values
Original PR description
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the…
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the compute_taxes method. Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py => We should have only one mechanism. Then, another problem is the whole logic to compute the round_globally is wrong. Instead of: - compute the tax values per grouping key per tax repartition line per line - aggregate the amounts - round we should: - compute the tax values per tax and per line - round - dispatch the amounts to the repartition lines. Let's take some examples: Suppose 3 lines of: price_unit = 33.33, tax = 10% price_unit = 33.33, tax = 10% price_unit = 33.34, tax = 10% Using round_per_line, each line will compute 3.33 as tax so a total of 9.99. Using round_globally, each line will respectively compute a tax amount of 3.333, 3.333, 3.334 so a total of 10.0. However, depending the current grouping key to compute the tax lines (each one corresponding to a repartition line), the computation could be different. Suppose the analytic checkbox is ticked on the tax and the base lines are: price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_A price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_B price_unit = 33.34, tax = 10%, analytic_distribution = 100% on account_C In this specific case, the total of taxes will be 3 x 3.33 = 9.99 because it will generate 3 tax lines, one for each analytic distribution. Another problem is when dealing with price included taxes. Suppose two lines: price_unit = 21.53, tax = 21% incl price_unit = 21.53, tax = 21% incl Each line will compute a tax excluded amount of round(21.53 / 1.21) = 17.79 So the total untaxed amount is computed as 17.79 x 2 = 35.58. However, since the tax is included in price, the untaxed amount should be round(21.53 * 2 / 1.21) = 35.59 It means there is 0.01 that need to be distributed on invoice's journal items. task-id: 3725705 Forward-Port-Of: odoo/enterprise#69952
The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`. Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint. Steps to reproduce: - Edit 'Out of Contract' work entr
Original PR description
The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`. Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint. Steps to reproduce: - Edit 'Out of Contract' work entry type and set Time Off and Unforeseen Absence as True. - Upgrade to the next version. Forward-Port-Of: odoo/enterprise#70104
Version: - 18.0 Steps to reproduce: - create a subscription sale order - confirm the sale order Issue: - two create invoice button are visible Cause: - The conditions for showing the two "Create Invoice" buttons overlapped, making both appear at the same time Solution: - Adjusted button conditions to ensure only one "Create Invoice" button is displayed when no invoice is created Forward-Port-Of: odoo/enterprise#70554
Original PR description
Version: - 18.0 Steps to reproduce: - create a subscription sale order - confirm the sale order Issue: - two create invoice button are visible Cause: - The conditions for showing the two "Create Invoice" buttons overlapped, making both appear at the same time Solution: - Adjusted button conditions to ensure only one "Create Invoice" button is displayed when no invoice is created Forward-Port-Of: odoo/enterprise#70554
Before this commit when creating shortcut / duplicating / archiving / renaming a folder the search panel wasn't reloaded and thus the folder still appeared in it. This commit fixes this. Task-4219258 Forward-Port-Of: odoo/enterprise#71028
Original PR description
Before this commit when creating shortcut / duplicating / archiving / renaming a folder the search panel wasn't reloaded and thus the folder still appeared in it. This commit fixes this. Task-4219258 Forward-Port-Of: odoo/enterprise#71028
Purpose: -------- In commit [1], the field holding the access token inside the file model has been renamed from accessToken to access_token. This commit adds the renaming of the related accessToken prop of the embedded file component during the migration of the file behavior. [1]: https://github.com/odoo/odoo/commit/448c9791dd1980d1aa3c244a9f85828424c7e10b Task-4221554 Forward-Port-Of: odoo/enterprise#71117
Original PR description
Purpose: -------- In commit [1], the field holding the access token inside the file model has been renamed from accessToken to access_token. This commit adds the renaming of the related accessToken prop of the embedded file component during the migration of the file behavior. [1]: https://github.com/odoo/odoo/commit/448c9791dd1980d1aa3c244a9f85828424c7e10b Task-4221554 Forward-Port-Of: odoo/enterprise#71117
This commit aims at fixing an issue with message containing attachments. Those attachments can be displayed too small resulting in scrollbars and weird displays. In e8df9ed4a92e we tried to fix this by using the environment variable inChatWindow, but this changed the styling of comments drastically. So in this commit we remove this option and directly apply the correct style to the attachment cards. task-4221276 Forward-Port-Of: odoo/enterprise#71100
Original PR description
This commit aims at fixing an issue with message containing attachments. Those attachments can be displayed too small resulting in scrollbars and weird displays. In e8df9ed4a92e we tried to fix this by using the environment variable inChatWindow, but this changed the styling of comments drastically. So in this commit we remove this option and directly apply the correct style to the attachment cards. task-4221276 Forward-Port-Of: odoo/enterprise#71100
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t
Original PR description
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer…
### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here: https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense. opw-4159779 Forward-Port-Of: odoo/enterprise#70748 Forward-Port-Of: odoo/enterprise#69936
Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore. Forward-Port-Of: odoo/enterprise#71075 Forward-Port-Of: odoo/enterprise#71012
Original PR description
Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore. Forward-Port-Of: odoo/enterprise#71075 Forward-Port-Of: odoo/enterprise#71012
Enable the copy of a financial report. Right now, when duplicating a financial report (or several at the same time), only the name is copied (same name, not even a "(copy)" after. We want to improve it by adding this "(copy)" in the title, and also copy the budget lines. This will enable a user to not start from scratch every time he wants to create a new financial budget. task-4207202 Forward-Port-Of: odoo/enterprise#70805
Original PR description
Enable the copy of a financial report. Right now, when duplicating a financial report (or several at the same time), only the name is copied (same name, not even a "(copy)" after. We want to improve it by adding this "(copy)" in the title, and also copy the budget lines. This will enable a user to not start from scratch every time he wants to create a new financial budget. task-4207202 Forward-Port-Of: odoo/enterprise#70805
Some btn-group classes were missing creating inconsistent looks among the buttons. The presence of the xpath for the share and freeze btn breaks the style when there are only the actions and share btns to display on the ctrl panel. task-3373836 Forward-Port-Of: odoo/enterprise#70851
Original PR description
Some btn-group classes were missing creating inconsistent looks among the buttons. The presence of the xpath for the share and freeze btn breaks the style when there are only the actions and share btns to display on the ctrl panel. task-3373836 Forward-Port-Of: odoo/enterprise#70851
To reproduce: Open a non-pinned folder in "Company", the breadcrumb will not be correctly shown and actions are not available. When simply removed from the returned records, no item is added in the breadcrumbs on opening a non-pinned company root folder. Co-authored-by: Lopes Marc (loma) <loma@odoo.com> Task-4216195 Forward-Port-Of: odoo/enterprise#71042
Original PR description
To reproduce: Open a non-pinned folder in "Company", the breadcrumb will not be correctly shown and actions are not available. When simply removed from the returned records, no item is added in the breadcrumbs on opening a non-pinned company root folder. Co-authored-by: Lopes Marc (loma) <loma@odoo.com> Task-4216195 Forward-Port-Of: odoo/enterprise#71042
Steps to Reproduce: - Open the planning app. - Create a planning for a resource. - Make sure resource doesn't have any past or future plannings. - Change the time frame to next week. Issue: - We don't see an empty line. Reason: In the PR https://github.com/odoo/enterprise/pull/55618. All the gantt time ranges have domain strictly comparative operators(> and <). But in group_expand_resource_ids we use non strict comparative operators(>= and <=). Fix: - Added strictly comp
Original PR description
Steps to Reproduce: - Open the planning app. - Create a planning for a resource. - Make sure resource doesn't have any past or future plannings. - Change the time frame to next week. Issue: - We don't see an empty line. Reason: In the PR https://github.com/odoo/enterprise/pull/55618. All the gantt time ranges have domain strictly comparative operators(> and <). But in group_expand_resource_ids we use non strict comparative operators(>= and <=). Fix: - Added strictly comparative operators into operators being checked. task-4188936 Forward-Port-Of: odoo/enterprise#70454
The 'This Station' default filter was introduced in [1] as a stopgap solution for limiting the amount of MOs loaded simultaneously in the view, to avoid performance bottlenecks. Since the introduction of a limit (also in [1]), as well as later performance improvements from [2], the performance of the shop floor is now acceptable without this filter, so we proceed with removing it completely in this PR. [1] https://github.com/odoo/enterprise/pull/64551 [2] https://github.com/odoo/enterpris
Original PR description
The 'This Station' default filter was introduced in [1] as a stopgap solution for limiting the amount of MOs loaded simultaneously in the view, to avoid performance bottlenecks. Since the introduction of a limit (also in [1]), as well as later performance improvements from [2], the performance of the shop floor is now acceptable without this filter, so we proceed with removing it completely in this PR. [1] https://github.com/odoo/enterprise/pull/64551 [2] https://github.com/odoo/enterprise/pull/66898 Forward-Port-Of: odoo/enterprise#70777
Before this commit, changing the partner in POS for the EC localization was raising an OWL error. This error happens because missingFields got stripped from most of the codebase, including PartnerList, leading to an "Invalid Props" error in Owl. This was preventing users from selecting a partner other than the default "consumidor final". After this commit, clicking the partner button correctly opens the "partner selection" popup. opw-4171779 opw-4192162 Forward-Port-Of: odoo/enterpr
Original PR description
Before this commit, changing the partner in POS for the EC localization was raising an OWL error. This error happens because missingFields got stripped from most of the codebase, including PartnerList, leading to an "Invalid Props" error in Owl. This was preventing users from selecting a partner other than the default "consumidor final". After this commit, clicking the partner button correctly opens the "partner selection" popup. opw-4171779 opw-4192162 Forward-Port-Of: odoo/enterprise#70559
### Steps to reproduce: - Install Field Service module - Set 12-hour time format in the languages - Navigate to My tasks kanban view in Field Service ### Current behavior before PR: When having 12-hour time format for Field Service it will be shown in the kanban view as '02:00 A' for example. This is happening because when formatting the time in the fsm_date widget the format we are using have a typo 'hh:mm A' where the 'AM, PM' should be represented with lowercase 'a' not uppercase 'A
Original PR description
### Steps to reproduce: - Install Field Service module - Set 12-hour time format in the languages - Navigate to My tasks kanban view in Field Service ### Current behavior before PR: When having 12-hour time format for Field Service it will be shown in the kanban view as '02:00 A' for example. This is happening because when formatting the time in the fsm_date widget the format we are using have a typo 'hh:mm A' where the 'AM, PM' should be represented with lowercase 'a' not uppercase 'A' ### Desired behavior after PR is merged: Fixed the typo and added the correct format opw-4178726 Forward-Port-Of: odoo/enterprise#70922 Forward-Port-Of: odoo/enterprise#70250
Steps to reproduce: - Sign > Edit any template > Add a field - Click your field > Select left alignment > Validate The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block. The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent
Original PR description
Steps to reproduce: - Sign > Edit any template > Add a field - Click your field > Select left alignment > Validate The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block. The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent even without this class. opw-4159676 Forward-Port-Of: odoo/enterprise#70307
Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior - Component: - C1: - Routes: “Resupply Subcontractor on Order” - Create a purchase order for one unit of “P1” - Confirm the PO - Create a second PO for one unit of “C1” and receive it - Confirm the resupply picking of C1 - Confirm the receipt of P1 **Problem:** A validation error is
Original PR description
Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior -…
Steps to reproduce the bug:
- Log in as a Kenyan company
- Create a storable product “P1” with the following Bill of Materials (BoM):
- Type: Subcontracting
- Subcontractor: Azure Interior
- Component:
- C1: - Routes: “Resupply Subcontractor on Order”
- Create a purchase order for one unit of “P1”
- Confirm the PO
- Create a second PO for one unit of “C1” and receive it
- Confirm the resupply picking of C1
- Confirm the receipt of P1
**Problem:**
A validation error is triggered: “You cannot end up with a negative stock quantity.”
We added a constraint to prevent negative stock quantities in internal locations for a company in Kenya. However, the location linked to subcontracting is internal but has no warehouse, so we don’t care if its quantity is negative, and it should be ignored. This could also happen with other internal locations that don’t have a warehouse.
Additionally, when reporting stock quantities, we only consider
quantities in locations that have a warehouse:
https://github.com/odoo/enterprise/blob/9dea0f2696084235ee1192b0a14adfa43eb732ef/l10n_ke_edi_oscu_stock/models/product.py#L47
opw-4184857
Forward-Port-Of: odoo/enterprise#70808Refactor Knowledge to use the new features of the editor. Behaviors are converted to Embedded Components which are now natively supported in the html_editor module. (Embedded Components is a feature of the HtmlField allowing to mount Owl components inside an HtmlField value, based on metadata stored in the attributes of html nodes) ### website_knowledge is no longer forgotten Public version of an article is now using the HtmlViewer to render the Html value, and this allows to mount em
Original PR description
Refactor Knowledge to use the new features of the editor. Behaviors are converted to Embedded Components which are now natively supported in the html_editor module. (Embedded Components is a feature…
Refactor Knowledge to use the new features of the editor. Behaviors are converted to Embedded Components which are now natively supported in the html_editor module. (Embedded Components is a feature of the HtmlField allowing to mount Owl components inside an HtmlField value, based on metadata stored in the attributes of html nodes) ### website_knowledge is no longer forgotten Public version of an article is now using the HtmlViewer to render the Html value, and this allows to mount embedded components as they would be in the backend view. This results in a far better reading experience for public users. ### Comments Overhaul of the feature, in a concise way: anchoring a comment in the HtmlField value is way less expensive in terms of amount of characters since it uses 2 self closing `<a>` nodes instead of wrapping every text node in a `<span>` (which could be hundreds for a comment spanning over an entire document). This is also easier to manage during edition, since new nodes between the boundaries of a comment don't need to be processed so that they are marked as part of a comment anymore. Loading threads and messages is now centralized in a `comments_service` which batches rpc calls together, significantly reducing the load when opening an article. The comment panel now has a "load more" feature, meaning that it does not load every single existing thread and their messages at once when opening it. Floating "Comment boxes" are now perfectly aligned with their anchor in the HtmlField when they are focused (previously they were pushed by other Comments boxes above them when there was not enough space, even when active). ### Embedded Components All existing Behaviors are converted to embedded components, and some of them are moved in the html_editor module #### knowledge: - Article Link - Article Index - Clipboard - Embedded View - Embedded view Link #### html_editor: - Excalidraw - File - Table of Content - Video ### Migration Since metadata for Behaviors differ from those of Embedded Components, and upgrading an html value is expensive, this transition will be handled client-side for starts. A small JS upgrade feature for html values is introduced. The "upgrade" will be attempted once, and won't result in a crash if it fails. Instead, the previous value will be conserved, and the user will be able to adjust the content manually by using editor commands. Odoo Community: https://github.com/odoo/odoo/pull/173997 task-3672747 Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Adrien Schoffeniels <adsc@odoo.com> Co-authored-by: Julien Banken <jbn@odoo.com> Co-authored-by: Thomas Josse <thjo@odoo.com> Forward-Port-Of: odoo/enterprise#67083
Issue: ====== `paid_amount` is not calculated correctly when the schedule pay isn't month. Steps to reproduce the issue: ============================= - Switch to MX company - Go to roque and employee and add these values to his contract : salary structure type( Mexico:Employee) - both schedule pay fields (weekly) - add any amount in wage. - Go to payslips and create one for roque and click on compute sheet - Go to salary computation tab - Basic salary is wrong it should be the amount
Original PR description
Issue: ====== `paid_amount` is not calculated correctly when the schedule pay isn't month. Steps to reproduce the issue: ============================= - Switch to MX company - Go to roque and employee and add these values to his contract : salary structure type( Mexico:Employee) - both schedule pay fields (weekly) - add any amount in wage. - Go to payslips and create one for roque and click on compute sheet - Go to salary computation tab - Basic salary is wrong it should be the amount you put at the start. Origin of the issue and solution: ================================= We were dividing by the coefficient of the pay schedule but in reality we didn't have to since we create the payslip for the period of the schedule pay so it will have the full mentioned wage. But for the christmas we need to divide by the coefficient since it's computed by `days/year`. opw-413332 Forward-Port-Of: odoo/enterprise#70136
Steps to reproduce: - Intall Payroll and Switzerland localization > Switch to CH company - Employees > New > Work Information tab > Set any Canton - Create a contract for that employee > Set it to 'Running' state - Payroll > Work Entries > Work Entries > Remove filters - Navigate to next month > Regenerate Work Entries - Generate Payslips > Error is raised This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returne
Original PR description
Steps to reproduce: - Intall Payroll and Switzerland localization > Switch to CH company - Employees > New > Work Information tab > Set any Canton - Create a contract for that employee > Set it to 'Running' state - Payroll > Work Entries > Work Entries > Remove filters - Navigate to next month > Regenerate Work Entries - Generate Payslips > Error is raised This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returned line.amount). This was most likely just a typo using the wrong decimal separator which turned th fallback into a tuple, breaking on the following operations. opw-4204580 Forward-Port-Of: odoo/enterprise#71071 Forward-Port-Of: odoo/enterprise#70751
In the community-side, we allow the reservation on all transit locations (i.e. Inter-Company transit as well). Adds a test where an interco PO is generated in draft then confirmed after the delivery was done in the other company, as it can now reserve on the already delivered quantities. Task-4207078 Forward-Port-Of: odoo/enterprise#70737
Original PR description
In the community-side, we allow the reservation on all transit locations (i.e. Inter-Company transit as well). Adds a test where an interco PO is generated in draft then confirmed after the delivery was done in the other company, as it can now reserve on the already delivered quantities. Task-4207078 Forward-Port-Of: odoo/enterprise#70737
This commit modifies the MO cost of operations. Now, when the production is started and if there is no duration expected on the operation, the mo cost of the operation will be the theorical cost of the real duration (i.e. it will be the result of machine + labour cost for that duration). When the production is done, the same behaviour will be applied, but without the labour cost. The timesheet cost of an operator for the MO cost column is now computed based on the operation's workcenter e
Original PR description
This commit modifies the MO cost of operations. Now, when the production is started and if there is no duration expected on the operation, the mo cost of the operation will be the theorical cost of the real duration (i.e. it will be the result of machine + labour cost for that duration). When the production is done, the same behaviour will be applied, but without the labour cost. The timesheet cost of an operator for the MO cost column is now computed based on the operation's workcenter employee cost. Forward-Port-Of: odoo/enterprise#70854
Installing this module with demo data gives an error "You need to link this user to an employee of this company to process the work order" As the installation user is "__system__" there is no linked employee. Forward-Port-Of: odoo/enterprise#71020
Original PR description
Installing this module with demo data gives an error "You need to link this user to an employee of this company to process the work order" As the installation user is "__system__" there is no linked employee. Forward-Port-Of: odoo/enterprise#71020
Products created by scanning a barcode in a receipt (Barcode app) should by default be storable ("Track Inventory" checked). This includes a situation when barcodelookup.com is configured. Forward-Port-Of: odoo/enterprise#70755
Original PR description
Products created by scanning a barcode in a receipt (Barcode app) should by default be storable ("Track Inventory" checked). This includes a situation when barcodelookup.com is configured.
Forward-Port-Of: odoo/enterprise#70755…ewing This commit fixes the remaining actions after switching folders while previewing a document. Forward-Port-Of: odoo/enterprise#70773
Original PR description
…ewing This commit fixes the remaining actions after switching folders while previewing a document. Forward-Port-Of: odoo/enterprise#70773
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * CFDI to public: [Checked] * Invoice Date: [Today] * Payment terms: [the following month] (e.g. 30 Days) - Confirm the invoice - Register a payment **Issues:** 1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked. 2) It is not possible to sign the p
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * CFDI to public: [Checked] * Invoice Date: [Today] * Payment terms: [the following month] (e.g. 30 Days) - Confirm the invoice - Register a payment **Issues:** 1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked. 2) It is not possible to sign the payment when the generic rfc (i.e. XAXX010101000) is used. opw-4145716 opw-4127870 Forward-Port-Of: odoo/enterprise#70974 Forward-Port-Of: odoo/enterprise#70470
This commit adds the missing neutralization necessary for the hr_recruitment_integration_monster module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database
Original PR description
This commit adds the missing neutralization necessary for the hr_recruitment_integration_monster module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/70213 Forward-Port-Of: odoo/enterprise#70789
Task~4215979 Forward-Port-Of: odoo/enterprise#70848
Original PR description
Task~4215979 Forward-Port-Of: odoo/enterprise#70848
This commit fixes small UI issues introduced by the conversion of kanban archs to the new API [1], in the helpdesk team dashboards. [1] https://github.com/odoo/enterprise/pull/70127 Task~4215979 Forward-Port-Of: odoo/enterprise#70904
Original PR description
This commit fixes small UI issues introduced by the conversion of kanban archs to the new API [1], in the helpdesk team dashboards. [1] https://github.com/odoo/enterprise/pull/70127 Task~4215979 Forward-Port-Of: odoo/enterprise#70904
First commit will add a new action to open the partner ledger from the customer list view. And the second will rename the follow up action and all occurence of the "send SMS text message" to "send SMS" task: 4213146 Forward-Port-Of: odoo/enterprise#70790
Original PR description
First commit will add a new action to open the partner ledger from the customer list view. And the second will rename the follow up action and all occurence of the "send SMS text message" to "send SMS" task: 4213146 Forward-Port-Of: odoo/enterprise#70790
The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line: ```py if from_post and move == closing_moves_by_company[self.env.company]: ``` triggered the insertion of a new key when `self.env.company` was not already present,
Original PR description
The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line: ```py if from_post and move == closing_moves_by_company[self.env.company]: ``` triggered the insertion of a new key when `self.env.company` was not already present, leading to the runtime error. This commit changes the access method to use `.get()` instead of directly accessing the key allowing, safe retrieval of the value without modifying the dictionary. opw-4089738 Forward-Port-Of: odoo/enterprise#70500
After this commit: ==== - A new pos_urban_piper_ubereats module added to support Ubereats integration with Urbanpiper. Task-4190230 Forward-Port-Of: odoo/enterprise#70437
Original PR description
After this commit: ==== - A new pos_urban_piper_ubereats module added to support Ubereats integration with Urbanpiper. Task-4190230 Forward-Port-Of: odoo/enterprise#70437
3 changes
Resolved issues and error corrections
A test display showing the difference between actual and expected daily time was accidentally left visible in the timesheet timer. This fix removes the unintended display so users only see the actual time spent on tasks, not internal testing information.
Original PR description
Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649
This update fixes a visual problem where buttons were appearing cropped or misaligned in the signature request form. The fix reorganizes how the button visibility is controlled, resulting in a cleaner and properly displayed interface for users sending signature requests.
Original PR description
Before this commit, the div was addded for additional condition for button visibility which causing button asymtry and cropping button. after this commit, moved visibility condition in invisible attribute of button.
A recent improvement to how fiscal positions are determined in the system now requires additional database queries. This update adjusts the performance test expectations to match the new query count, ensuring tests continue to pass accurately.
Original PR description
After a fix in `res_partner._get_fiscal_position`
we extract the line `eu_country_codes =
set(self.env.ref('base.europe').country_ids.mapped('code'))`
from a condition, therefore we make extra queries and we have to adapt
the `assertQueryCount`.
opw-4072691