Friday, January 5, 2024
27 changes · 17.0
Enhancements to existing features
This draft change updates a browser rendering library used by the web editor. It is likely intended to improve how page content is captured or displayed, with limited direct business impact based on the available details.
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
Resolved issues and error corrections
This fixes how the website editor identifies XML content when editing page head or body code. It helps ensure the editor applies the right behavior and formatting, reducing confusion for users making website code changes.
Documentation and clarification updates
This pull request records Sunarc Technologies' Corporate Contributor License Agreement for Odoo. It is an administrative legal update that enables accepted contributions from the company under Odoo's contribution rules.
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
Miscellaneous changes
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public user and make the payment 4- Check the state of this order in backend Current behavior before PR: Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'L
Original PR description
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public…
[FIX] sale: always lock confirmed order when auto-lock activated Steps to reproduce: 1- Install Sales module 2- Activate Lock Confirmed Sales from Sales settings 3- Create a new order as a Public user and make the payment 4- Check the state of this order in backend Current behavior before PR: Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'Lock Confirmed Sales' group is on or not we check if it is there for the current user which if he is a public user by default will not have this group. Desired behavior after PR is merged: Before we had this condition checking if self.env.user has the 'Lock Confirmed Sales' but this won't work if the SO is coming from eCommerce with public user env So now we are checking the creator of the SO that in the eCommerce scenario will be OdooBot and if the SO is created from the backend it will be one of the users who already has the group. opw-3595964 Forward-Port-Of: odoo/odoo#148162 Forward-Port-Of: odoo/odoo#146188
The Belgian localization demo setup now uses the proper expense account for negative cash differences in cash journals. This prevents losses from being classified as income, improving accounting accuracy for Belgian demo configurations.
Original PR description
This fix is to solve a bug that appears in the demo data of the l10n_be specifically in the cash journal using an income type account for the negative cash difference which should be an expense type. current behavior: using income type in a loss account. desired behavior: expense account instead. opw-3642586
Header buttons that are meant to always display will now still respect rules that hide them when appropriate. This prevents users from seeing actions in list and kanban views when those actions should be hidden based on the page setup.
Original PR description
Since the commit odoo/odoo@0d99f4b9d9de404fea44ecf5480ec3b07c2b0fd6 , the header buttons with display="always" can't be invisible. The invisible attribute is ignored for this type of button in list view and kanban view. This commit fixes this issue by adding t-if that will evaluate the invisible attribute. 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
The keyboard shortcut for completing an activity and scheduling the next one has been changed so it no longer conflicts with the Save/Schedule action. This helps users avoid triggering the wrong action when using keyboard shortcuts in the activity dialog.
Original PR description
This commit simply replaces the shortcut for the action_done_schedule_next buttons from alt+q to alt+z in the activity view dialog because the alt+q shortcut is already used for the Save/Schedule buttons. This was already done in https://github.com/odoo/odoo/pull/145738 but the wizard which appeared in 17.0 hadn't been corrected. opw-3565747
This update corrects a test case in the payroll module that was failing due to year-related validation issues. The fix ensures that salary attachment tests run correctly and reliably, improving the stability of payroll testing processes.
Original PR description
Forward-Port-Of: odoo/enterprise#53623 Forward-Port-Of: odoo/enterprise#53554
This fix resolves an issue where translated text in the bank reconciliation interface was causing unwanted line breaks in partner-related buttons (such as "Client:" and "Payable:" labels). The problem occurred when translations introduced extra whitespace, making buttons appear broken or misaligned. This fix ensures buttons display properly regardless of language, improving the user experience in the bank reconciliation process.
Original PR description
Translations may introduce whitespace into the text of some buttons. The text of the buttons may then contain a linebreak. This i.e. concerns the buttons in the "Manual Operations" tab that are visible when a non-liquidity line is selected and has a partner set: "Client:", "Payable:" below the partner. Reproduce 1. Select French language 2. Go to the bank reconciliation widget and select an unmatched statement line. 3. On the right side: Select any line that is not the liquidity line 4. Ensure that the "Manual Operations" tab is selected 5. Ensure that a partner is set and the 2 buttons below the partner are visible. 6. The 2 buttons contain linebreaks. Forward-Port-Of: odoo/enterprise#53574 Forward-Port-Of: odoo/enterprise#52027
Issue Description: ================== The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically: 1. The `qty_production` field in `mrp_workorder.py` is a related field https://github.com/odoo/odoo/blob/2e5da1130f4
Original PR description
Issue Description: ================== The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce…
Issue Description: ================== The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically: 1. The `qty_production` field in `mrp_workorder.py` is a related field https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L44 2. When marking the MO as done, we write on this related field https://github.com/odoo/odoo/blob/780dded71cc725d75a0739e6c7bf4ceab5850581/addons/mrp/models/mrp_production.py#L1886 3. This action triggers a call to the compute method https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L324 leading to the unexpected change in the expected duration value. Steps to Reproduce: =================== 1. Create a Manufacturing Order (MO) with a product that has a BOM. 2. In the Work Order tab of the MO, input a custom expected duration different from the BOM's default duration. 3. Сomplete all product validation steps. 3. Click 'Produce All' on the MO. 4. Observe the reset of the expected duration to the default BOM value in the Work Order tab. Proposed Solution: ================== Implement a change to prevent the re-calculation of `duration_expected` in the Work Order tab once the work order's state is set to 'done' or 'cancel', ensuring that any custom duration set prior to executing 'Produce All' is maintained. opw-3608185 Forward-Port-Of: odoo/odoo#146843
After #38518, there are cases in which people uninstall l10n_it_edi so the following traceback is given when importing a PDF invoice (OCR): ```py File "/home/odoo/src/enterprise/saas-16.4/l10n_it_reports/models/account_move.py", line 9, in <lambda> lambda rec: self.env['account.edi.format']._check_filename_is_fattura_pa(rec.name) AttributeError: 'account.edi.format' object has no attribute '_check_filename_is_fattura_pa' ``` We move everything back to l10n_it_edi, ~~but the test wi
Original PR description
After #38518, there are cases in which people uninstall l10n_it_edi so the following traceback is given when importing a PDF invoice (OCR):
```py
File "/home/odoo/src/enterprise/saas-16.4/l10n_it_reports/models/account_move.py", line 9, in <lambda>
lambda rec: self.env['account.edi.format']._check_filename_is_fattura_pa(rec.name)
AttributeError: 'account.edi.format' object has no attribute '_check_filename_is_fattura_pa'
```
We move everything back to l10n_it_edi, ~~but the test will be excised.~~ (actually, we can keep the test since we can assume l10n_it_reports will be installed on runbot)
Enterprise PR: odoo/enterprise#53333
Forward-Port-Of: odoo/odoo#147370Version: -------- - 16.0+ Steps to reproduce: ------------------- 1. Go to Timesheets / Configuration / Settings; 2. set encoding method to Days / Half-Days; 3. go to sales and create a sales order; 4. sell a service that will create project on sale; 5. confirm and go to the generated project's settings. Issue: ------ The Allocated Days displayed is one-eighth of what's expected. Cause: ------ On project creation, it was using `timesheet_encode_uom_id` to calculate `allocate
Original PR description
Version: -------- - 16.0+ Steps to reproduce: ------------------- 1. Go to Timesheets / Configuration / Settings; 2. set encoding method to Days / Half-Days; 3. go to sales and create a sales order; 4. sell a service that will create project on sale; 5. confirm and go to the generated project's settings. Issue: ------ The Allocated Days displayed is one-eighth of what's expected. Cause: ------ On project creation, it was using `timesheet_encode_uom_id` to calculate `allocated_hours`. Hence, if timesheets are being encoded in days, it also tries to encode the project's `allocated_hours` as days, dividing the quantity by eight. Solution: --------- It should use `project_time_mode_id` as UoM instead, which is hardcoded to hours. opw-3614995 Forward-Port-Of: odoo/odoo#148183 Forward-Port-Of: odoo/odoo#147009
There were a few errors
Original PR description
There were a few errors
Issue: ====== The auto signature has hidden overflow part in y axis when having long characters in bottom like (y, j, g) Steps to reproduce the issue: ============================= - Use any sign template that have at least one name_and_signature sign item. - Enter a name that have at least one of the characters (y,j,g) - Click on auto - The signature doesn't show fully Solution: ========= Update the hardcoded values for the y-axis for the name and the line of signature and the fo
Original PR description
Issue: ====== The auto signature has hidden overflow part in y axis when having long characters in bottom like (y, j, g) Steps to reproduce the issue: ============================= - Use any sign template that have at least one name_and_signature sign item. - Enter a name that have at least one of the characters (y,j,g) - Click on auto - The signature doesn't show fully Solution: ========= Update the hardcoded values for the y-axis for the name and the line of signature and the font size to make sure it fits perfectly inside the canvas. Before: =====  After: ====  opw-3639171 Forward-Port-Of: odoo/odoo#146789
Before this commit, the link preview in the Link Dialog would not be updated after changes on the label input field, depending on other actions to be updated (e.g. picking a different type of link/button or changing the URL input field). This commit makes sure the link preview reacts to changes on the label input field. task-3580621 Forward-Port-Of: odoo/odoo#148084 Forward-Port-Of: odoo/odoo#140763
Original PR description
Before this commit, the link preview in the Link Dialog would not be updated after changes on the label input field, depending on other actions to be updated (e.g. picking a different type of link/button or changing the URL input field). This commit makes sure the link preview reacts to changes on the label input field. task-3580621 Forward-Port-Of: odoo/odoo#148084 Forward-Port-Of: odoo/odoo#140763
When the user uploads an image and remove the original image, some image options continue to work thanks to a backend fallback on another image. Unfortunately, this fallback is not available for images coming from unsplash. This commit fixes this issue by preventing the UI to be blocked when the original image is not found. Steps to reproduce the bug: - Activate the developer mode - Configure Unsplash in the settings - Add a Cover block on a page - Replace the background image with an
Original PR description
When the user uploads an image and remove the original image, some image options continue to work thanks to a backend fallback on another image. Unfortunately, this fallback is not available for images coming from unsplash. This commit fixes this issue by preventing the UI to be blocked when the original image is not found. Steps to reproduce the bug: - Activate the developer mode - Configure Unsplash in the settings - Add a Cover block on a page - Replace the background image with an unsplash image - Save - Edit the page and via the media dialog, remove the original image => The options on the image cannot start anymore. opw-3636499 opw-3474103 Forward-Port-Of: odoo/odoo#148118 Forward-Port-Of: odoo/odoo#146866
Before this commit, the pager hook use useChildSubEnv to patch the config with the pagerProps. We used useChlidSubEnv because this information only targets one of its children (the ControlPanel), not the components using the hook themselves (e.g. the controllers). However, this has an infortunate side-effect. If a component using the pager hook also wants to patch the env (e.g. with useSubEnv), and does it after calling usePager, it will erase the sub env created by the pager hook for the chi
Original PR description
Before this commit, the pager hook use useChildSubEnv to patch the config with the pagerProps. We used useChlidSubEnv because this information only targets one of its children (the ControlPanel), not…
Before this commit, the pager hook use useChildSubEnv to patch the config with the pagerProps. We used useChlidSubEnv because this information only targets one of its children (the ControlPanel), not the components using the hook themselves (e.g. the controllers).
However, this has an infortunate side-effect. If a component using the pager hook also wants to patch the env (e.g. with useSubEnv), and does it after calling usePager, it will erase the sub env created by the pager hook for the children by its own.
This happens with the TimesheetTimerListView:
```js
setup() {
super.setup(); // super will call usePager
useSubEnv({
config: {
// this config doesn't contain the pagerProps
// generated by usePager, as it's the config of
// the component itself
...this.env.config,
disableSearchBarAutofocus: true,
},
});
}
```
Since using useChildSubEnv in this case isn't necessary, we simply replace it by useSubEnv.
Note that we don't add a framework test for this issue, as it would be totally artificial. Instead, the enterprise PR adds a test for the TimesheetTimerListView.
opw 3636182
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#147250When we copy a sales order we were taking margins from the past which have a high probability of not being valid anymore. Now, once we copy a sales order, no past value is copied and the purchase price is computed as new so we get the current margin values. cc @Tecnativa TT46721 check @pedrobaeza @sergio-teruel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148156 Forward-Port-Of: odoo/odoo#147137
Original PR description
When we copy a sales order we were taking margins from the past which have a high probability of not being valid anymore. Now, once we copy a sales order, no past value is copied and the purchase price is computed as new so we get the current margin values. cc @Tecnativa TT46721 check @pedrobaeza @sergio-teruel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148156 Forward-Port-Of: odoo/odoo#147137
Steps to reproduce: 1) Install and enable the "Onsite" payment provider; 2) As a public user, add product(s) to your cart; 3) Try to pay with the "Onsite" provider. -> Internal Server Error Cause of the issue: In the log, the cause of the issue is an AccessError, specifying that we tried to read the field `transaction_ids` on a `sale.order` without having the necessary access rights. This shouldn't happen, since the payment & ecommerce flows are executed in sudo mode, after m
Original PR description
Steps to reproduce: 1) Install and enable the "Onsite" payment provider; 2) As a public user, add product(s) to your cart; 3) Try to pay with the "Onsite" provider. -> Internal Server Error Cause of…
Steps to reproduce: 1) Install and enable the "Onsite" payment provider; 2) As a public user, add product(s) to your cart; 3) Try to pay with the "Onsite" provider. -> Internal Server Error Cause of the issue: In the log, the cause of the issue is an AccessError, specifying that we tried to read the field `transaction_ids` on a `sale.order` without having the necessary access rights. This shouldn't happen, since the payment & ecommerce flows are executed in sudo mode, after making sure that the cart belongs to the customer. After investigation, pending payment transactions trigger 1) the sending of a mail to the customer 2) the first mail generation will request the report assets 3) the generation of the report assets will create an attachment and commit the transaction 4) committing the transaction will trigger a global flush of the environment, forcing the computation of pending mail wizard fields, with a different environment than the sudoed one initiating the sending of the mail. This will lead to security errors as we try to access `sale.order` fields content without having the rights for it. Standard fields being already in the cache, it will be noticed when trying to read the `transaction_ids` field. Solution: Manually prefetch the `transaction_ids` content with the sudoed environment, since the records cache is shared between the environments (until a more global fix is found and deployed). Introduced by https://github.com/odoo/odoo/pull/121376 opw-3628753 Forward-Port-Of: odoo/odoo#147148
Description of the issue/feature this PR addresses: - When using safe_eval on this dict, "true" raises a NameError while "True" is interpreted properly. At the same time, this is more consistent with the rest of the code. - Affects 16.0+ - This doesn't cause an error when entering the view in Odoo as the interpreter for that is indifferent to `true` or `True` but it causes issues when a `safe_eval` is run on it Replicatable in an Odoo Shell ![Captura desde 2024-01-03 18-06-34](https://
Original PR description
Description of the issue/feature this PR addresses:
- When using safe_eval on this dict, "true" raises a NameError while "True" is interpreted properly.
At the same time, this is more consistent with the rest of the code.
- Affects 16.0+
- This doesn't cause an error when entering the view in Odoo as the interpreter for that is indifferent to `true` or `True` but it causes issues when a `safe_eval` is run on it
Replicatable in an Odoo Shell
Current behavior before PR:
```
ValueError: <class 'NameError'>: "name 'true' is not defined" while evaluating
"{'no_open': true, 'color_field': 'color'}"
```
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#148106
Forward-Port-Of: odoo/odoo#147988Before this PR: When inserting a star rating element, pressing 'Enter' would move the cursor to the next line, and hitting 'Backspace' would delete the star rating element. After this PR: After inserting a star rating element and moving to the next line with 'Enter,' pressing 'Backspace' now causes the cursor to move to the previous 'p' tag where star element is located. If 'Backspace' is pressed again, the star element is deleted. task-3555394 Forward-Port-Of: odoo/odoo#144412
Original PR description
Before this PR: When inserting a star rating element, pressing 'Enter' would move the cursor to the next line, and hitting 'Backspace' would delete the star rating element. After this PR: After inserting a star rating element and moving to the next line with 'Enter,' pressing 'Backspace' now causes the cursor to move to the previous 'p' tag where star element is located. If 'Backspace' is pressed again, the star element is deleted. task-3555394 Forward-Port-Of: odoo/odoo#144412 Forward-Port-Of: odoo/odoo#141379
Description of the issue/feature this PR addresses: When replenishing a product with a route buy selected on the product form but no vendor added, we fall into an endless loop because the default_get sets the route, which triggers the onchange that return a warning. This will again call the default_get and the loop never ends. The onchange is useless as it's only goal is to display the warning, and as the field is required on the form, the user will not be able to submit it. opw-36537
Original PR description
Description of the issue/feature this PR addresses: When replenishing a product with a route buy selected on the product form but no vendor added, we fall into an endless loop because the default_get sets the route, which triggers the onchange that return a warning. This will again call the default_get and the loop never ends. The onchange is useless as it's only goal is to display the warning, and as the field is required on the form, the user will not be able to submit it. opw-3653714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148044
Purpose ======= When we open an email that has been encapsulated in the notification email, we still search the partner based on that email (which make no sens). Instead, in that case, we show an error saying that it's the notification email. Task-3557545 Forward-Port-Of: odoo/odoo#147945 Forward-Port-Of: odoo/odoo#139002
Original PR description
Purpose ======= When we open an email that has been encapsulated in the notification email, we still search the partner based on that email (which make no sens). Instead, in that case, we show an error saying that it's the notification email. Task-3557545 Forward-Port-Of: odoo/odoo#147945 Forward-Port-Of: odoo/odoo#139002
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147832
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147832
Incorporate German Loredo (xmglord) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148009
Original PR description
Incorporate German Loredo (xmglord) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148009
Create a branch under the main company Select an internal user and keep only this branch on the fields "Allowed companies" and "Default Company" Access with the user Create an invoice Add a product Issue: user will be blocked by error """ Access Error Due to security restrictions, you are not allowed to access 'Companies' (res.company) records. Records: YourCompany (id=1) User: Marc Demo (id=6) This restriction is due to the following rules: - company rule employee Note:
Original PR description
Create a branch under the main company Select an internal user and keep only this branch on the fields "Allowed companies" and "Default Company" Access with the user Create an invoice Add a product Issue: user will be blocked by error """ Access Error Due to security restrictions, you are not allowed to access 'Companies' (res.company) records. Records: YourCompany (id=1) User: Marc Demo (id=6) This restriction is due to the following rules: - company rule employee Note: this might be a multi-company issue. Contact your administrator to request access if necessary. """ This occurs because the accounting info is taken from the parent company, but the branch user has no access to the parent company records opw-3627439 Forward-Port-Of: odoo/odoo#147270
This update exports translation files for version 17.0 across multiple Odoo modules. The translation files are prepared for localization teams to translate the software into different languages, ensuring the platform can serve users worldwide in their native languages.