Friday, February 16, 2024
46 changes · saas-17.1
Miscellaneous changes
**Steps to reproduce** 1. Visit the website and open the event tab. 2. Access an event with the talks and exhibitor sub-menu. 3. Select the talks sub-menu and search for a talk -> Even if the talk exists, the search count shows zero -> The same thing happens in the exhibitor sub-menu **Technical** When searching for the talk or the exhibitor we didn't send the search_count due to this, it is always showing zero. A variable `sponsors` is renamed to `sorted_sponsors` as it was redeclar
Original PR description
**Steps to reproduce** 1. Visit the website and open the event tab. 2. Access an event with the talks and exhibitor sub-menu. 3. Select the talks sub-menu and search for a talk -> Even if the talk exists, the search count shows zero -> The same thing happens in the exhibitor sub-menu **Technical** When searching for the talk or the exhibitor we didn't send the search_count due to this, it is always showing zero. A variable `sponsors` is renamed to `sorted_sponsors` as it was redeclared in the loop before the return dict **After this PR** Now the search_count will display the accurate result. Task-3659940 Forward-Port-Of: odoo/odoo#147876
This commit follows [1], which attempted to fix CORS errors occurring when we access the `cssRules` property of stylesheets, to detect scss compilation errors and display a warning to the user. [1] doesn't seem to be enough, as we faced another source of CORS errors. Indeed, in non-secure http, the error is raised even if the origin is the same. We never want this access to crash anyway, as it's a nice to have feature, and if reading `cssRules` is forbidden, there's nothing the user can do
Original PR description
This commit follows [1], which attempted to fix CORS errors occurring when we access the `cssRules` property of stylesheets, to detect scss compilation errors and display a warning to the user. [1] doesn't seem to be enough, as we faced another source of CORS errors. Indeed, in non-secure http, the error is raised even if the origin is the same. We never want this access to crash anyway, as it's a nice to have feature, and if reading `cssRules` is forbidden, there's nothing the user can do anyway. For those reasons, we decided to simply protect the code with a try/catch. [1] odoo/odoo#152696 opw 3746910 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#154347
### Steps to reproduce issue: 1. Select a Contact 2. Click on Smart Button "Loyalty Cards" 3. Create a new Loyalty Coupon 4. Save 5. Receive an error: > The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. > > Model: Loyalty Coupon (loyalty.card) > Constraint: loyalty_card_program_id_fkey ### Explanation: The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the
Original PR description
### Steps to reproduce issue: 1. Select a Contact 2. Click on Smart Button "Loyalty Cards" 3. Create a new Loyalty Coupon 4. Save 5. Receive an error: > The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. > > Model: Loyalty Coupon (loyalty.card) > Constraint: loyalty_card_program_id_fkey ### Explanation: The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the case of the issue, for example, the model is `res.partner`. https://github.com/odoo/odoo/blob/a3201d636505dc1976d3f0ee7f8cbf65d2488966/addons/loyalty/models/loyalty_card.py#L27 ### Suggested fix: The creation of `loyalty.card` from `res.partner` Smart Button is not intended, therefore we will remove this option and set the Smart Button as invisible if `loyalty_card_count` is null. opw-3707588 Forward-Port-Of: odoo/odoo#154258 Forward-Port-Of: odoo/odoo#152644
**Steps to reproduce:** 1- Install Sales module 2- Activate developer mode 3- Navigate to any storable product 4- Click on 'Replenish' 5- Click on 'developer bug' and Choose 'Set Defaults' 6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save **Current behavior before PR:** When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a dat
Original PR description
**Steps to reproduce:** 1- Install Sales module 2- Activate developer mode 3- Navigate to any storable product 4- Click on 'Replenish' 5- Click on 'developer bug' and Choose 'Set Defaults' 6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save **Current behavior before PR:** When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI. **Desired behavior after PR is merged:** It is handled now from the UI side that the format that is been sent is the server valid format of datetime. opw-3692472 Forward-Port-Of: odoo/odoo#150447
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in
Original PR description
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:**…
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in the top right 2. In Accounting settings, select the Estonia fiscal localization package and save (this causes the exception) **Cause of the issue:** Certain tax accounts in the module do not have their names fully updated. They all were labeled as "0% ..." instead of their true percentages like all other tax accounts. **Fix:** Update the names of the offending tax accounts so that they are fully reflective of their true %. Associated with https://github.com/odoo/enterprise/pull/56496 opw-3683538 Forward-Port-Of: odoo/odoo#151515
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead to the error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the pr
Original PR description
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead…
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead to the error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’." On the other hand, some extra-european countries use Peppol Bis 3 but do not prepend their VAT with the country code (i.e. Australia). To allow such cases, we automatically add the country code when it's missing. To prevent regression, we also add a contraint mimicking the schematron: we check that the final value of the PartyTaxScheme/CompanyID is prefixed with a 2 letters code. This way, the constraint is independant from the code. Forward-Port-Of: odoo/odoo#154233 Forward-Port-Of: odoo/odoo#151352
The model `l10n_pl_tax_office` has a group to be able to access it. The Many2one that refers to it, `l10n_pl_reports_tax_office_id`, does not. Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust Linked to runbot error 24602, 24721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154294 Forward-Port-Of: odoo/
Original PR description
The model `l10n_pl_tax_office` has a group to be able to access it. The Many2one that refers to it, `l10n_pl_reports_tax_office_id`, does not. Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust Linked to runbot error 24602, 24721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154294 Forward-Port-Of: odoo/odoo#153660
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation: - Create a new transfer for each date_deadline - Merge the move with distinct date_deadline Usually, it makes sense to not merge moves with distinct date_deadline, but it
Original PR description
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer…
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation: - Create a new transfer for each date_deadline - Merge the move with distinct date_deadline Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day. So for now, we treat this situation as a limitation, but we still provide a workaround: By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves. ## HOW TO REPRODUCE: - Create new Warehouse 'Warehouse 2' WH2 - Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot) - Create product P1 (storable, with custom route selected) - Create reordering rule on default warehouse, with min=1, max=1, route=custom route - Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated - Wait 1 day (alternative is to increment the Lead Time on the Stock Rules). - Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present. OPW-3633551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154276 Forward-Port-Of: odoo/odoo#151499
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectangle" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: ---------
Original PR description
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectangle" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: --------- We can use `preventDefault` to block the second event (the click) because the event is the same. Note: ----- This fix is safer than patching the `FullCalendar` library (which may change in future versions). opw-3743945 Forward-Port-Of: odoo/odoo#154135
Make the set() of module sorted, aka a list. We can be pretty sure that nobody relied on the order of this set before since it was completely underterministic. Therefore this change should not break anything and make the testing on runbot more consistant. This is mainly following the issue with the sql-injection testing failing randomly with the order of the modules. Forward-Port-Of: odoo/odoo#154140
Original PR description
Make the set() of module sorted, aka a list. We can be pretty sure that nobody relied on the order of this set before since it was completely underterministic. Therefore this change should not break anything and make the testing on runbot more consistant. This is mainly following the issue with the sql-injection testing failing randomly with the order of the modules. Forward-Port-Of: odoo/odoo#154140
Since 16.3, opening the web client on the Odoo backends results in two subscribe events being sent through the bus websocket. Discuss listens to the thread changes to know when the subscription should be refreshed. In order to do so, the last subscription that was made is kept. This issue is that this subscription is empty in the first place so the first evaluation always considers the subscription should be made. In order to fix this issue, this PR refine the condition to determine
Original PR description
Since 16.3, opening the web client on the Odoo backends results in two subscribe events being sent through the bus websocket. Discuss listens to the thread changes to know when the subscription should be refreshed. In order to do so, the last subscription that was made is kept. This issue is that this subscription is empty in the first place so the first evaluation always considers the subscription should be made. In order to fix this issue, this PR refine the condition to determine if the subscription should be renewed: - The last subscription is different from the last one - The user joined a channel after the bus initialization - The user left a channel after the bus initialization In order to test those scenario in a reliable way, this PR also backports https://github.com/odoo/odoo/pull/147455 Forward-Port-Of: odoo/odoo#154170 Forward-Port-Of: odoo/odoo#153666
Prior to this commit, automatic printing was only functional when a printer was configured with the Point of Sale. It did not support web printing. This commit rectifies this issue, allowing automatic printing to work seamlessly with or without a physical printer setup, supporting web printing. opw-3706400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154066
Original PR description
Prior to this commit, automatic printing was only functional when a printer was configured with the Point of Sale. It did not support web printing. This commit rectifies this issue, allowing automatic printing to work seamlessly with or without a physical printer setup, supporting web printing. opw-3706400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154066
Steps to reproduce: ------------------- 1. Install sale_project with demo data 2. Create a user with no access rights other than Project/User 3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update 4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More' This will give an access rights error. The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leadin
Original PR description
Steps to reproduce: ------------------- 1. Install sale_project with demo data 2. Create a user with no access rights other than Project/User 3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update 4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More' This will give an access rights error. The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leading to an access right error. This PR adds two sudos to avoid that error. Forward-Port-Of: odoo/odoo#154025
Current behavior: When you make an order in the PoS with different lots for the same product, the lots are not correctly selected in the picking. And only one lot is affected by the order. Steps to reproduce: - Create a product with tracking by lot, and 2 lots with some quantity - Create a PoS order with 2 lines of the same product, and select a different lot for each line - Validate the order - Close the PoS session - Check the picking, and the lot quantities Note: This partly reve
Original PR description
Current behavior: When you make an order in the PoS with different lots for the same product, the lots are not correctly selected in the picking. And only one lot is affected by the order. Steps to reproduce: - Create a product with tracking by lot, and 2 lots with some quantity - Create a PoS order with 2 lines of the same product, and select a different lot for each line - Validate the order - Close the PoS session - Check the picking, and the lot quantities Note: This partly revert this part of commit : https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-0ef4eb66998f308afe5f09748bc2af04ad79e9647507c25fe9007e03a79a1249L265-L303 And also make sure that the original created line quantity is set to 0 so that the each lot has a line, and the total quantity is correct. opw-3621363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148517
CLA for enterprise PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153820
Original PR description
CLA for enterprise PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153820
You have to unlock the order before cancelling it. Introduced by 17bece3e797913bcba8dd7e07fc8541c0a45e3f7 Fixes #153987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154259
Original PR description
You have to unlock the order before cancelling it. Introduced by 17bece3e797913bcba8dd7e07fc8541c0a45e3f7 Fixes #153987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154259
Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437adc2b5db2 removed the dep
Original PR description
Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both…
Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437adc2b5db2 removed the dependence of sale_temporal for sale_subcription. After that, there was no point in keeping the sale_temporal dependence in sale_renting. Thus, the dependence for sale_temporal has also been removed here: https://github.com/odoo/enterprise/commit/6c86a278dbc752009c0985702cb2927c26f5f636. The module sale_temporal was responsible for checking incompatible products types. Currently, both sale_renting and sale_subscription have the module sale in common. This commit is part of a 2-part fix and targets Odoo Community. It transfers the code responsible for the checking of incompatible product types in the module sale. Code transferred: https://github.com/odoo/enterprise/blob/4cf9e6f013f75c082c5b5b42b9d2591554b75503/sale_temporal/models/product_template.py#L15-L33 PR in Enterprise: https://github.com/odoo/enterprise/pull/54940 opw-3678715 Forward-Port-Of: odoo/odoo#150688
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#146213
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#146213
Since PR #137969, the `save` button is no longer available in schedule activity wizard. This PR makes `schedule` button available for call activities like other activities (except meeting), so user can create a call activity without going to calendar view. Before this PR:  After this PR:  task-3668732
Original PR description
Since PR #137969, the `save` button is no longer available in schedule activity wizard. This PR makes `schedule` button available for call activities like other activities (except meeting), so user can create a call activity without going to calendar view. Before this PR:  After this PR:  task-3668732 Forward-Port-Of: odoo/odoo#152893
Steps to reproduce: - - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: - The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. https://github.com/odoo/odoo/blob/31100f22ad7e31daea65de446439b090f70ad9de/addons/calendar/models/calendar_event.py#L548-L556
Original PR description
Steps to reproduce: - - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: - The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. https://github.com/odoo/odoo/blob/31100f22ad7e31daea65de446439b090f70ad9de/addons/calendar/models/calendar_event.py#L548-L556 Fix: - Since we don't want to send_mail_to_attendees anyway, we skip this part of the write method using the already existing contextual escape 'is_calendar_event_new'. opw-3733753 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153908 Forward-Port-Of: odoo/odoo#153430
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153464In this commit ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2 Forward-Port-Of: odoo/odoo#154120
Original PR description
In this commit ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2 Forward-Port-Of: odoo/odoo#154120
Forward-Port-Of: odoo/odoo#154195
Original PR description
Forward-Port-Of: odoo/odoo#154195
https://github.com/odoo/enterprise/commit/9a0a3f96a9fc377b39db767155f57cd434908ce9 introduced the default 'NURG' SvcLvl value for all SEPA and ISO20022 files. However, this node should not be there for the Swiss version, and was incorrectly added in its files when generating payments in other currencies as EUR, since those were qualified as generic. A XOR on the condition solves the issue. OPW 3725981 3730908 Forward-Port-Of: odoo/enterprise#56754 Forward-Port-Of: odoo/enterprise#56704
Original PR description
https://github.com/odoo/enterprise/commit/9a0a3f96a9fc377b39db767155f57cd434908ce9 introduced the default 'NURG' SvcLvl value for all SEPA and ISO20022 files. However, this node should not be there for the Swiss version, and was incorrectly added in its files when generating payments in other currencies as EUR, since those were qualified as generic. A XOR on the condition solves the issue. OPW 3725981 3730908 Forward-Port-Of: odoo/enterprise#56754 Forward-Port-Of: odoo/enterprise#56704
Current behavior: The ebay location found in the Settings App is not being saved due to an empty config_parameter. Creating an config_parameter for this field will allow the field to be saved after being filled. opw-3722548 Forward-Port-Of: odoo/enterprise#56731
Original PR description
Current behavior: The ebay location found in the Settings App is not being saved due to an empty config_parameter. Creating an config_parameter for this field will allow the field to be saved after being filled. opw-3722548 Forward-Port-Of: odoo/enterprise#56731
It's confusing to allow resubmitting electronic invoices. When invoices are rejected the user will probably make changes to them in Odoo. Resubmitting will use the old, saved tax response data in l10n_br_edi_avatax_data which won't be correct anymore for the new configuration. Instead, the user should reset to draft, redo tax computation and then resubmit. task-3711015 Forward-Port-Of: odoo/enterprise#56576
Original PR description
It's confusing to allow resubmitting electronic invoices. When invoices are rejected the user will probably make changes to them in Odoo. Resubmitting will use the old, saved tax response data in l10n_br_edi_avatax_data which won't be correct anymore for the new configuration. Instead, the user should reset to draft, redo tax computation and then resubmit. task-3711015 Forward-Port-Of: odoo/enterprise#56576
Before this, a subscription with partial exemptions wouldn't be automatically invoiced. It's caused by field dependencies added by sale_subscription that cause the order totals to be recomputed after confirmation. More specifically, sale.order.line.discount is made to depend on subscription_state, which gets written to during action_confirm(). Because of this _invoice_sale_orders() will filter out the payment transaction because _get_partial_payment_subscription_transaction() considers it a p
Original PR description
Before this, a subscription with partial exemptions wouldn't be automatically invoiced. It's caused by field dependencies added by sale_subscription that cause the order totals to be recomputed after confirmation. More specifically, sale.order.line.discount is made to depend on subscription_state, which gets written to during action_confirm(). Because of this _invoice_sale_orders() will filter out the payment transaction because _get_partial_payment_subscription_transaction() considers it a partial payment. opw-3562613 Forward-Port-Of: odoo/enterprise#55579
Currently, when an employee contract belongs to a company different than the employee's company, a warning is shown in the payroll dashboard [1]. However, if the current user has no access to the contract's company, an access error is raised, which makes not possible to neither see the warning nor load the dashboard. This commit fixes the above issue by ensuring the employee contract is read as sudo, to avoid requiring the current user to have both companies selected to see the warning. R
Original PR description
Currently, when an employee contract belongs to a company different than the employee's company, a warning is shown in the payroll dashboard [1]. However, if the current user has no access to the contract's company, an access error is raised, which makes not possible to neither see the warning nor load the dashboard. This commit fixes the above issue by ensuring the employee contract is read as sudo, to avoid requiring the current user to have both companies selected to see the warning. References: - [1] https://github.com/odoo/enterprise/blob/e41d2ce5/hr_payroll/models/hr_payslip.py#L1072 **Access Error:**  Forward-Port-Of: odoo/enterprise#56425 Forward-Port-Of: odoo/enterprise#56335
Currently if you do not have any payroll rights and you are your own attendance manager, you will not be able to create or write attendances since those affect hr.work.entries that you do not have any rights on, this issue is fixed by using sudo in the work entry creation and modification task-3734639 Forward-Port-Of: odoo/enterprise#56176
Original PR description
Currently if you do not have any payroll rights and you are your own attendance manager, you will not be able to create or write attendances since those affect hr.work.entries that you do not have any rights on, this issue is fixed by using sudo in the work entry creation and modification task-3734639 Forward-Port-Of: odoo/enterprise#56176
Create a branch In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Switch to the branch only and try to access the accounting app Access error raises: """ Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Bank Connection, Plaid (account.online.link: 2, company=parent nico) Blame the following rules: - Account online link company rule Note: this might be a multi-company
Original PR description
Create a branch In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Switch to the branch only and try to access the accounting app Access error raises: """ Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Bank Connection, Plaid (account.online.link: 2, company=parent nico) Blame the following rules: - Account online link company rule Note: this might be a multi-company issue. Switching company may help - in Odoo, not in real life! If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. """ This occurs because the mentioned record rule allow access to the `account.online.link` record only from the same company opw-3725198 Forward-Port-Of: odoo/enterprise#56136
How to reproduce: - Open a planned transfer in the Barcode App; - Scan a non-reserved product => A confirmation dialog is shown; - Discard or close the confirmation dialog => Traceback! It happens because rejected promises have to be handle which is not the case here. To fix that, resolve the promise anyway. task-3677142 Forward-Port-Of: odoo/enterprise#55979
Original PR description
How to reproduce: - Open a planned transfer in the Barcode App; - Scan a non-reserved product => A confirmation dialog is shown; - Discard or close the confirmation dialog => Traceback! It happens because rejected promises have to be handle which is not the case here. To fix that, resolve the promise anyway. task-3677142 Forward-Port-Of: odoo/enterprise#55979
Bug === 1. Open the comments modal of a LInkedIn post 2. Click on "Reply" on a comment without answer => Traceback Task-3748995 Forward-Port-Of: odoo/enterprise#56773 Forward-Port-Of: odoo/enterprise#56689
Original PR description
Bug === 1. Open the comments modal of a LInkedIn post 2. Click on "Reply" on a comment without answer => Traceback Task-3748995 Forward-Port-Of: odoo/enterprise#56773 Forward-Port-Of: odoo/enterprise#56689
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in
Original PR description
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:**…
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in the top right 2. In Accounting settings, select the Estonia fiscal localization package and save (this causes the exception) **Cause of the issue:** Certain tax accounts in the module do not have their names fully updated. They all were labeled as "0% ..." instead of their true percentages like all other tax accounts. **Fix:** Update the names of the offending tax accounts so that they are fully reflective of their true %. Associated with https://github.com/odoo/odoo/pull/151515 opw-3683538 Forward-Port-Of: odoo/enterprise#56496
On a view, drag and drop a new related field. Go into one m2o field. Before this commit, it was possible to select a field of type "properties". This is not supported by python at the time. To do so, one would have to reflect the property "definition" of the python field. Also, some code would have to be written to create that other field, related as well that'd contain the properties' definition. After this commit, to make things simpler, we just blacklist property fields in the related
Original PR description
On a view, drag and drop a new related field. Go into one m2o field. Before this commit, it was possible to select a field of type "properties". This is not supported by python at the time. To do so, one would have to reflect the property "definition" of the python field. Also, some code would have to be written to create that other field, related as well that'd contain the properties' definition. After this commit, to make things simpler, we just blacklist property fields in the related field selector. opw-3730900 Forward-Port-Of: odoo/enterprise#56749 Forward-Port-Of: odoo/enterprise#56597
### Before: Before this fix, entering a search term in the bar caused pagination to malfunction. The issue stemmed from the offset not resetting to 0 upon entering a search term, leading to incorrect behavior. Additionally, the total count failed to update with search inputs. ### After: This PR resolves the issue by resetting the offset to 0 upon search term entry and updating the total count using the domain passed to the _fetchPagerTotal method. Task ID: [3631981](https://www.odoo
Original PR description
### Before: Before this fix, entering a search term in the bar caused pagination to malfunction. The issue stemmed from the offset not resetting to 0 upon entering a search term, leading to incorrect behavior. Additionally, the total count failed to update with search inputs. ### After: This PR resolves the issue by resetting the offset to 0 upon search term entry and updating the total count using the domain passed to the _fetchPagerTotal method. Task ID: [3631981](https://www.odoo.com/web#id=3631981&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56669 Forward-Port-Of: odoo/enterprise#53122
We got a feedback from a Belgian partner that we don't have a xml declaration in the xml report. opw-3745820 Forward-Port-Of: odoo/enterprise#56764 Forward-Port-Of: odoo/enterprise#56727
Original PR description
We got a feedback from a Belgian partner that we don't have a xml declaration in the xml report. opw-3745820 Forward-Port-Of: odoo/enterprise#56764 Forward-Port-Of: odoo/enterprise#56727
- According the SRI, the payment method is available in customer and vendor documents (invoices, debit notes and purchase liquidation), we leave it visible in view and pdf report for the documents excluding credit notes Forward-Port-Of: odoo/enterprise#56447 Forward-Port-Of: odoo/enterprise#52855
Original PR description
- According the SRI, the payment method is available in customer and vendor documents (invoices, debit notes and purchase liquidation), we leave it visible in view and pdf report for the documents excluding credit notes Forward-Port-Of: odoo/enterprise#56447 Forward-Port-Of: odoo/enterprise#52855
Steps to reproduce ================== - Go to Sales > Quotation - Open studio - Click on Reports - Open the "Quotation / Order" report - Inside the Sale order lines, type /field - Click on "Product >" - Type "128" => The "Image 128" field is missing, only the "Variant Image 128" is displayed Cause of the issue ================== Only searchable fields were displayed opw-3713666 Forward-Port-Of: odoo/enterprise#56364 Forward-Port-Of: odoo/enterprise#55839
Original PR description
Steps to reproduce ================== - Go to Sales > Quotation - Open studio - Click on Reports - Open the "Quotation / Order" report - Inside the Sale order lines, type /field - Click on "Product >" - Type "128" => The "Image 128" field is missing, only the "Variant Image 128" is displayed Cause of the issue ================== Only searchable fields were displayed opw-3713666 Forward-Port-Of: odoo/enterprise#56364 Forward-Port-Of: odoo/enterprise#55839
Fix translation for account_asset / wizard There was fixed strings without translation - gain - loss - gain/loss Forward-Port-Of: odoo/enterprise#56481
Original PR description
Fix translation for account_asset / wizard There was fixed strings without translation - gain - loss - gain/loss Forward-Port-Of: odoo/enterprise#56481
For email address to be considered in the UPS request, the `M` needs to be capitalized. UPS documentation for reference: UPS documentation for reference: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment!path=ShipmentRequest/Shipment/ShipTo/EMailAddress&t=request opw-3487959 Forward-Port-Of: odoo/enterprise#56475
Original PR description
For email address to be considered in the UPS request, the `M` needs to be capitalized. UPS documentation for reference: UPS documentation for reference: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment!path=ShipmentRequest/Shipment/ShipTo/EMailAddress&t=request opw-3487959 Forward-Port-Of: odoo/enterprise#56475
Steps to reproduce: 1. install `l10n_pos_res_cert` and set up Fiskaly 2. set up a PoS restaurant 3. set the language to German 4. open a PoS session and make an order error: ``` error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$' ``` The issue is similar to that fixed in https://github.com/odoo/enterprise/pull/46682 It comes from the fact that formatCurrency method is used to convert the amounts to string. However it adds language
Original PR description
Steps to reproduce:
1. install `l10n_pos_res_cert` and set up Fiskaly
2. set up a PoS restaurant
3. set the language to German
4. open a PoS session and make an order
error:
```
error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$'
```
The issue is similar to that fixed in https://github.com/odoo/enterprise/pull/46682
It comes from the fact that formatCurrency method is used to convert the amounts to string. However it adds language specific formatting. In this case Fiskaly expects `12.50` but `12,50` is sent.
opw-3724456
Forward-Port-Of: odoo/enterprise#56619
Forward-Port-Of: odoo/enterprise#56498…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437
Original PR description
…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to…
…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437adc2b5db2 removed the dependence of sale_temporal for sale_subcription. After that, there was no point in keeping the sale_temporal dependence in sale_renting. Thus, the dependence for sale_temporal has also been removed here: https://github.com/odoo/enterprise/commit/6c86a278dbc752009c0985702cb2927c26f5f636. The module sale_temporal was responsible for checking incompatible products types. Currently, both sale_renting and sale_subscription have the module sale in common. This commit is part of a 2-part fix and targets Odoo Enterprise. It re-introduces the constraints on 'rent_ok' and 'reccuring_invoice'. Code re-introduced: * https://github.com/odoo/enterprise/blob/da031dd50501af0b6c02fab804a9af33363d397c/sale_subscription/models/product.py#L12-L19 * https://github.com/odoo/enterprise/blob/da031dd50501af0b6c02fab804a9af33363d397c/sale_renting/models/product_template.py#L19-L26 PR in Community: https://github.com/odoo/odoo/pull/150688 opw-3678715 Forward-Port-Of: odoo/enterprise#54940
Task: 3584650 Forward-Port-Of: odoo/enterprise#52871
Original PR description
Task: 3584650 Forward-Port-Of: odoo/enterprise#52871
When a subscription code is already linked to a database and you try to use it on another database, the message displaying that this subscription code is already used and provides the informations of what to do is not correctly displayed. Forward-Port-Of: odoo/enterprise#56618 Forward-Port-Of: odoo/enterprise#47326
Original PR description
When a subscription code is already linked to a database and you try to use it on another database, the message displaying that this subscription code is already used and provides the informations of what to do is not correctly displayed. Forward-Port-Of: odoo/enterprise#56618 Forward-Port-Of: odoo/enterprise#47326
How to reproduce: 1. Select a file/doc. 2. click on the split tool button 3. opens the PDF split view 4. press control+k (shows command palette) Before this commit: List all the commands, but those which are related to 'DocumentsKanbanRenderer' are not working. Technical Reason: PDF splitter is a dialog, the context of the Kanban Renderer stays in the background, 'Select all' and other command logic related to the 'DocumentsKanbanRenderer', do not work in PdfManager because of not ha
Original PR description
How to reproduce: 1. Select a file/doc. 2. click on the split tool button 3. opens the PDF split view 4. press control+k (shows command palette) Before this commit: List all the commands, but those which are related to 'DocumentsKanbanRenderer' are not working. Technical Reason: PDF splitter is a dialog, the context of the Kanban Renderer stays in the background, 'Select all' and other command logic related to the 'DocumentsKanbanRenderer', do not work in PdfManager because of not having the state of it. After this commit: Showing commands related to the PdfManager only. Task-3623653 Forward-Port-Of: odoo/enterprise#53438
During a forward port (https://github.com/odoo/enterprise/commit/bb67df2f37a65acd9f62a28d8a52fbd335ef903e), we introduced a bug because the old warning system was in conflict with the new one. The aim of this commit is removing the old one (that are not working) for the new one. In the same time, we make sure that we use the right key when getting ids that have an issue. opw-3741287 opw-3741721 opw-3741658 Forward-Port-Of: odoo/enterprise#56683
Original PR description
During a forward port (https://github.com/odoo/enterprise/commit/bb67df2f37a65acd9f62a28d8a52fbd335ef903e), we introduced a bug because the old warning system was in conflict with the new one. The aim of this commit is removing the old one (that are not working) for the new one. In the same time, we make sure that we use the right key when getting ids that have an issue. opw-3741287 opw-3741721 opw-3741658 Forward-Port-Of: odoo/enterprise#56683