[12.0] update upstream 5c814f7b82b #2407
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…automatic flow PR odoo/odoo#49964 fixed manual payment flow but broke automatic payment flow. This commit should allow both by raising the exception only for manual flow, giving only an error for automatic flows. closes odoo/odoo#50908 Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
PURPOSE Because Odoo might run with different "etree" versions some HTML tags are allowed in a version and not in another. We want to unify the list of allowed tags between etree versions. SPECIFICATIONS Specify allowed tags directly. That way all HTML fields us the same subset of allowed tags, no matter the etree version. Task 2171753 closes odoo/odoo#51773 X-original-commit: 8072aef Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The pos.order.line quantity wasn't considered when computing the discount amount. E.g. buying 5 products (1$) at 50% would only show 0.5$ as discount_amount, instead of 2.5$. Followup of #43587 closes odoo/odoo#51814 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
It changes the output of `[1, 2, 3]` to `res.users(1, 2, 3)` which can be a valuable information. Closes #51636 closes odoo/odoo#51838 X-original-commit: 678893d Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue - Install "Calendar" app - Activate & Set google calendar credidentials - Go to user preference - Edit and set timezone "Europe/Brussels" e.g. - Go to calendar app - Add an event and sync with google - Go to Settings->Technical->Automation->Scheduled Actions - Edit Google Calendar: synchronization - Set "Next Execution Date" ASAP The timezone on Google Calendar synchronised event is: - Before cron: GMT +2 - After cron: UTC Cause If no timezone is provided in context, it will by default use 'UTC' timezone. Solution Like display time on odoo, if no timezone is provided in context, it will check the env.user timezone instead. opw-2228296 closes odoo/odoo#51849 X-original-commit: 41372db Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When search is implemented on a given field, the domain returned by `field.search()` must be normalized, otherwise its processing just crashes (because of missing logic operators). closes odoo/odoo#51899 X-original-commit: 4758a06 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com> Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce the bug: - Let's consider a product P (invocing policy based on timesheet and creating new task) - Create a quotation with the product P - Confirm it (A new task T is created) - Go to T and add a follower (who is a portal user PU) in the task but uncheck the box to send him an email - Connect to the portal with PU - Go to T and send a message Bug: A 403 error was raised opw:2239844 closes odoo/odoo#51906 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In Postgresql version 12.0, performance was improved for the real and double precision values. See: https://www.postgresql.org/docs/release/12.0/ This improvement had an impact on this test because the returned value is now `999.9975000000001` with postgresql 12.0. Anyway, the test should have used `assertAlmostEqual`. closes odoo/odoo#51981 X-original-commit: 167f7a0 Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
As indicated in the comment, it's much preferred to perform response buffering at the reverse proxy level than to increase the socket timeout. It will free up HTTP workers for other requests faster, while the proxy does the work of buffering the stream on disk as needed. /!\ The timeout is also used to protect from accidental DoS effects in situations of low worker availability, due to idle connections caused e.g. by wkhtmltopdf's connection pooling. Setting a high timeout will make the protection less effective, so ensuring you have enough free HTTP workers at all times becomes critical. In our tests with nginx's defaut buffering on a typical hardware with SSD storage, buffering up to 1GB responses did not require any change of the socket timeout on the Odoo side, though your mileage may vary. See also nginx's `proxy_buffering` and `proxy_max_temp_file_size` config directives. OPW-2247730 See also: #20158 closes odoo/odoo#51968 X-original-commit: d78ea12 Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit, when an error occured during a request to Stripe, it was never handled and the script was continuing. Now, the error is handled as expected and raises an exception.
The `get_string` method from the `pyusb` package has changed its signature after version 1.0.0b1 so we used to force the IoT Box to use this version to avoid an error. The problem is that version 1.0.0b1 has dependencies that raise DeprecationWarings in Raspbian Buster. We then want to update the version of pyusb that is installed on the IoT Box in 14.0. As the Driver might be loaded to old versions of the IoT Box as well as new ones, we need to check what version of the package is present on the IoT Box before calling `get_string`. This check will be removed in 14.0, as people will have to use the latest version of the IoT Box. closes odoo/odoo#51229 Related: odoo/enterprise#10595 Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Issue - Have IE 11 or not chromium-based Edge - Install Contacts - Add a salesperson on any contact - Save - Try to remove the salesperson with the cross icon on the input - Save The value comes back Cause We do not handle this feature in dropdowns Solution Remove the dropdown cross icon OPW-2262749 closes odoo/odoo#52053 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Things to know about specific views: Since the introduction of website specific views, we can have multiple views that are related to a website (specific views). These views have no xml_id as it is only set on the original view (generic view). We rely on the view's key to identify related views as it is the same for all specific views of a generic view. Also the key is equals to the xml_id. When a generic view is updated, we will check if the specific views have the same values as the generic view. If it is the case, the value that are the same are considered updatable and are updated on both the generic and specific view. Else these are considered as noupdate. When a generic view is created we will check if the potential parent generic view has specific views. If it is the case we will create a copy of the created view for each specific view. The issue: The method that checks if a created/updated view has specific views is located in website. When we update a module, each modules are initialized and updated in a specific order. If a generic view that has specific views located in a module loaded before website this view's specific views will not be updated/created as the method does not exist. This issue is mainly affecting portal views at the moment. The solution: For write: We now COW(copy on write) the views in base module, meaning this will apply to all qweb views that are duplicated and not only the website specific ones. For create: We will create the generic view as before but wait until we have updated all the modules to gather all generic views that are supposed to have a specific view but don't and create the specific views. This will result in a change of behavior being that if a specific view that have a parent is deleted it will be recreated on update (same behavior as a generic view). closes odoo/odoo#50799 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Installing sale_margin module on a db with a lot of sale.order was impossible. This commit significantly improves performances. Went from many hours (forecasted) to 15 minutes on a db with 300k orders For sale.order.line: - Adding a read to prefetch everything at once in non edit mode For sale.order: - Duplicating logic between edit mode and non edit mode - Edit mode logic stays the same as before - Non edit mode uses read_group to speed up the computation closes odoo/odoo#52006 X-original-commit: 554fb1e Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
get_specific_views was returning non qweb views closes odoo/odoo#52145 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The *Reload File* import functionality stands on an undefined behavior or the HTML File API. The API is not clear about what should done in case the underlying file change on the filesystem after it has been imported in the browser. It turns out the actual behavior vary among browsers and even among OSes. The *Reload File* button only works as intended when importing files via Chrome on Linux. In other cases, the browser may refuse to send the file or may send it in a corrupted HTTP request. Such malformed request is rejected in the best cases by the backend web application but there is chance it hangs. Security-wise, this problem is not much likely to happen as it requires an authenticated user with importation privileges to perform the operation. When it comes to the severity, it is possible to exhaust the available workers by forcing every one of them to hang. As there is a security impact, we decided to disable the *Reload File* functionality. Steps to reproduce ------------------ 1) Import a CSV or XLSX document in any model. 2) Wait for the data visualization to come back to the browser. 3) Change the file on disk to a) remove a few lines b) add a few more lines. 4) Click the Reload button. Wrong `size` attribute on Firefox. ---------------------------------- Impact: Firefox The advertised `Content-Length` HTTP header in the POST request is a) *greater* than the actual body length. The backend web application hangs on a `socket.recv` like function waiting for those missing bytes. b) *smaller* than the actual body length. The request is truncated and futher processing is impossible. The malformed request should have been detected and reported by the http web application as requested by the HTTP/1.1 spec [1]: > When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected. Mitigating the issue is possible using nginx as reverse-proxy. The connection is closed after one minute if data are missing. Invalid `ERR_UPLOAD_FILE_CHANGED` --------------------------------- Impact: Chrome on Windows Chrome prevent sending the XHR due to a `ERR_UPLOAD_FILE_CHANGED` error, this error should only happens when the underlying file content have been changed the second before the request. On Windows, the error is triggered as soon as the file have been changed, not considering the modification time. [1]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html Section 4.4 opw-2252440 closes odoo/odoo#51753 X-original-commit: 9d97443 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com> Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce: - install events - create an event in the future and save - add an attendee > confirm > send by email - send the 'event: registration' template to the attendee - go to the chatter and click the '+ Outlook' button in the sent email Previous behavior: the link is no longer valid Current behavior: the link sends you to outlook live opw-2257062 closes odoo/odoo#51986 Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Issue - Save a credit card in chrome - Install "Ecommerce" module - Activate/Publish "Authorize.net" payment acquirer - Set the "Payment Flow" field to "Payment from Odoo" - Save and go to front end shop - Add any product to cart and go to checkout process - Chose Authorize.net as payment mode - Fill with autocompletition the credit card form Error message: "e.g. Your credit card details are wrong. Please verify." Cause It will not validate the expiry date if it has 4 digits number as year. Solution Handle year date with datetime library: it allows to set 2 or 4 digits number as year. opw-2239065 closes odoo/odoo#52040 X-original-commit: e99044a Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com> Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
closes odoo/odoo#52261 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
…ustomer'
Issue
Step done with "CRM" since main kanban view can be
grouped by 'res.partner' model:
- Install "CRM" app
- Go to crm and group by "Customer".
- Add a Column.
Traceback is raised.
Cause
Wrong "default_type" in context ('opportunity' in this case)
when creating new kanban stage and grouped by "Customer".
Solution
On "default_get" for "res.partner", if "default_type" is in
context and not in 'type' selection choices field; then
remove it from context.
Cherry-pick of #47723 in 12.0
opw-2256905
closes odoo/odoo#52265
X-original-commit: e579642
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug: - Let's consider a customer company partner P - Let's consider, P1, a child partner of P - Create a SO for P1 - Archive P1 Bug: The SO count in the smart button Sales of P was 0 instead of 1 opw:2267828 closes odoo/odoo#52237 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Backport from 13.0 (0e8f867) Before this commit, a user with attendance administrator rights can see the attendances of all users of all companies and not only the companies he is allowed. Now, the administrator will only see the attendances of the users of the companies he is allowed. opw-2263577 closes odoo/odoo#52356 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Backport of odoo/odoo#52001 This tag needed to be reintroduced from v11, in order to be able to add -balance of this tax amount to the reported total. opw 2230389 closes odoo/odoo#52315 Related: odoo/enterprise#10904 Signed-off-by: Josse Colpaert <jco@openerp.com>
Commit bca2926 introduced a fix for ir.ui.view unlinks during uninstall but forgot to return the result of the super() call to unlink which broke behaviour downstream. This commit restores the proper behavior of returning the result of the call to super. Closes #52364 closes odoo/odoo#52395 X-original-commit: c526410 Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
To reproduce:
Introduce some error in a mail template.
For instance:
`% set bug = object.not_exiting_function()`
Before this commit:
The user message is confusing with irrelevant information.
In my example case:
```
Failed to render template <Template memory:7f76f424b2b0> using values {'format_date': <function MailTemplate.render_template.<locals>.<lambda> at 0x7f76e9422d08>, 'format_tz': <function MailTemplate.render_template.<locals>.<lambda> at 0x7f76e9422840>, 'format_amount': <function MailTemplate.render_template.<locals>.<lambda> at 0x7f76e9422950>, 'user': res.users(1,), 'ctx': {'lang': 'en_US', 'tz': 'Europe/Brussels', 'uid': 1, 'type': 'out_invoice', 'journal_type': 'sale', 'params': {'action': 198}, 'active_model': 'account.invoice', 'active_id': 3, 'active_ids': [3], 'default_model': 'account.invoice', 'default_res_id': 3, 'default_use_template': True, 'default_template_id': 7, 'default_composition_mode': 'comment', 'mark_invoice_as_sent': True, 'custom_layout': 'account.mail_template_data_notification_email_account_invoice', 'force_email': True, 'search_disable_custom_filters': True, 'tpl_partners_only': True, 'safe': False}, 'object': account.invoice(3,)}
```
After this commit:
More relevant information are added to the logs and user message.
In my example case:
`UndefinedError: 'odoo.api.account.invoice object' has no attribute 'not_exiting_function'`
OPW-2266567
closes odoo/odoo#52413
X-original-commit: 6ae9c09
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
The checkout to switch to the branch of the connected DB was not processed correctly because the command used to clear the drivers failed, raising an exception: `rm: cannot remove '/home/pi/odoo/addons/hw_drivers/drivers/__pycache__': Is a directory`
The location of the drivers has been changed in master. So, even if we
perform a checkout, the `addons/hw_drivers/drivers` directory doesn't
exist. The `get_resource_path('hw_drivers', 'drivers')` then returned
False instead of the correct path and the extraction of the zip file
failed.
closes odoo/odoo#52432
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
closes odoo/odoo#52437 Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Issue - Open console in debugger of the browser. - Install "Employees" app - Go to "Employees" and edit or create any employee - In 'Department' field, quick create one Error is raised in console and the modal department form view is opened. Cause 'name' field is required but empty since 'complete_name' is the one set as _rec_name in 'Department' python model. Solution Cherry-pick of 7c0fed4 opw-2267356 closes odoo/odoo#52454 X-original-commit: 9c510ac Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
…uation Enable Consignment Have a [DEMO] product with category having automated inventory valuation Create a PO/SO Add a line with [DEMO], validate, go to the picking and set an owner to the stock move (need to enable detailed operations in the operation type) Validate the picking. Go back to the PO/SO. Validate and create the invoice/bill. This is using the interim account on the invoice/bill line, but it should use the expense account instead because the interim was never hit on the receipt since it has an owner. opw-2320097 closes odoo/odoo#56458 Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
backporting changes from commit 4f59004a0f407e93cfed2126198208738ed47f9a Purpose ======= If a manager creates a leave for an employee in another timezone, the employee's timezone should be used, not the user's timezone. Currently, if a manager with timezone UTC creates a leave (one day) for an employee in New Zealand timezone, the leave is during the night from the employee's perspective. Specification ============= 1) Use the employee's timezone for saving leave dates. 2) Display a warning if the user and the employee have different timezones. closes odoo/odoo#57493 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
…ing cash basis and regular taxes Solves odoo/odoo#56803 Use case: 1) Create accounts ACC TAX A, ACC TAX B, with reconcile = True, internal_type = other 2) Create Tax A, with tax_exigibilty = on_invoice and account_id = ACC TAX A, 20% 3) Create Tax B, with tax_exigibilty = on_payment and account_id = ACC TAX B and cash_basic_account_id = ACC TAX A, 20% 4) Create invoice A, account_id = Tax A, unit_price = 1000, Valide invoice 5) Create invoice B, account_id = Tax B, unit_price = 500, Valide invoice, 6) Register full payment for invoice B. The cash basis tax creates a miscellaneous operation MISC A, containing a line on ACC TAX A. 7) Create a mis operation MISC TVA, like this: line 1 : account_id = ACC TAX A, credit = 300 line 2 : account_id = 401100, debit = 300 8) Reconcile the following move lines: line of MISC A with account ACC TAX A (300) line of invoice A with account ACC TAX A (200) line of MISC TVA with account ACC TAX A (100) ==> When doing that, not full reconcile object was created between the reconciled lines, while it should have been. closes odoo/odoo#57495 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When purchasing a product through the e-commerce using product configurator features such as custom attribute values, the computed product description containing the selected values could be broken when using special values. This commit fixes the description building by using proper DOM manipulation. Task 2337859 closes odoo/odoo#57517 Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
A payslip in state done cannot be deleted. But in case it is included in a payslip batch, we should not be able to delete it when deleting the batch. closes odoo/odoo#56903 Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
* Change the `addons/account/i18n/vi.po` PO file to replace the translation of `Vendor Bill` like msgids from `Công nợ nhà cung cấp` to ` by `Hóa đơn Nhà cung cấp`, there should be 3. What's matter is the `đ` character. * Create a brand new Vietnamese database (using `-l vi_VN` and `--load-language=vi_VN`) * Install Invoicing (`account`), an email alias constraint is raised. > You cannot use anything else than unaccented latin characters in the > alias address. During the installation of the invoicing module, an email alias is created for every journal account of purchase type. The alias is created using the current journal name. Here the journal name is `Hóa đơn Nhà cung cấp`, as mail aliases should only contain ascii characters, we attempt to remove the accents. The `tools.misc.remove_accents` successfully remove most of them but the `đ` character is left as-is, the final alias is `hoa-đon-nha-cung-cap` which is invalid as it contains some non-ascii characters. The `remove_accents` function uses the [NFKD] Unicode Compatibility Decomposition Normalization Form. This normalization process unify all abstract equivalent characters, i.e. characters only different by font or rotation. While this normalization process helps to transcript a lot of characters to their ascii compatibility equivalent, some 118,230 other non-ascii characters (mainly from the Chinese and Japanese scripts) are left as-is as they lack an ascii compatibility equivalent. The solution has been to not use the journal name but rather the journal code or journal type as email alias when the name is unsafe. The journal code is a short version of the name, the journal type is not translatable so is always ascii. One additional watchdog has been added to the sanitization function of email aliases so non-ascii characters are replaced with a '?' which is an authorized character in emails local-part. [NFKD] https://unicode.org/reports/tr15/ Closes #55492 Closes #55493 closes odoo/odoo#55597 Signed-off-by: Simon Goffin (sig) <sig@openerp.com> Co-authored-by: Thong Le <thongthele@users.no-reply.github.com>
Column mappings are updated in-place, if multiple users are importing records
of the same model at the same time, this will trigger concurrency errors.
This is made worse by the error only being reported on commit (after having
processed the entire import) and being retried automatically, so it slows down
the user and the entire system, the more concurrent imports the slower.
Log except:
INFO dbname odoo.addons.base_import.models.base_import: done
ERROR dbname odoo.sql_db: bad query: UPDATE "base_import_mapping" SET "field_name"='name',"write_uid"=%s,"write_date"=(now() at time zone 'UTC') WHERE id IN (%s)
ERROR: could not serialize access due to concurrent update
INFO dbname odoo.service.model: SERIALIZATION_FAILURE, retry 1/5 in 0.8720 sec...
closes odoo/odoo#54248
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It links to the same url as the previous sentence.
The page shows the first 15 lines of a CSV in raw form as an example. Next it shows the same data rendered as a table. However, it was displaying the entire 680-line source data. `csv-table` doesn't have a `:lines:` directive. I copied and truncated the original file for use in the documentation.
MAT confirmed the Javascript API is currently not being built due to repeated compatibility problems between ES6 and the docstring output with no clear solution in sight.
Add dvdhinesh Remove amkarthik closes odoo/odoo#57656 X-original-commit: 9cb093a Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Some line items in a bulleted list would span a paragraph but the first line of the paragraph would be in bold and the rest would be indented and not bold below it. You would end up with sentences that broke off half in bold and half in the regular font. This was due to wrong indentation in the source. The pattern was also used for more legitimate cases (field descriptions), as well as borderline cases (where a section might have also worked). I've updated the borderline cases to have consistent formatting across the document and removed the bullet points that were prefixing description lists in both cases.
Also added an example.
Added an example because it's non-trivial to realize why you would want to set `mode` to `primary` together with `inherit_id`. Another way to look at it is that the view matching doesn't understand delegation inheritance. If it did there would be no need to override `mode` because it would be able to see that the parent and derived views refer to related models. But since that feature might not be worth the effort, it's ok for me to just document the current situation.
The behavior isn't exactly undefined: it will appear to work if the relation refers to only 1 instance. If there are multiple it will give results for 1 instance and ignore the others. This behavior should not be relied upon, hence I'm documenting it as undefined. I confirmed this with mat from the ORM team. Even better would be to raise an error or warning if `related` is used in this context. closes odoo/odoo#57647 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> Signed-off-by: Raf Geens <raf-odoo@users.noreply.github.com> Co-authored-by: Raf Geens <raf@odoo.com>
closes odoo/odoo#33714 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to the Spanish accounting rules, this commit tries to set more appropriate account types to the different account_account templates. closes odoo/odoo#57625 X-original-commit: 7207eb0 Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Create a paragraph the jQuery way. This way we avoid breaking the node if the error contains a </p> argument. closes odoo/odoo#57725 X-original-commit: 203da43 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commits solves different rendering issues in the javascript reference documentation, following the work done in #57270, but for issues added in further versions and missed in the forward-port. closes odoo/odoo#57758 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The original feature was introduced in commit #8248f0e153a and works well for internal transfers, but fails for dropship. For latter, if quantity is changed on confirmed PO line, new picking is created, even if the quantity was decreased not increased, leaving the new draft picking empty. closes odoo/odoo#57113 Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The attribute Exception.message is no longer available in Python 3, and
newer versions of pylint check for this and raise an error during
test_lint, with this commit we take care of these codesites in the
following manner:
* For test_convert, the access was in a function that is effectively
dead code, and thus it has been removed.
* In modules.py, it is accessed in code that is used *BUT* is within a
pycompat.PY2 block, which means it'll only be called if running
under python 2 which is legal, therefore we just add a comment for
pylint to ignore this specific call
With this, we can upgrade pylint to the newest version and fix a
longstanding bug with MRO building in pylint.
closes odoo/odoo#57871
X-original-commit: 5a4d531
Related: odoo/enterprise#13295
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
…814f7b82b No conflicts
AdriaGForgeFlow
approved these changes
Sep 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updated.
No conflicts.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr