11.0 #13
Open
11.0 #13
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
On the website for portal and public users, we only show membership products that are set as website_published. But if you only install eg. website_membership there is no clear way through "Members" > "Configuration" | "Membership Products" to set product as website_published. opw-2202766 closes #47342 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
- Install some random module that can be uninstalled (so not base)
- Open the uninstall wizard for said module in two different tabs /
windows / whatever
- In one tab, confirm the module uninstall and wait for it to be
done
- As soon as the other tab is done with the uninstall, go to the
second one with the uninstall wizard still open, and proceed
with the second uninstall
- Boom, the registry crashes and completely fucks up the DB because
there's no check at all that prevents the uninstall of already
uninstalled modules.
After this commit:
- `ir.module.module.button_uninstall` will check if all the
modules being uninstalled are in the installed state
and if not a UserError will be raised, preventing a second
uninstall of the module which could potentially break the DB
Do note that this fix is LOCAL, the problem is however more or less
global, wherever there's user-actionable buttons that should only be
pressed once there's a potential for bugs / breakage if a similar fix is
not implemented locally. Perhaps a more global fix should be implemented
eventually, but it's generally less annoying for business cases since
those probably won't break the registry, see task 1859014.
opw-2213679
opw-2212594
opw-2206446
closes #47414
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The synchronisation of commercial_partner_id was introduced at 0d68acf as a way to ensure the value is always correct. The order or the operation was not important though. This synchronisation has a side effect in the following scenario: 0. install base_vat 1. disable vat_check_vies in the settings 2. set an invalid VAT number on a company with at least one contact 3. enable vat_check_vies in the settings 4. correct the VAT number on the company with a valid one --> an error was raised for an invalid VAT number on the contact This is because the commercial_partner_id synchronisation is done before the update of the VAT number. Even if the value has not changed, this triggers the check_vat method. Invert both instructions Courtesy of Wolfgang Taferner Closes #43065 Closes #42973 closes #47219 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The default currency of Guatemela is GTQ. opw-2201797 closes #47621 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO with a dropship product, set a qty of 1.0 - Validate the SO - Validate the corresponding PO - Change the qty to the SO to 2.0 2 PO are created: the first one with a qty of 1.0, another with a qty of 3.0. There is an overlap of functionality between: - `_purchase_increase_ordered_qty` from `sale_purchase` (first PO) - `_action_launch_stock_rule` from `sale_stock` (second PO) The quantity is incorrectly computed since the quantity on the PO is taken into account only if the no stock move exist. We remove the latter condition, so the procurement quantity is computed correctly. opw-1950076 closes #31963 closes #47677 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com> Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce: - install mrp - go to mrp > configuration > settings > activate work orders - go to mrp > master data > work centers > create > giva a long name to the work center > save > duplicate > give a specific code to the work center > save - go to mrp > group by > custom > select "code" Previous behavior: the kanban cards are overlapping each others when the work center's name is too long Current behavior: kanban cards have a set width and do not overlap backport of e8e3ba9 opw-2213502 closes #47701 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Le compte 608. « Frais accessoires d’achat …» peut être ventilé : Selon les achats concernés comme les matières premières, les marchandises et les différents approvisionnements : Dans ce cas, sont recommandées les subdivisions suivantes : 6081 Frais accessoires sur achats de matières premières (et fournitures) 6082 Frais accessoires sur achats d'autres approvisionnements stockés 6084 Frais accessoires sur achats d'études et prestations de services 6085 Frais accessoires sur achats de matériel, équipements et travaux 6086 Frais accessoires sur achats d'approvisionnements non stockés 6087 Frais accessoires sur achats de marchandises Référence: http://public.iutenligne.net/comptabilite/comptabilite-financiere/antraigue_januario/CTA-FIN-14/Chapitre-01/Sous-section-1-1-2.html opw:2186347 closes #46672 Related: odoo/enterprise#8962 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1. Create a product A with 'Control Policy' set to 'On received quantities' 2. Create a PO for 10 units => status is `no` 3. Validate the PO => status is `no` 4. Receive 5 units => status is `to invoice` 5. Invoice 5 units => status is `invoiced` 6. Receive the remaining quantity => status is `to invoice` 7. Invoice the remaining quantity => status is `invoiced` There is an inconsistency between steps 3 and 5: there is pending material to receive, but the status is different. This is due to the fact the `order.invoice_ids` is checked, while it shouldn't affect the computation of the status. The status should be `no` in steps 3 and 5. opw-2206447 closes #47358 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Status : For the moment, the "load more" button skip some lines each time we use it. The splice is not used correctly. For example, on a array of 75, we see the first 30 lines. The splice function cuts the array in two : The first 30 lines on one and last 45 lines in an other. After the cut, we say that an index is at 30 to split on the load more. When we click on "Load more", we check the second array. But, as we use the index at 30 for the splice function, we skip the first 30 lines of the second array (with only 45 lines so we needed to take the first 30 lines) and only show the last 15 lines. Expected : When we click on "load more" button, we need to respect the pagerIndex and not remove elements. Fix : Changing the way we use the splice. Using slice instead of splice. opw-2171734 closes #47719 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Co-authored-by: Nicolas Lempereur <nle@odoo.com>
When passing a view
from `active` `False`
to `active` `True`,
its xml wasn't being checked, and it could be very well be invalid.
e.g.
Create a view inheriting from `base.view_partner_form`
`active` set to `False`
`arch` set to
```
<field name="foo" position="after">
<field name="bar"/>
</field>
```
On creation, the `_check_xml` constraint is valid because the view is disabled.
Now, write `active` to `True`. Notice no constraint error is raised while the view is invalid.
This is particularly critical now that we automatically disable invalid custom views
during upgrades. When the user tries to re-enable the view which has been disabled to see
what was wrong, he doesn't get any error because of this.
closes #46305
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Because of the law of the 1st december 2019, we can't pay with 1 or 2 cents anymore. We have to round the total price to the 0.05 unit. If the customer pay without rounding values, it triggers an error. Before the order is finalized, we add a line with a product rounding to round the total amount. task-id: 2035010 Backport of PR: #40958 Backport of PR: #39488 Backport of PR: #41951 closes #47864 Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Importing 100 records and getting 100 errors (often the same every time because a required field was not mapped) is not super useful and spams the logs a lot. Cutting off at one point seems useful. closes #47660 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The intent of #47660 was to cut-off after some number of *errors* (fatal which would cause import rollback) in order to avoid the huge number of redundant error reporting if a significant fraction of or all lines are in error. However it did not take in account that the messages list can contain both errors and warnings (and possibly other message types), meaning it can stop importing after having loaded the first record if the records extraction / conversion has reported more than 10 warnings. Fix this issue, instead of counting messages, only account for errors reported during the loading process itself by specifically counting these. Reported by Grzegorz Marczyński Closes #47936 closes #47972 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce: - Create a vendor bill - Add a line with tax "IVA Soportado exento (operaciones corrientes)" and an analytic account. - Add another line with same tax but different analytic account. Current behavior: There are 2 account.invoice.tax for the tax, one per analytic account Expected behavior: There should be only one. This is important because some developments like SII sendings to fiscal authority depend on these lines. The reason behind the problem is that the flag "Include in Analytic Cost" is ignored when there are no configured accounts for the tax. We may want to fix this behavior instead, but it's debatable which one is the suitable one. As for these cases, it's clear that we can set a tax account as there's no tax at all (they are 0% percentage), this workaround is the best option. closes #48018 Signed-off-by: Josse Colpaert <jco@openerp.com>
-Ensure Sales Channel has an alias set -Create new opportunity with above sales channel set -Send message to customer and then the customer replies. -Now remove sales channel -Send message to customer and the customer replies When you send a message in a model that has an alias configured the alias is used as the reply-to. So in the above situation when you send a message from an opportunity linked to a sales channel with an alias the reply-to is sales@mycompany.odoo.com. However, once you remove the sales channel the fallback reply-to is the sender. As a result the customer response is never received by Odoo opw-2200301 closes #47191 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate SIPS - Make a payment of 263.90 on the eCommerce The SO is not confirmed because there is 0.01 of difference. This is due to the fact that 263.90 * 100 = 26389.9999... Using `round` instead of `int` prevents truncating the value. opw-2179123 closes #48127 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When we print a report for multiple records, we call wkhtmltopdf one
time and to save each document separately, we will split the PDF based
on its outline if it is available.
The outline is generated by wkhtmltopdf based on headings
(H1,H2,H3,H4,H5,H6,H7,H8,H9 elements) for example this document:
```
<h1>hello</h1>
<h2>world</h2>
<h1>!</h1>
```
has this abbreviated outline structure:
```
/Outlines: {
'/First': {
'/Title': 'hello'
'/First': {
'/Title': 'world'
},
'/Next': {
'/Title': '!'
}
}
}
```
But the current heuristic did not take into account level of headings,
so if the document had a lower-level headings this could break the
multi-printing of these reports.
So for the example above, the document would be cut in 3 when in reality
we only want to cut it twice over the top level heading (`<h1/>` here).
An existing issue in Odoo is in l10n_in_sale, `<h6/>` element are added
to the report invoice line so instead of only one `<h2/>` heading
containing the invoice name per document, there was an additional
heading per invoice line which broke the heuristic.
note: we also add an assertion to ensure first heading is on first page.
note: allowing several top-level heading on same page has been
implemented so reports that did not work in 11.0 but worked in 12.0 and
over (thanks to 573e577) still work after this change.
opw-2188767
closes #48099
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Issue
- Install Website
- Edit your website
Do this 8 times:
- Add the block "Image - Text" under each product
- Make image on left smaller and text longer
- Edit the size/color of the title and the description
There is some case where it will crash
Cause
We override the method who gets the editor:
`x = $('[data-note-id="' + list.last($target.attr('id')) + '"]');`
When there is more than 9 editors in the page
(because we edited 10 different HTML fields), we reach the
editor with ID 10 but the code erroneously will not find the
editor with ID 0
Solution
Use this instead:
```
x = $('[data-note-id="' + list.last($target.attr('id').split('-')) + '"]');
```
OPW-2218467
closes #48001
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce the bug: - Let's consider a user U with User access rights in Inventory and Employee in Employee - Log as U on mobile or tablet and create a stock.picking - Set a type (Ex Receipt) and add a line - Save Bug: An access right error was raised because Odoo tried to write on the product the value of product_tmpl_id Making the same operation in a large size screen doesn't make any issue. opw:2212693 closes #48412 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce: - install sales and barcodes - go to sales > catalog > products > create - give the product a random name and the following barcode: #1N4005-T+A - save > print > product labels Current behavior: the barcode is not generated properly because it is not url encoded everything after the # charachter is ignored Current behavior: barcodes are url encoded and generated properly opw-2203716 closes #47978 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Change the decimal point and thousands separator for es_PE and es_CR Set the currency symbol and position for Colon CRC closes #48468 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There is a discrepancy between what country is used to compute the fees for a transaction depending on where we are in the payment flow. At rendering, the country of the order's shipping partner is used (since it is set as the main partner in the rendering values dict through `render_sale_button`). At creation, the country of the partner is used (since the `payment.transaction` record is created with the order's main `partner_id` in `_create_payment_transaction`). This is unfortunate and can cause issues with payment flows if there is a mismatch between countries of the shipping/invoice/main partner, as the fees may be computed as 'international' in one case and 'domestic' in another - this causes the values sent to Paypal to differ from those saved on the transaction, which causes the transaction to be rejected upon return from Paypal because of an amount mismatch. Since the transaction is created using the main partner of the order, I believe it is preferrable to use it for the rendering as well. Some may dislike this choice, as it means that if you use these fees to manage your delivery fees, a customer with a shipping address to is not the same as the company's country will pay domestic fees, while they should pay international ones. However, this is mitigated by the fact that: - this did not work before this commit (hell of an argument) - the delivery module is there to handle those cases with much higher configurability - having a consistent computation is more important than managing this case opw-2225023 closes #48498 Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
SIPS date format can be somewhat variable, some sanitation is required before using the data raw for the ORM. opw-2224926 closes #48582 Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
In some situations, the context can contain a default journal id. When creating the cash basis entry, we are correctly retrieving the Cash Basis Journal for the account.move, but as we do not explicitly set the journal on the account.move.line also, it is using the context default value for journal_id (usually the customer invoices journal). As journal_id on account.move.line is a related field to journal_id of account.move, we are wrongly updating it. We should populate journal_id on account.move.line explicitly to avoid this. closes #48510 Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
closes #48655 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently, there's only one tax for non deductible VAT on purchase, but although the most common one (21% percentage), it's not the only one. There can be cases where there's 4% or 10% VAT that is not deductible. With this PR we add that percentages to the CoA. closes #48629 Signed-off-by: Josse Colpaert <jco@openerp.com>
Could import translation on a non-active translation
…ntry_codes' The vatnumber is pinned to version 1.2 in the requirements.txt: -https://github.com/odoo/odoo/blob/85f3fe323c9105827931febda04745a55c1f44a4/requirements.txt#L41 but vatnumber does not have a pinned version to stdnum package So, it is installed the last version even if it is not compatible A new version was released of stdnum 1.15 on Jan 11, 2021 - https://pypi.org/project/python-stdnum/1.15/ But it is not compatible with odoo@11.0 anymore because of there is not exists the following attribute: - stdnum.eu.vat._country_codes or stdnum.eu.vat.country_codes Used in the following line: - https://github.com/odoo/odoo/blob/85f3fe323c9105827931febda04745a55c1f44a4/addons/base_vat_autocomplete/models/res_partner.py#L15-L17 So, the following error will raised: 2021-01-12 22:40:39,897 155 CRITICAL DB odoo.modules.module: Couldn't load module base_vat_autocomplete 2021-01-12 22:40:39,897 155 CRITICAL DB odoo.modules.module: module 'stdnum.eu.vat' has no attribute '_country_codes' 2021-01-12 22:40:39,905 155 WARNING DB odoo.modules.loading: Transient module states were reset 2021-01-12 22:40:39,906 155 ERROR DB odoo.modules.registry: Failed to load registry Traceback (most recent call last): File "./modules/registry.py", line 85, in new odoo.modules.load_modules(registry._db, force_demo, status, update_module) File "./modules/loading.py", line 380, in load_modules loaded_modules, update_module, models_to_check) File "./modules/loading.py", line 274, in load_marked_modules perform_checks=perform_checks, models_to_check=models_to_check File "./modules/loading.py", line 137, in load_module_graph load_openerp_module(package.name) File "./modules/module.py", line 368, in load_openerp_module __import__('odoo.addons.' + module_name) File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 664, in _load_unlocked File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible File "./modules/module.py", line 82, in load_module exec(open(modfile, 'rb').read(), new_mod.__dict__) File "<string>", line 4, in <module> File "./base_vat_autocomplete/models/__init__.py", line 4, in <module> from . import res_partner File "./base_vat_autocomplete/models/res_partner.py", line 17, in <module> stdnum_vat.country_codes = stdnum_vat._country_codes AttributeError: module 'stdnum.eu.vat' has no attribute '_country_codes' 2021-01-12 22:40:39,907 155 CRITICAL DB odoo.service.server: Failed to initialize database `DB`. Traceback (most recent call last): File "./service/server.py", line 1043, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "./modules/registry.py", line 85, in new odoo.modules.load_modules(registry._db, force_demo, status, update_module) File "./modules/loading.py", line 380, in load_modules loaded_modules, update_module, models_to_check) File "./modules/loading.py", line 274, in load_marked_modules perform_checks=perform_checks, models_to_check=models_to_check File "./modules/loading.py", line 137, in load_module_graph load_openerp_module(package.name) File "./modules/module.py", line 368, in load_openerp_module __import__('odoo.addons.' + module_name) File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 664, in _load_unlocked File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible File "./modules/module.py", line 82, in load_module exec(open(modfile, 'rb').read(), new_mod.__dict__) File "<string>", line 4, in <module> File "./base_vat_autocomplete/models/__init__.py", line 4, in <module> from . import res_partner File "./base_vat_autocomplete/models/res_partner.py", line 17, in <module> stdnum_vat.country_codes = stdnum_vat._country_codes AttributeError: module 'stdnum.eu.vat' has no attribute '_country_codes' 2021-01-12 22:40:39,908 155 INFO DB odoo.service.server: Initiating shutdown 2021-01-12 22:40:39,908 155 INFO DB odoo.service.server: Hit CTRL-C again or send a second signal to force the shutdown. Fixed pinning the last version compatible python-stdnum<=1.14 closes #64447 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
instead of using ad-hoc weirds closes #66437 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In windows chrome 89 (at least at version 89.0.4389.114 (29 march 2021)) clicking on a select option doesn't trigger jQuery events if they are delegated. For example this happen when selecting a field for custom group or custom filter in the search view and when selecting a field the dropdown closes. This happens because: - chrome now sends MouseEvent.button[^1] with value -1 instead of previousvalue of 0. - jquery in odoo 12 and under is version 1.11.1 and only executes the delegated event if the button value is 0 Reproduction case of the issue [^2]: clicking to choose an option only logs "non-delegated click". So for version 11.0 and 12.0 only, this commit is cherry-picking jquery's commit that is fixing the issue: jquery/jquery@c82a6685bb9 [^1]: https://developer.mozilla.org/docs/Web/API/MouseEvent/button [^2]: http://jsfiddle.net/cox4gzae opw-2497859 opw-2499415 opw-2499305 opw-2466991 opw-2506676 backport of #69274 closes #69304 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose ======= When creating an attendee from frontend some fields may be added in parameters, notably through inheritance (questions, ...). We want the defaults values to have the priority on those parameters (e.g. barcode code). Task ID-2322411 PR #68699
A computed field on event may crash if current user is a portal user as it tries to access registrations to know if current user is already participating to the event. We also fix ACL on the registrations as most code already use it as sudo and do not access it directly. Only the event users or admins should access it directly. Task ID-2322411 PR #68699 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
closes #69945 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As part of the Python 3 compatibility effort, 01e3514 moved all uses of urllib(2) to werkzeug & requests as the packages were renamed and reorganised between P2 and P3. For `module.py`, it looks like I confused the `urls` local variable for an already imported `werkzeug.urls` and just tried calling `url_parse` on that. Which doesn't work, because `urls` is a dict. Fixes #71076 closes #71080 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`update_db_index` is meant to skip the creation of the index if it fails. It therefore uses `with cr.savepoint()` for that purpose But, before this revision, it surrounds `create_index`, in which the index creation is skipped if it already exists. Meaning, if the index already exists, a savepoint was created for nothing. Creating a savepoint has a cost. Therefore, avoiding to create one when it's not necessary is better for the performances. In addition, during an installation / upgrades, a lot of index are attempted to be created, and the performance of postgresql are degraded when there are more than 64 savepoints within the same transaction, which could easily happen when installing/updating a module, while attempting to create all its indexes (despite they already existed). Moving only the `with cr.savepoint`, without moving the `try..except` will have no impact on the API. It's still the role of the method calling `create_index` to catch the exception if it wants to. Besides, for the methods which are calling `create_index` without a `try..except` block, the transaction will still be rollbacked, as it's the case for any uncatched exception in Odoo. There is therefore no downside to move `cr.savepoint` into `create_index`. closes #71565 Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
5195550 mitigated an issue of being able to try and download files which don't exist yet, make the fix more reliable by clearing out the field completely and hiding the content if the (readonly) field has no value *or the record is not saved yet*. Also clean up the code: * an old-style forward port created a duplicate fixprovement (a8d01cb) which seems less correct as it applies conditionally * and the code is branchier than necessary, we can make it simpler by judiciously leveraging jquery's API closes #77603 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Modernize code to avoid hand-rolling addons path manipulations, as well as remove a pycompat callsite. closes #82462 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Both of the native `magic` libraries can trigger an allocation error if the buffer being sniffed is large. This results in nothing useful for the user and just triggers and exception when trying to create large attachments (in the hundreds of MBs). Fix by implementing the workaround suggested in ahupp/python-magic#82, under the assumption that it should also work fine for Debian's python-magic. The pure-python trivial version of odoo should not have this issue, as it does not normally copy the source buffer in full, it just seeks and slices the buffer, and occasionally parses it as a zip (but does not normally load everything in memory). Task-2722110 closes #82791 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Collaborator
Author
|
testing close |
Collaborator
Author
|
upgrade odoo |
…version change closes #117019 Signed-off-by: Christophe Simonis <chs@odoo.com>
When we compare majorless scripts we must ignore the Odoo version.
Otherwise a module upgrade without major Odoo upgrade would fail to run
local scripts majorless scripts. That's what happens for example when
users click the upgrade button of a module.
Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder
for upgrades.
```
11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch)
1.0 < 2.0 <= 2.0 -> True (check with this patch)
```
While still: upgrade from `11.0.2.0` to `12.0.2.0`
```
11.0.2.0 < 12.0.2.0 < 12.0.2.0 -> False (before this patch)
2.0 < 2.0 <= 2.0 -> False (with this patch)
```
closes #119027
Signed-off-by: Christophe Simonis <chs@odoo.com>
closes #127276 Related: odoo/enterprise#43420 Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Prevent an infinite loop when the cycle in the parents does not contain the starting id: `3->2->1->2->1...` Example: ``` >>> m=self.env['ir.module.category'] >>> c1,c2,c3 = map(m.browse,[1,2,3]) >>> c2.parent_id = False >>> c3.parent_id = False >>> c1.parent_id = c2 >>> (c3|c2).parent_id = c1 # this never ends ``` With current patch the call to `_check_recursion` successfully detects the new cycle. closes #151294 Signed-off-by: Raphael Collet <rco@odoo.com>
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.
Upgrade with version 11