Skip to content
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

Open
wants to merge 27 commits into
base: 18.0
Choose a base branch
from

Conversation

trisdoan
Copy link

@trisdoan trisdoan commented Oct 10, 2024

@trisdoan trisdoan force-pushed the 18.0-mig-server_action_mass_edit branch from 29381ab to 0f93b99 Compare October 10, 2024 02:43
@pedrobaeza
Copy link
Member

/ocabot migration server_action_mass_edit

@florenciafrigieri2
Copy link

@trisdoan Hi! I tested the module but it didn't worked.
I created a server action to change the salesperson in the SOs, but when selecting the action within sales an error came up (I was not able to even see the wizard).

This are the last lines of the error:
File "/mnt/data/odoo-addons-dir/server_action_mass_edit/wizard/mass_editing_wizard.py", line 93, in onchange
dynamic_fields["selection__" + line.field_id.name] = fields.Selection(
File "/opt/odoo/odoo/fields.py", line 2772, in init
self._selection = dict(selection) if isinstance(selection, list) else None
ValueError: dictionary update sequence element #0 has length 0; 2 is required

I leave here a print of the server action
testserveraction

@trisdoan trisdoan force-pushed the 18.0-mig-server_action_mass_edit branch from 0f93b99 to 7399b98 Compare October 18, 2024 08:45
@trisdoan
Copy link
Author

@trisdoan Hi! I tested the module but it didn't worked. I created a server action to change the salesperson in the SOs, but when selecting the action within sales an error came up (I was not able to even see the wizard).

This are the last lines of the error: File "/mnt/data/odoo-addons-dir/server_action_mass_edit/wizard/mass_editing_wizard.py", line 93, in onchange dynamic_fields["selection__" + line.field_id.name] = fields.Selection( File "/opt/odoo/odoo/fields.py", line 2772, in init self._selection = dict(selection) if isinstance(selection, list) else None ValueError: dictionary update sequence element #0 has length 0; 2 is required

I leave here a print of the server action testserveraction

Hi @florenciafrigieri2, thank you for the review

I just added a fix, could you please try again?

Copy link
Member

@TDu TDu left a 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.

Copy link

@henrybackman henrybackman left a 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):

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?

Comment on lines +132 to +133
def test_wiz_fields_view_get(self):
"""Test whether fields_view_get method returns arch.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"""Without this call, dynamic fields build by fields_view_get()
"""Without this call, dynamic fields build by get_view()

Copy link

@florenciafrigieri2 florenciafrigieri2 left a 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!

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@stefsava
Copy link

It seems like there is a regression.
I can't bulk insert product attributes, while I could do it in 17.0.

Before it asked me to add a line,
now it doesn't ask and there are multiple columns.

With 17.0
image
image

With 18.0 and this PR
image
image

Copy link
Contributor

@legalsylvain legalsylvain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See @stefsava comment.

@trisdoan
Copy link
Author

trisdoan commented Nov 7, 2024

Hello @stefsava, I checked and it looks to me that the issue is not because of the module

  1. I tried with different o2m fields in another model
    server_mass_action_edit

  2. For product attribute, after https://github.com/odoo/odoo/pull/160270, there is a list view created and it has attribute create='false'. I changed to create='true' (for testing only), here's result:
    server_mass_action_edit_2

@stefsava
Copy link

stefsava commented Nov 7, 2024

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
18.0 has added "product.template.attribute.line.view.list", and for some reason that I don't understand the list view is chosen instead of the form view.

My workaround was simply to deactive the list view, although I fear it may introduce regressions elsewhere.

image

@trisdoan trisdoan force-pushed the 18.0-mig-server_action_mass_edit branch 3 times, most recently from 87e31a4 to 6b8dca7 Compare November 29, 2024 05:11
@trisdoan trisdoan marked this pull request as draft November 29, 2024 05:15
@trisdoan
Copy link
Author

trisdoan commented Nov 29, 2024

DRAFT: working on failed test

@trisdoan trisdoan force-pushed the 18.0-mig-server_action_mass_edit branch from 6b8dca7 to f88d10f Compare December 9, 2024 04:58
@trisdoan trisdoan marked this pull request as ready for review December 9, 2024 04:58
@trisdoan
Copy link
Author

trisdoan commented Dec 9, 2024

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)

Copy link

@PaulGoubert PaulGoubert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionnal review OK

@grindtildeath
Copy link
Contributor

Thanks for the mig.
While we are at it, can we please bring #963 in the new version? 🙏

cc @etobella @pedrobaeza @legalsylvain

@pedrobaeza
Copy link
Member

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.

@legalsylvain
Copy link
Contributor

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 !

@pedrobaeza
Copy link
Member

The module is there for 10 versions, and now it's a critical problem to not play onchanges. Come on...

@etobella
Copy link
Member

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.

@rousseldenis
Copy link
Contributor

I'm in favor too in #963 integration.

The module is there for 10 versions, and now it's a critical problem to not play onchanges. Come on...

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:

  • That behavior is not documented in README. So, people are expecting the changes to automatically change the other values like in any other Odoo flow.
  • Current users are maybe not aware that their changes do not impact other fields (the remaining onchanges ones).

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.

I would recommend to remove onchange on most of the modules we create if possible.

@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.

@pedrobaeza
Copy link
Member

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 sale_crm as a glue module between sale and crm, you must have server_action_mass_edit_onchange for the same, and make it optional for people.

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.

@etobella
Copy link
Member

According to Odoo documentation:
https://www.odoo.com/documentation/16.0/developer/tutorials/getting_started/09_compute_onchange.html?highlight=onchange

Odoo is not recommending onchange. So, I do not recommend to add this functionality here because it might be a problem later.

@rousseldenis
Copy link
Contributor

The bug is solved installing the module in all your instances.

Which one and where?

Please stop wasting the time of all the good contributors

I suppose I'm on the other side

here's a solution that fits all,

I thought @grindtildeath @simahawk @legalsylvain @mmequignon were not in that way. But maybe I'm wrong

@pedrobaeza
Copy link
Member

Which one and where?

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.

@rousseldenis
Copy link
Contributor

Which one and where?

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.

@pedrobaeza
Copy link
Member

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.

@legalsylvain
Copy link
Contributor

Odoo is deprecating the use of onchange.

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
V13 : 572 onchanges / 752 depends
V14 : 479 onchanges / 1258 depends
V15 : 507 onchanges / 1625 depends
V16 : 447 onchanges / 2168 depends
V17 : 452 onchanges / 2703 depends
V18 : 459 onchanges / 2934 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.

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.

@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)

@grindtildeath
Copy link
Contributor

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...

@pedrobaeza
Copy link
Member

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 onchange_helper on the base module.

P.S.: I have never said to put it on the migration. I oppose to the dependency change in any version.

@legalsylvain
Copy link
Contributor

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 onchange_helper on the base module.

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 more OCA contributors who think there's a mistake than who don't.
  • Odoo SA developers also think it's a mistake.
  1. I asked a question 2 monthes ago ("Provide a use case where applying onchange would be dangerous?"). I need an answer to change my mind. (except speed of execution that depends on the number of items and because there may also be performance problems with api.depends)

  2. When I explain in one sentence to my novice users what the mass editing wizard is for, I tell them that “it avoids the need to edit items one by one.”
    When you edit one by one, the onchange is executed.

@pedrobaeza
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.