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

Odoo 15 - Context not being passed to Many2one field #82366

Closed
FredericoCoelhoNunes opened this issue Jan 7, 2022 · 14 comments
Closed

Odoo 15 - Context not being passed to Many2one field #82366

FredericoCoelhoNunes opened this issue Jan 7, 2022 · 14 comments

Comments

@FredericoCoelhoNunes
Copy link

FredericoCoelhoNunes commented Jan 7, 2022

Impacted versions: 15

Steps to reproduce:

  • create a project model
  • create an account model
  • create a one2many relationship from account to project (an account has multiple projects)
  • create a many2one relationship from project to account (a project is associated with 1 account)
  • create a budget field (float) on project, for illustrative reasons
  • create a form view for project, and place the budget and account fields there
  • create a form view for account, and place the projects (one2many) field there
  • pass context to the projects field, for a default value of budget and account: context="{'default_budget': 10, 'default_account': active_id}" as such:
    image

Current behavior:

Context is only passed to the budget field:
image

even though the context dictionary is set:
image

Expected behavior:

The account field should be pre-filled with the right account.

Video/Screenshot link (optional):

Support ticket number submitted via odoo.com/help (optional):

@gdgellatly
Copy link
Contributor

Why are you even passing it or showing it in the one2many form view?

One2many will automatically get the id of the account. It makes no sense to default it because if you changed it you couldn't save it. There are hundreds of working examples in the code. When you save it vals will be something like {'projects': [(0, 0, {'budget': 10}]} and written on account.

@FredericoCoelhoNunes
Copy link
Author

@gdgellatly thanks for your reply. I simply want to display it there for a user experience perspective, so that it's always very obvious what info is being input. Preferably, I wouldn't want to omit any information from the form views.

Alternatively I could also have two form views: one for when the Project is created individually (from the "root"), and another one from when the project is created through an Account, but that will led to a bit of code bloat if I do it for every single pair of related models in my application. This is the main reason why I want to show my Many2one fields - homogeneity.

Thanks.

@JDSalcedo
Copy link

It doesn't work even if you catch the variable from context in a default_get method it won't set it. I think the old way is the proper way.

@angelramirezisea
Copy link

I had to use this dirty hack:

@api.onchange('account')
def wtf(self):
    self.account = int(str(self.account.id).replace('NewId_', ''))

@denris
Copy link

denris commented Sep 8, 2022

Why are you even passing it or showing it in the one2many form view?

One2many will automatically get the id of the account. It makes no sense to default it because if you changed it you couldn't save it. There are hundreds of working examples in the code. When you save it vals will be something like {'projects': [(0, 0, {'budget': 10}]} and written on account.

Yes, you are correct that it will automatically get the id, but it only gets it after the record is saved. The problem with that is that I want things domained off the value of the parent record (record it is getting created from), and since the default value does not get set till the record is saved, it does not domain the other field(s).

I am also having this issue in V14, we recently migrated to 14 from V12 and it worked as expected (outlined above) in V12.

@gdgellatly
Copy link
Contributor

Isn't that what parent is for?

@denris
Copy link

denris commented Sep 21, 2022

Isn't that what parent is for?

So I am only coming from mostly having worked in v12 so maybe it has changed since v12, but in v12 parent was only used in embedded views (eg. tree view embedded in a form view) to refer to something from the main form view, but active_id was used to pass the context of the default values to the child view (occasionally that was even wrong if you were too far into nested records...IOW the active_id would not be the expected parent record and I was using plain id to get around that).

image
(the above screenshot is base odoo 14 CE codebase...so they clearly still seem to use active_id, at least in some cases)

What's strange is I can pass the default values for any other many2one fields on the child from, but not the parent many2one (even the id trick didn't get me anywhere). Definitely feels like a bug to me.

@Yenthe666 do you have any input on whether this is a bug or if there is a new way since v12 to pass default parent many2one value to a child view?

@gdgellatly
Copy link
Contributor

Yes, I've faced similar problems. In fact have one on a project at the moment, where really my only out has been to pass the parent id via a button on an editable tree view to pop the form. But the UX is clunky as. I've tried flushes all sorts before popping to try and make clean. I'm almost at point where actually I'm just going to hide the fields until the record is saved.

But I seem to recall in product.supplierinfo it does handle the case of the same form being popped from both templates and products.

@litmount
Copy link

litmount commented Nov 10, 2022

Hello, Is there any way to get this bug more exposure? It is causing major headaches with our modules that use to work on V12 and now don't work anymore. It's hard to believe that more people are not affected by this issue.

Edit:
I also noticed this post confirming the issue seems to have changed after version 13
https://www.odoo.com/forum/help-1/passing-context-to-a-tree-view-field-inside-a-form-view-178972

@ray-odoo @Yenthe666

@litmount
Copy link

This seems to be related:
##81508

@Yenthe666
Copy link
Collaborator

Make an official ticket through odoo.com/help honestly. Odoo does not care about publicly reported issues..

@litmount
Copy link

Make an official ticket through odoo.com/help honestly. Odoo does not care about publicly reported issues..

Thanks @Yenthe666 for the response. I did officially make a ticket on 11/11/22 ticket #3064991. I will see what they say.
Kind of a shame to hear that odoo doesn't take publicly reported bugs seriously.

@bouvyd
Copy link
Contributor

bouvyd commented Jan 3, 2023

Hi,

This is not a bug - default_ values are removed from the context in the create and write methods when traversing relational fields (check the method clean_context in models.py) - this has been the case for years (normally well before v11). This is by design, as in the past we had way too many context values like default_user_ir or default_partner_id wandering about in the whole call stack and causing issues by impacting different models than what was intended by the developer. I suspect the code observed in survey was either non-functional or was augmented by python code somewhere, because it shouldn't have worked as-is.

It is indeed not possible to pass default values for relational objects that way; you'll need to use specific context override (not prefixed by default) and handle them manually at the correct places if you want this behaviour.

To bypass this, you can simply use a context key of your choosing (e.g. custom_default_something instead of default_something) and handle it in the default_get of your target model (for example).

@bouvyd bouvyd closed this as completed Jan 3, 2023
@denris
Copy link

denris commented Jan 3, 2023

Thanks so much for your reply @bouvyd . However that does not completely make sense, please see this attached example on the runbot of v14. You can see that in an embedded tree view, the product variants are domain-ed correctly off the current product template. As soon as I simply remove the tree_view_ref so that it shows a pop up form instead (which is what the examples above were using), the domain stops working for the product variants. Can you explain to me why the tree view works, but not the form view?

You say this has been the case since before even v11, but it has worked in v12 for me in 2 separate companies (one running community version and the other enterprise). And in both companies, we used the default_ in many places throughout our codebases.

I greatly appreciate your time! (you can also see the Odoo ticket mentioned above #3064991 for more details)

ctx_error.mp4

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

No branches or pull requests

8 participants