Wrong interpretation of extra clause in ModelAdmin with new admin UI
|Reported by:||Florian Apolloner||Owned by:||Jannis Leidel|
|Severity:||Keywords:||admin, js, inlines|
|Cc:||Jannis Leidel, Florian Apolloner||Triage Stage:||Accepted|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Description (last modified by )
In the current admin you can specify max_num and extra for inlines. Before r12297 this meant that you would get the current data from the database +
extra as long as it stays below
max_num. If you were still below
max_num you had to save the page to get
extra new fields (this could be repeated until you reached the limit). This behaviour is currently implemented with the js too; but I think (as js is a usability enchancement) you should be able to add as many rows until you reach
max_num not TOTAL-FORMS (which is rows+
extra while <= max_num). To get this working I guess we would need to pass max_num to the js so it can decide when to stop.
An alternate description from #12704:
The current code interprets 'extra = N' as "allow the user to add no more than N extra rows. The user must press (+ add another XXX) to add the first inline.
I would have thought the interpretation would have been "instantiate the form with with N empty extra rows". The task of constraining the number of allowed inlines is the job of the 'max_num' clause.
The admin UI should always show N blank inputs (for extra = N), as long as that wouldn't exceed the max_num. The user should be able to fill in up to N inlines before needing to press the (+ add another) button.
If I'm incorrect, then the second failing test reported by #12703 needs to be fixed by accounting for the 5 fields (and missing default date) that are no longer on the form.
Change History (10)
comment:1 Changed 7 years ago by
|Summary:||shortcoming in the new admin inlines → Wrong interpretation of extra clause in ModelAdmin with new admin UI|
|Triage Stage:||Unreviewed → Design decision needed|