Monday, August 19, 2024
19 changes · saas-17.2
Miscellaneous changes
A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly. This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked cap
Original PR description
A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly. This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked capacity and existing bookings. Indeed, the asked_capacity will not be counted when computing the total reserved percentage. In practice, this means that events crossing the treshold will be automatically 'accepted' instead of 'needsAction' The fix creates another variable to avoid the issue and adds a test. Task-4084727 Forward-Port-Of: odoo/enterprise#67626
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check:
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1
- Create a quality point:
- Product: P1
- Operation: Manufacturing
- Control per: Quantity
- Control Frequency: All
- Create a manufacturing order:
- Product: P1
- Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check:
- Button Fail
- Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check:
- Button Fail
- Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/enterprise#68512
Forward-Port-Of: odoo/enterprise#67474**Description** A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases. The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence,
Original PR description
**Description** A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new…
**Description**
A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases.
The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence, id`, where `sequence` column (if unchanged) remains null, causing lines to be sorted by `id`. The change caused larger id records to be assigned as the parent of smaller id records, violating the required hierarchy and raising a traceback.
**Traceback :**
```py
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 4386, in get_report_information
'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 2123, in _get_lines
parent_generic_id = line_cache[line.parent_id]['id'] if line.parent_id else None # The parent line has necessarily been treated in a previous iteration
KeyError: account.report.line(338,)
```
**steps to reproduce**
1. install 'l10n_fr' and 'account_accountant' in a demo database of version 16
2. migrate it to version 17.
3. go to Reporting->Profit and Loss (Fr company should be selected)
4. Change Report to "IMB - Intermediate management balances"
Note: This PR is created by this [suggestion](https://github.com/odoo/upgrade/pull/6267#issuecomment-2244373973).
Forward-Port-Of: odoo/enterprise#68182
Forward-Port-Of: odoo/enterprise#67147This commit aims to add a minimum box size for sign items. regardless of how the user resizes them, they should maintain this minimum size. Task: 4014579 Forward-Port-Of: odoo/enterprise#67242
Original PR description
This commit aims to add a minimum box size for sign items. regardless of how the user resizes them, they should maintain this minimum size. Task: 4014579 Forward-Port-Of: odoo/enterprise#67242
Have a 0% Tax Open bank reconciliation widget Reconcile a bank statement with a manual operation including the 0% tax Issue: On the reconciliation widget a void line will be shown After validation the 0 balance tax line will be created opw-4043498 Forward-Port-Of: odoo/enterprise#68383 Forward-Port-Of: odoo/enterprise#67458
Original PR description
Have a 0% Tax Open bank reconciliation widget Reconcile a bank statement with a manual operation including the 0% tax Issue: On the reconciliation widget a void line will be shown After validation the 0 balance tax line will be created opw-4043498 Forward-Port-Of: odoo/enterprise#68383 Forward-Port-Of: odoo/enterprise#67458
Ensure that, when importing amounts involving currency exchanges, the system reads the amount that includes the fees. (New behavior confirmed with CHKL) opw-3999490 Forward-Port-Of: odoo/enterprise#68385 Forward-Port-Of: odoo/enterprise#67879
Original PR description
Ensure that, when importing amounts involving currency exchanges, the system reads the amount that includes the fees. (New behavior confirmed with CHKL) opw-3999490 Forward-Port-Of: odoo/enterprise#68385 Forward-Port-Of: odoo/enterprise#67879
A FROM email is required in order to send an email. For this email, the source email can either come from the new user's company, or from the sending user's company. In both cases it's almost certainly going to be *the* company. The company's email comes from its partner object, which only gets one when loading the demo (via a `<function>` call in the users demo, making finding it a bit of a chore). This means without demo the totp mail send fails with somewhat unhelpful error messages (as it
Original PR description
A FROM email is required in order to send an email. For this email, the source email can either come from the new user's company, or from the sending user's company. In both cases it's almost certainly going to be *the* company. The company's email comes from its partner object, which only gets one when loading the demo (via a `<function>` call in the users demo, making finding it a bit of a chore). This means without demo the totp mail send fails with somewhat unhelpful error messages (as it's on the server side of a controller call and deep into the bowels of email rendering). The fix is to just set an email on the main company before going through the signup flow, that way there is an email_from to use and everything works out. Runbot error 70541 Forward-Port-Of: odoo/odoo#176906
More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
Original PR description
More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
Changing a BoM from 'phantom' (kit) to 'normal' (manufacture) during leads to an error if the kit is in the middle of a sale process. ## How to reproduce: 2. Create a product category PC: AVCO Automated 3. Create 3 storable products P_kit, P_01, P_02 in category PC 4. Create a BoM: - Product: P_kit - Type: kit - Components: - 1 x P_01 - 1 x P_02 5. Create and confirm a SO with 1 x P_kit 6. Force the delivery 7. Change BoM type to 'Manufacture this product' 8. Cr
Original PR description
Changing a BoM from 'phantom' (kit) to 'normal' (manufacture) during leads to an error if the kit is in the middle of a sale process.
## How to reproduce:
2. Create a product category PC: AVCO Automated
3. Create 3 storable products P_kit, P_01, P_02 in category PC
4. Create a BoM:
- Product: P_kit
- Type: kit
- Components:
- 1 x P_01
- 1 x P_02
5. Create and confirm a SO with 1 x P_kit
6. Force the delivery
7. Change BoM type to 'Manufacture this product'
8. Create and confirm the SO's invoice
Error: a traceback appears "ValueError: Expected singleton: uom.uom..."
Related PR: https://github.com/odoo/odoo/pull/119944
OPW-3843356
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171802Issue: ====== Image changes aren't auto saved. Steps to reproduce the issue: ============================= - Add cover snippet and text-image snipets - Change cover image or the image in the text-image snippet - Don't click anywhere after that - Switch tab to A/B testing for example - Go back to mail body - The image changes aren't saved Origin of the issue and solution: ================================= When we choose an image from the media dialog, we loose the focus from t
Original PR description
Issue: ====== Image changes aren't auto saved. Steps to reproduce the issue: ============================= - Add cover snippet and text-image snipets - Change cover image or the image in the…
Issue: ====== Image changes aren't auto saved. Steps to reproduce the issue: ============================= - Add cover snippet and text-image snipets - Change cover image or the image in the text-image snippet - Don't click anywhere after that - Switch tab to A/B testing for example - Go back to mail body - The image changes aren't saved Origin of the issue and solution: ================================= When we choose an image from the media dialog, we loose the focus from the editable which means `onWysiwygBlur` is not called and as consequence `commitChanges` isn't called too. Since the flow of the destroy and the `commitChanges` in `onWysiwygBlur` are in parallel, the following happens: - We don't update the value in the blur flow because we will wait for some promises which may take some time and the component gets destroyed and we never call the `updateValue` at the end of the function. - Now in the `commitChanges` coming from `onWillUnmount` we need to pass the `urgent` flag in mass_mailing too. opw-3947516 Forward-Port-Of: odoo/odoo#174740 Forward-Port-Of: odoo/odoo#172312
After the commit https://github.com/odoo/odoo/commit/6636135d5f2858e4a2bf27e5c2da91a91fa52695, an unnecessary error was triggered when a bill of materials (BOM) containing an item with zero quantity was used. This commit updates the logic to prevent this check when the item's quantity is zero and its unit of measure (UoM) matches the product's UoM, avoiding the error. opw-4113385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odo
Original PR description
After the commit https://github.com/odoo/odoo/commit/6636135d5f2858e4a2bf27e5c2da91a91fa52695, an unnecessary error was triggered when a bill of materials (BOM) containing an item with zero quantity was used. This commit updates the logic to prevent this check when the item's quantity is zero and its unit of measure (UoM) matches the product's UoM, avoiding the error. opw-4113385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176566
**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty Google
Original PR description
**Version:** - 17.0 **Step to reproduce:** - open the Calendar and navigate to Configuration > Settings - add Google credentials and sync it - create an event and then pause the sync. - again create an event and unpause the sync with Google Calendar - event fails to update on Google Calendar **Issue:** Currently, when an event is created during the sync_pause period, the `_google_insert` function will not be called. After unpausing the sync, the event will return an empty GoogleEvent ID. **Solution:** This PR enables the synchronization to restart automatically when unpausing the Google Calendar. task-3731607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156037
Currently, when making downpayment the name on the product concerned by the downpayment are not reflected on the receipt. Steps to reproduce: ------------------- * Go to the **Sale** App * Make a quotation with multiple products -> Save * Go to the **Point of Sale** App * Make a downpayment for the quotation just created * Pay and validate > Observation: We see multiple '1x ' lines on the receipt, under the downpayment line but the product names are not shown Why the fix: --------
Original PR description
Currently, when making downpayment the name on the product concerned by the downpayment are not reflected on the receipt. Steps to reproduce: ------------------- * Go to the **Sale** App * Make a…
Currently, when making downpayment the name on the product concerned by the downpayment are not reflected on the receipt. Steps to reproduce: ------------------- * Go to the **Sale** App * Make a quotation with multiple products -> Save * Go to the **Point of Sale** App * Make a downpayment for the quotation just created * Pay and validate > Observation: We see multiple '1x ' lines on the receipt, under the downpayment line but the product names are not shown Why the fix: ------------ https://github.com/odoo/odoo/blob/9e934b83ed200317947ee7575deb443e721290e8/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L384 `line.product_id` is now only a number thus `line.product_id[1]` is undefined. We could use `line.display_name` as it is already currently loaded but there is too much information on the display name. It has the following format: `Sale Order nbr - Name of the product - Customer of the SO` opw-4043149 Forward-Port-Of: odoo/odoo#175669
### **Description:** * **Steps to Reproduce:-** 1. Install the Inventory module and create a new warehouse, other than the standard one. 2. Archive the standard warehouse. 3. Attempt to install the Point_of_Sale module. * After this commit: https://github.com/odoo/odoo/commit/0ddd04a34d85386d4ffc59aab07f68b365619b0a, archived warehouses are now also considered when defaulting the `pos_type_id`. Initially, if a warehouse was archived, no `pos_type_id` would be creat
Original PR description
### **Description:** * **Steps to Reproduce:-** 1. Install the Inventory module and create a new warehouse, other than the standard one. 2. Archive the standard warehouse. 3. Attempt to install the…
### **Description:**
* **Steps to Reproduce:-**
1. Install the Inventory module and create a new warehouse, other than the standard one.
2. Archive the standard warehouse.
3. Attempt to install the Point_of_Sale module.
* After this commit: https://github.com/odoo/odoo/commit/0ddd04a34d85386d4ffc59aab07f68b365619b0a, archived warehouses are now also considered when defaulting the `pos_type_id`. Initially, if a warehouse was archived, no `pos_type_id` would be created for it. Later on, if any new `pos_config` record is created for `self.env.company` where the warehouse is archived, it will throw the following error:
```py
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
DETAIL: Failing row contains (1, null, null, 1, null, 221, 222, null, 1, 170, 169, 289, null, null, 7, null, 1, 1, Shop, total, null, 17c45bf9-4ffa-45ce-b637-53249b394421, direct, null, null, null, null, null, null, null, null, null, null, f, t, null, f, null, t, null, null, null, f, null, null, null, null, null, null, null, null, null, null, t, null, t, 2024-08-06 04:46:54.504337, 2024-08-06 04:46:54.504337, null).
```
While parsing this...
```py
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 569, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/17.0/addons/point_of_sale/data/point_of_sale_data.xml:35, somewhere inside
<record model="pos.config" id="pos_config_main" forcecreate="0">
<field name="name">Shop</field>
</record>
```
OPW - 4094096
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#175838**Description of the issue/feature this PR addresses:** steps to reproduce error:- 1.create db with 'point_of_sale' module 2.duplicate the record of pos_payement_method with journal type cash 3. install 'pos_restaurant' module this traceback will raise the **OR** start pos session validation error will come ``` Traceback (most recent call last): File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db return service_model.retryin
Original PR description
**Description of the issue/feature this PR addresses:** steps to reproduce error:- 1.create db with 'point_of_sale' module 2.duplicate the record of pos_payement_method with journal type cash 3.…
**Description of the issue/feature this PR addresses:**
steps to reproduce error:-
1.create db with 'point_of_sale' module
2.duplicate the record of pos_payement_method with journal type cash
3. install 'pos_restaurant' module this traceback will raise the **OR** start pos session validation error will come
```
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/odoo/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1791, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1995, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 741, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "<decorator-gen-77>", line 2, in button_immediate_install
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
return method(self, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 466, in button_immediate_install
return self._button_immediate_function(self.env.registry[self._name].button_install)
File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 590, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/odoo/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/17.0/addons/pos_restaurant/data/pos_restaurant_data.xml:4
You cannot use the same journal on multiples cash payment methods.
View error context:
'-no context-'
```
- Here is the reason why above mentioned traceback is raised:
-> [here](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/pos_restaurant/data/pos_restaurant_data.xml#L4) new record of pos.config is creating which trigger the check of pos.config model due to that traceback is raised due to this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)
- **Current behavior before PR:**
if we create ``new`` record of pos.payment.method journal_id field domain not let create another record of journal with type cash if its already present
but if we ``duplicate`` record we can do which is not corrrect as per this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)
- **Desired behavior after PR is merged:**
for resolving this not let duplicate journal_id with type cash. After, this patch user will not able select journal_id with type cash due to [domain](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/point_of_sale/models/pos_payment_method.py#L29) on journal_id and records never will create. From ui .
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#175530Steps to reproduce: - Go to website (in "Edit" mode) > Drop a "Title" block > Add a highlight effect to the title text. - Select a word in the title text > Transform it to a link, and save. - Try to translate the title into another language in the editor > You cannot update the text or remove it. The highlight effects have an auto-updated DOM structure handled by JS. Having an element that is not inline translated (the `<a/>` tag in this case) inside a highlight structure will wr
Original PR description
Steps to reproduce: - Go to website (in "Edit" mode) > Drop a "Title" block > Add a highlight effect to the title text. - Select a word in the title text > Transform it to a link, and save. - Try to…
Steps to reproduce: - Go to website (in "Edit" mode) > Drop a "Title" block > Add a highlight effect to the title text. - Select a word in the title text > Transform it to a link, and save. - Try to translate the title into another language in the editor > You cannot update the text or remove it. The highlight effects have an auto-updated DOM structure handled by JS. Having an element that is not inline translated (the `<a/>` tag in this case) inside a highlight structure will wrap the link content in `<span data-oe-translation-initial-sha="...">` elements that are considered "UNREMOVABLE" and, as a consequence, cannot be adapted as normal content inside the highlight DOM. Also, we cannot translate `<a>` elements inline to fix this issue, since there is a reason why this was prevented (see more details in the commit message from [1]). The goal of this commit is to fix this behaviour by forcing the highlight content to always be translated as a whole. This should wrap all the text highlight DOM in one global `<span>` so it can be translated correctly. [1]: https://github.com/odoo/odoo/commit/9bd60ca93510e410a0136b8b433f596330900593 opw-3980975 Forward-Port-Of: odoo/odoo#170895
Odoo service could not restart after reboot as `service odoo restart` was missing in `wireless_ap.sh` file, which is called in `rc.local`. Forward-Port-Of: odoo/odoo#176967
Original PR description
Odoo service could not restart after reboot as `service odoo restart` was missing in `wireless_ap.sh` file, which is called in `rc.local`. Forward-Port-Of: odoo/odoo#176967
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check: - Button Fail - Quantity: 1 Problem: A traceb
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM: - Component: C1
- Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All
- Create a manufacturing order: - Product: P1 - Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check: - Button Fail - Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check: - Button Fail - Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/odoo#176937
Forward-Port-Of: odoo/odoo#175355This commit is a backport of commit [1], adjusting the `color5` of the color palette generated after uploading a logo in the configurator. Indeed, this color was too light, even though it is supposed to be the darkest. [1]: https://github.com/odoo/odoo/commit/09fd191657372da5a5220fe82c180a3d2f5a076e Related to task-4109584 Forward-Port-Of: odoo/odoo#176930
Original PR description
This commit is a backport of commit [1], adjusting the `color5` of the color palette generated after uploading a logo in the configurator. Indeed, this color was too light, even though it is supposed to be the darkest. [1]: https://github.com/odoo/odoo/commit/09fd191657372da5a5220fe82c180a3d2f5a076e Related to task-4109584 Forward-Port-Of: odoo/odoo#176930