-
-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[18.0][MIG] server_action_mass_edit: Migration to 18.0 #951
base: 18.0
Are you sure you want to change the base?
Conversation
29381ab
to
0f93b99
Compare
/ocabot migration server_action_mass_edit |
@trisdoan Hi! I tested the module but it didn't worked. This are the last lines of the error: |
0f93b99
to
7399b98
Compare
Hi @florenciafrigieri2, thank you for the review I just added a fix, could you please try again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the error mentioned by @florenciafrigieri2 anymore, but I am not familiar with this module !
Code review looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of minor comments
|
||
@common.tagged("-at_install", "post_install") | ||
class TestMassEditing(common.TransactionCase): | ||
def setUp(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would setUpClass
work for the common test setup to avoid running the setup separately for each test case?
def test_wiz_fields_view_get(self): | ||
"""Test whether fields_view_get method returns arch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def test_wiz_fields_view_get(self): | |
"""Test whether fields_view_get method returns arch. | |
def test_wiz_get_view(self): | |
"""Test whether get_view method returns arch. |
return vals_list | ||
|
||
def read(self, fields=None, load="_classic_read"): | ||
"""Without this call, dynamic fields build by fields_view_get() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"""Without this call, dynamic fields build by fields_view_get() | |
"""Without this call, dynamic fields build by get_view() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functional test! Now is working ok!
This PR has the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See @stefsava comment.
Hello @stefsava, I checked and it looks to me that the issue is not because of the module |
Hello @trisdoan your suggestion doesn't solve my use case. If I change create='true' I can see "Add a row", but the choice doesn't lead to anything useful. Instead I found a workaround that brings the behavior back to that of 17.0 that I think can help you understand the problem detected. I discovered that 17.0 only has the view "product.template.attribute.line.form" while My workaround was simply to deactive the list view, although I fear it may introduce regressions elsewhere. |
87e31a4
to
6b8dca7
Compare
|
…avoid incompatibilities with data from those users.
Currently translated at 100.0% (43 of 43 strings) Translation: server-ux-16.0/server-ux-16.0-server_action_mass_edit Translate-URL: https://translation.odoo-community.org/projects/server-ux-16-0/server-ux-16-0-server_action_mass_edit/tr/
Currently translated at 100.0% (44 of 44 strings) Translation: server-ux-17.0/server-ux-17.0-server_action_mass_edit Translate-URL: https://translation.odoo-community.org/projects/server-ux-17-0/server-ux-17-0-server_action_mass_edit/it/
add pre-init-hook
6b8dca7
to
f88d10f
Compare
Hi, I updated the code to include a pre-hook which handles the renaming (benefit those who use the addon in 14.0 and now migrate to 18.0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionnal review OK
Thanks for the mig. |
As said already in the other PR, that should be a different module, not integrated in this one. And even more in these recent versions, where onchanges are rare, as most of them have been replaced by computed writable fields. |
As @grindtildeath, I'm also in favor of the integration of #963 in V18.
Thanks ! |
The module is there for 10 versions, and now it's a critical problem to not play onchanges. Come on... |
My 2 cents. Odoo is deprecating the use of onchange. If you see numbers, on 15, we had 513 onchange and 1645 depends on odoo core code. On 18, we have 461 onchange and 2935 depends. I think we shouldn't add this code and leave it on another module, the cost is minimal and if we check numbers, odoo is removing onchange for depends because we can. I would recommend to remove onchange on most of the modules we create if possible. |
I'm in favor too in #963 integration.
In fact, I think I see the behavior expected by @pedrobaeza. This module was used to mass edit fields without touching any other value in the record or elsewhere. A kind of database editor. Stop me if I'm wrong. BUT:
So, I think saying a misbehavior present for several versions is not a bug is not correct. As said before, maybe nobody saw that problem... @pedrobaeza So, you rely on compute methods code and not in onchanges one ? That's weird. IMHO, we should improve modules behavior when we can. When Odoo remove all onchanges, we will remove it.
@etobella Of course, this should maybe added in contribution guidelines. Concerning the numbers, I would say if there is only 1 onchange, that code should be still applicable. |
Yes, onchanges are designed for changes in UI during the manual manipulation of the record, relying also in view features like readonly or non existing fields for its behavior. Computed methods, on contrary, are designed to work in a view-agnostic mode, and are more confident. Executing onchanges in a wild mode doing mass editions can lead to unexpected behaviors. And anyway, the same you have the module Please stop wasting the time of all the good contributors involved in this discussion while there's a solution that fits all, although you consider it a bug. The bug is solved installing the module in all your instances. |
According to Odoo documentation: Odoo is not recommending onchange. So, I do not recommend to add this functionality here because it might be a problem later. |
Which one and where?
I suppose I'm on the other side
I thought @grindtildeath @simahawk @legalsylvain @mmequignon were not in that way. But maybe I'm wrong |
Seriously? You are the one saying that it's a bug to not play onchanges. So the bug is solved creating the glue module and installing it. |
Ok, don't be harsh, I've just reread the comments and some people stil say (or never said the contrary) that this is a bug:
They were the basis for my questioning. |
Why forcing those that are totally against this "bugfix" to have it, even only in the new version? If there's no other solution, I understand that this debate makes sense, but the simpler solution to avoid the debate is to have that extra module. We are not saying that is forbidden to have it on OCA. We are just asking to not integrate it in the base module. |
No. I read the text of your link (https://www.odoo.com/documentation/16.0/developer/tutorials/getting_started/09_compute_onchange.html?highlight=onchange) and there is no section about deprecation or about "obsolete feature that should not be used in the futur". Just explanation about pro and cons. I remember clearly an answer of Odoo SA developper, during a recent Odoo experience, saying that both tools remain valid. V12 : 504 onchanges / 638 depends I don't see any massive withdrawal of onchange to make it disappear. On the other hand, there is a more massive use of the depends function. Between V12 and V18, onchange : -9% ; depends : +360% regards.
@rousseldenis : As mentioned in this long comment, Odoo SA developpers says it's a bug also ;-) (in fact Odoo prohibits mass edition on fields if there are onchange on it : see commit message and diff : odoo/odoo@14198a2#diff-4c25e9b1afc64d76fd27b33de1bc39a16b8b79fc254f21ab350e51b7deae9b02R40) |
I agree we should prefer compute to onchange but IMO this discussion is missing the point. Basically, we went from "do not introduce this in a stable version" to "do not introduce that because I don't want it" ... FWIW my patch is adding a bugfix (or a feature if you prefer) that is opt-in and won't change anything if someone does not want to use it. The only drawback being an added dependency on a module that is not in the same repository but is still in the OCA, to avoid repeating code. But I guess I'm just a bad contributor wanting to waste the time of the good ones... |
You are a good contributor, but stucked on imposing to some other good contributors something they don't want, like it's depending on other module. The solution for all is the extra module. Put if you want in the README of the base module that there's the glue module for the onchange case, but don't force people to install P.S.: I have never said to put it on the migration. I oppose to the dependency change in any version. |
Please Pedro. The main question is : "is it a mistake not to execute the onchange ?" If the answer is yes, propose to make an extra module, and write in the readme of the first module "There is a bug in this module, but you can fix it installing another module" doesn't makes sense. For the time being,
|
There are also a lot of persons not wanting to put this dependency. Why the people wanting to put it worth more than the one not wanting? And more having a solution for all, which is the extra module. |
Note