URL arguments to set values of fields in admin don't work for inlines

[josh@…]

Though it works just fine to set the value of a field in the admin with URL arguments (i.e. adding '?title=foo' to your URL sets the value of the field 'title' to 'foo'), this doesn't work if the field you're trying to set is in an inline. In such a case the syntax would presumably be something along the lines of '?inlinemode_set-0-fieldname' if you were trying to set the value fo the first instance of the inline model. This, however, doesn't work nor does any other variation I was able to think of.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[TapanGujjar]

For this feature, the correct query parameter for inline models according to me should look something as inlinemode_set-[inline model index]-[index of the inline model form in the inline formset]-[fieldname]. Also, should the inline parameters override the extra parameter in the custom inline Model as if we have more inline query parameters means for the inline model we will have to show more inline form just to show those more query parameters?

for e.g.

class choiceInline(admin.TabularInline):
    model=Choice
    extra=2
    # exclude=['votes']

class QuestionAdmin(admin.ModelAdmin):
    fieldsets = [
        (None,               {'fields': ['question_text']}),
        ('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}),
    ]    
    inlines=[choiceInline]

query parameter can be like
inlinemode_set-0-0-choiceModelField where the first 0 points to the first element in the inlines array (choiceInline) and the second 0 is the first form in inline formset.

The issue here is that if the query parameter is inlinemode_set-0-3-choiceModelField , this points to the 4th form in the choiceinline formset, this will need to override the extra parameter.

Should we override the extra parameter through the query parameter?
Any ideas for this.

[Carlton Gibson]

Any ideas for this.

Easier to see in code, I think.

After 12 years, you're free to implement your idea. (It sounds generally reasonable.)

If you can open a PR with the easier cases handled and then perhaps failing test cases for the more difficult examples it will be easier to comment sensibly.
Does that seems an OK plan?

[TapanGujjar]

Hi Carlton please check the pull request for this. I have created two tests to demonstrate my solutions. One of the test will fail.

​https://github.com/django/django/pull/12882