[Django] #20649: unable to override the blank option '--------' in django admin in charfield with choices
Django
with choices
-------------------------------+--------------------
Reporter: brillgen | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 1.5
Severity: Normal | Keywords: admin
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
CHAR_FIELD_CHOICES = (('', "Empty Choice"), ('S', "Non Empty Choice"))
char_field = models.CharField(blank=True, default='', max_length=1,
choices=CHAR_FIELD_CHOICES)
Expected:
<select id="id_char_field" name="char_field">
<option value="" selected="selected">Confirmed</option>
<option value="P">Provisional</option>
</select>
Actual Output:
<select id="id_category" name="category">
<option value="" selected="selected">---------</option>
<option value="">Confirmed</option>
<option value="P">Provisional</option>
</select>
--
Ticket URL: <https://code.djangoproject.com/ticket/20649>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
with choices
Reporter: brillgen | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 1.5
Severity: Normal | Resolution: worksforme
Keywords: admin | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by wim@…):
* status: new => closed
* needs_docs: => 0
* resolution: => worksforme
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
Hi, if you use blank=False in your Charfield definition, the blank option
will not show.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:1>
Django
with choices
Reporter: brillgen | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 1.5
Keywords: admin | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by brillgen):
* status: closed => new
* resolution: worksforme =>
Comment:
That is correct. However I have an option which is blank (please see
example above). blank=False does not allow that option to be selected,
saying that this field is required.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:2>
Django
-----------------------------+------------------------------------
Reporter: brillgen | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* cc: timograham@… (added)
* component: Uncategorized => Forms
* version: 1.5 => master
* keywords: admin =>
* type: Bug => New feature
* stage: Unreviewed => Accepted
Comment:
I wouldn't consider this a bug, but rather a new feature request.
`BaseModelAdmin.formfield_for_choice_field` has an example of calling
`db_field.get_choices` which allows customizing the blank option, but this
is probably not a public API at this point.
Accepting on the basis that an easier way to customize the blank choice
would be helpful (or documenting it if one already exists that I'm not
thinking of). Adding an `empty_label` argument to a `CharField` with
`choices` may be a possible approach.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:3>
Django
-----------------------------+-------------------------------------
Reporter: brillgen | Owner: anonymous
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Alex Couper <info@…>):
* status: new => assigned
* owner: nobody => anonymous
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:4>
Django
-----------------------------+-------------------------------------
Reporter: brillgen | Owner: anonymous
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by brillgen):
IMHO, its a bug because the documentation for choices does not say
anywhere that the blank is a special case etc. While designing a solution,
I would also suggest that you keep in mind this use case (we're not
affected by this one yet)
For a Nullable char field with choices, the select options created should
be as below:
Null should be represented lets say by the default --------- (and
overridable)
"" should also be represented lets say by the default "" (and overridable)
<....remaining options...>
These are all database valid options which should be possible. How its
done keeping backward compatibility is why you guys chose to be the core
team :)
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:5>
Django
-----------------------------+-------------------------------------
Reporter: brillgen | Owner: anonymous
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Alex Couper <info@…>):
I am implementing an API change for CharFields with choices such that an
empty_label can be specified.
{{{#!python
CHOICES = (
('p', 'Python'),
('j', 'Java')
)
class DummyModel(models.Model):
language = models.CharField(choices=CHOICES, blank=True, max_length=2,
empty_label="Please select one")
}}}
Which would result in
{{{
<p><label for="id_language">Language:</label> <select id="id_language"
name="language">
<option value="" selected="selected">Please select one</option>
<option value="p">Python</option>
<option value="j">Java</option>
</select></p>
}}}
I'd be interested to hear of a use case where you would want to tell the
difference between a null and a blank string on a choice field.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:6>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by alexcouper):
* owner: anonymous => alexcouper
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:7>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by alexcouper):
I have submitted a PR to attempt to address this problem, using my
understanding of what timo suggested.
https://github.com/django/django/pull/1315
I have a slight concern that we are breaking MVC somewhat, in that we're
defining presentation properties on the model as a matter of convenience.
Although having said that, we already do that somewhat with choices, so
perhaps this is seen as OK.
As this is my first contribution to Django, I thought it would be a good
idea to get feedback at this point before making any documentation
changes.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:8>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by alexcouper):
* cc: info@… (added)
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:9>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by alexcouper):
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:10>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
On second thought, rather than `empty_label`, how about doing what the OP
did and just making sure that the Django blank choice isn't added if a
blank choice is already defined in `choices`?:
{{{
CHOICES = (
('', 'Please select one'),
('p', 'Python'),
('j', 'Java')
)
}}}
Opinions?
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:11>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
@timo I also think it would make more sense than an `empty_label` option
however both alternatives introduce a form specific option at the ORM
level.
IMHO this belongs at the form level.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:12>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
@timo I see that most of the choice logic is unfortunately already defined
at the db field level thus you can ignore my last concern.
You suggested approach should work and is way less invasive.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:13>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by alexcouper):
@timo - I prefer that approach too.
The {{{empty_label}}} option felt wrong while I was implementing it TBH.
I'll be away for the next week or so but after that I'll amend my fix
(unless I'm beaten to it by someone else).
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:14>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by alexcouper):
I have managed to find some time to give the new solution a go.
Let me know if you've got any questions about it. It's on this PR:
https://github.com/django/django/pull/1383
*holds breath*
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:15>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Easy pickings: 0 | UI/UX: 0
Comment (by brillgen):
I'm not core or reviewing the patch (just the reporter) but it looks good
(without having tested the codebase though ...)
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:16>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by alexcouper):
* needs_docs: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:17>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Updated title to reflect that the fact that this isn't specific to
CharField but works for any field that defines choices.
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:18>
Django
-----------------------------+--------------------------------------
Reporter: brillgen | Owner: alexcouper
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"1123f4551158b7fc65d3bd88c375a4517dcd0720"]:
{{{
#!CommitTicketReference repository=""
revision="1123f4551158b7fc65d3bd88c375a4517dcd0720"
Fixed #20649 -- Allowed blank field display to be defined in the initial
list of choices.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/20649#comment:19>