Daily updates from Odoo
Tuesday, July 9, 2024
25 changes · saas-17.2
Resolved issues and error corrections
This fixes an error that could occur when Viva Wallet payment responses were sent to the point of sale. The change helps ensure payment updates reach the POS reliably without disrupting the cashier workflow.
Original PR description
With commit [1], we removed the method ``_get_bus_channel_name``, but at line [2], it's still referenced, which causes an error. AttributeError: ``'pos.session' object has no attribute '_get_bus_channel_name'`` This commit will fix the issue by using ``_notify`` for calling the notification bus. [1]-https://github.com/odoo/odoo/commit/3836aad466c6c111f0f0d33c357a1c7a5150f3fd [2]-https://github.com/odoo/odoo/blob/5633d590decc6e8989c0f454a355e965f072f967/addons/pos_viva_wallet/models/pos_payment_method.py#L133 sentry-5562979975 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents manufacturing order overviews from crashing when the same product is configured as both a component and a by-product in a bill of materials. Users will now be protected from a setup that could trigger an endless processing loop, improving reliability when reviewing manufacturing orders.
Original PR description
Steps to reproduce: - Manufacturing > Products > Bills of Material > New - Add any item as component then the same item as by-product - Confirm - Operations > Manufacturing Order > New - Pick the…
Steps to reproduce: - Manufacturing > Products > Bills of Material > New - Add any item as component then the same item as by-product - Confirm - Operations > Manufacturing Order > New - Pick the product associated to your newly created BoM - Confirm > Overview What happens and why: Odoo raises an RPC error due to an infinite recursion between _get_components_data and _get_replenishment_lines. Both calls are made before the manufacturing order line is flagged as processed so the functions are mutually dependent on the other finishing first. The looping call is conditionally called when document_in and document_out are the same, which seems to be why the stock moves 'move_in' (component) and 'move_out' (by-product) need to be configured this way on the BoM. Why is this an error: This prevents the user from accessing the overview of a valid MO. What this fix does: Moves the flag to before the looping call can be made, so the recursive call does not propagate infinitely. opw-4013371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to
Original PR description
Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to convert the locales from the Python side for use on the JavaScript side. *: payment_adyen Task-4014022 Forward-Port-Of: odoo/odoo#172001 Forward-Port-Of: odoo/odoo#171176
Steps: - Add "rate" field via Studio in the currency form - Try to create a currency Actual result: - Traceback due to rate computation ```python currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id) TypeError: unsupported operand type(s) for /: 'NoneType' and 'float' ``` Expected result: - Default rate value is 1.0 (cf 16.0) opw-4039324 Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd --- I confirm
Original PR description
Steps: - Add "rate" field via Studio in the currency form - Try to create a currency Actual result: - Traceback due to rate computation ```python currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id) TypeError: unsupported operand type(s) for /: 'NoneType' and 'float' ``` Expected result: - Default rate value is 1.0 (cf 16.0) opw-4039324 Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172211
Versions -------- - 17.0+ Steps ----- 1. Go to working schedules; 2. try to modify duration days. Issue ----- Any change gets undone immediately. Cause ----- Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values. Solution
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to working schedules; 2. try to modify duration days. Issue ----- Any change gets undone immediately. Cause ----- Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values. Solution -------- Remove `calendar_id.hours_per_day` from `api.depends`. Having the fields editable is preferable over triggering recomputes ASAP. opw-3999825 Forward-Port-Of: odoo/odoo#171109
[FIX] l10n_dk: fix some accounts' type Some accounts are set as "Expense" but it should be "Cost of revenue" Change them to 'expense_direct_cost' type task-id#3983710 enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168838
Original PR description
[FIX] l10n_dk: fix some accounts' type Some accounts are set as "Expense" but it should be "Cost of revenue" Change them to 'expense_direct_cost' type task-id#3983710 enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168838
Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set,
Original PR description
Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set, if it is, displaying the default value view, else closing the popover. related PR: odoo/odoo#117951 Task-4001976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171697
task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021
Original PR description
task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021
-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912
Original PR description
-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 I
Original PR description
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/…
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 In this method, we first try to find the relevant plans: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L103-L107 To do so, we take all existing plans, evaluate them with a score, and take the one with the higher score. Here is the issue: when evaluating *Projects*, since we didn't provide any business domain and since the plan has a company, we assign a 0.5 score to the plan instead of skipping it: https://github.com/odoo/odoo/blob/f17b37b14cad8f353443586cc9c4ecaf86e476da/addons/analytic/models/analytic_plan.py#L310-L319 Which does not make sense as the business domain of *Project* is *Purchase Order* and here the user is dealing with a BoM... As a result, back to `_validate_distribution`, we check the distribution for this plan and realize there isn't any, hence the error: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L115-L117 Solution: BOM: We don't restrict anymore the creation of a BOM. Setting an analytic distribution is only a tool to facilitate the definition of the analytic distribution on the MO but the creation should not be constrained Workcenter: we correct the flowing by specifying the business domain restricting the creation of a workcenter if any relevant rule is present Forward-Port-Of: odoo/odoo#168688
We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355
Original PR description
We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355
Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forwar
Original PR description
Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forward-Port-Of: odoo/odoo#171471
To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217
Original PR description
To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217
Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503
Original PR description
Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Enterprise PR: https://github.com/odoo/enterprise/pull/65952 opw-4004765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171264
Original PR description
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Enterprise PR: https://github.com/odoo/enterprise/pull/65952 opw-4004765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171264
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A tra
Original PR description
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add…
**Steps to reproduce the bug:**
- Go to contact and select azure interior:
- Sales & purchase tab:
- Enable “Receipt Reminder” 1 day
- Create a purchase order:
- Select azure interior as vendor
- add any storable product
- Delivery date: Tomorrow
- Confirm the PO
- Go to the Scheduled Actions: Purchase reminder
- Run it Manually
- Come back to the Dashbord > Emails
- Select the email for Azure interior:
- Try to click on “YES”
**Problem:**
A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'`
When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117
This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823
We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered.
opw-4028362
Forward-Port-Of: odoo/odoo#172267## Issue: Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet. ## Steps to reproduce: 1. Install website_slide_survey. 2. Create or go to an existing course logged in. 3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect. 4. Go to your profile and check for the attemtps. ## Solution: It will make more
Original PR description
## Issue: Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet. ## Steps to reproduce: 1. Install website_slide_survey. 2. Create or go to an existing course logged in. 3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect. 4. Go to your profile and check for the attemtps. ## Solution: It will make more sense that we only show the actual attempts, which means that we shouldn't show here the attempts that are not finished, since how user_inputs works and are always created at the time of the link creation, we could just filter out the user_inputs that are not actually valid to show here and show only the proper ones. opw-3781323 Forward-Port-Of: odoo/odoo#161456
A traceback is occuring in the backend when the `method` is undefined while using the `POS`. Error:- ``` KeyError: 'method' File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1818, in _serve_db ro = ro(self.registry, request) File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly method_name = params['method'] ``` During an `ORM` call with dynamic method and model, at some point somehow, `metho
Original PR description
A traceback is occuring in the backend when the `method` is undefined while using the `POS`.
Error:-
```
KeyError: 'method'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1818, in _serve_db
ro = ro(self.registry, request)
File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly
method_name = params['method']
```
During an `ORM` call with dynamic method and model, at some point somehow,
`method` value getting undefined with the model as `pos.session`.
This leads to a traceback in the backend side.
After applying this commit it will resolve this issue by handling
the traceback on the `JS` side when the method is undefined.
sentry-5285015466
Forward-Port-Of: odoo/odoo#170676Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania con
Original PR description
Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to…
Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania connected with an ANAF account. The full process on what needs to be done is explained in the settings view, in the "Romanian E-Factura" block. Once a token is generated, we'll be able to use it in all of our request to send/fetch/download data to/from ANAF. --- The Full Sending E-Factura Flow (requires access token) - Upload invoice/credit note to SPV -> get "loading ID" - The invoice gets processed by ANAF (State: "sending") - After some time, fetch the invoice using the acquired loading ID. - If processed, there will be 2 kind of answer: "OK" or "NOK" (not ok) - Either way, we will get a "download ID", which we can then use to download the answer. - If "NOK" -> "Error". Read the zip file and display the error message - If "OK" -> "Sent". Save the zip file attachment task-id: 3595436 related enterprise PR: https://github.com/odoo/enterprise/pull/65602 Forward-Port-Of: odoo/odoo#144061
In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 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#172289 Forward-Port-Of: odoo/odoo#172233
Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings. opw-3995279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171962
Original PR description
Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings. opw-3995279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171962
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is
Original PR description
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report,…
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is immediate. When the employee took care of the payment, a Bill and a Caba Entry are created because the company still needs to reimburse the employee. ### Suggested fix: Adding a Caba Entry is not necessary since there is no need to record the transaction in a transitional account, sending the transaction in the final Account would also match the use case when using Taxes Based On Invoice. `account_id` is selected between the `cash_basis_transition_account_id` of the tax and the `account_id` of the repartition line depending on the values of `tax_exigibility` and `caba_no_transition_account`. https://github.com/odoo/odoo/blob/0c0f0b58aa49cff1efafcc1d4c5a9091e99f2ff4/addons/account/models/account_tax.py#L640-L642 The latter is a context key and is only used in this check, meaning it is most likely harmless to add it in the context of the method. opw-3946362 Forward-Port-Of: odoo/odoo#172196 Forward-Port-Of: odoo/odoo#169255
Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 For
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 Forward-Port-Of: odoo/odoo#172235 Forward-Port-Of: odoo/odoo#172068
When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172317
Original PR description
When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172317
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270
Original PR description
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270