Re: [Django] #33892: Management commands with flags using "store_false" create inverted boolean flags in call_command

[Django]

#33892: Management commands with flags using "store_false" create inverted boolean
flags in call_command
-------------------------------------+-------------------------------------
Reporter: Luke Wiwatowski | Owner: nobody
Type: Bug | Status: closed
Component: Core (Management | Version: 4.0
commands) |
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Luke Wiwatowski:

Old description:

> In any management command which parses a flag using the action
> `store_false` it has an unexpected side effect when calling the
> management command from the `call_command` function. When `call_command`
> parses the arg it won't be taken into account the action and can create
> weird inversions of the intent of the boolean.
>
> **example:**
>
> from the command line this will work fine:
>
> {{{
> ./manage.py flush --no-input
> }}}
>
> However if called from the `call_command` with one of the recommended
> ways we might expect `no_input=True` to work the same but it doesn't.
>
> {{{
> from django.core.management import call_command
>
> call_command("flush", no_input=True)
>
> You have requested a flush of the database.
> This will IRREVERSIBLY DESTROY all data currently in the ":memory:"
> database,
> and return each table to an empty state.
> Are you sure you want to do this?
>
> Type 'yes' to continue, or 'no' to cancel:
>
> call_command("flush", no_input=False) # This will continue with no input
> required
> }}}
>
> I'm not sure how widespread this is but `flush` is definitely affected

New description:

In any management command which parses a flag using the action
`store_false` it has an unexpected side effect when calling the management
command from the `call_command` function. When `call_command` parses the
arg it won't be taken into account the action and can create weird
inversions of the intent of the boolean. **This is only relevant to
options inputs via keyword arguments, string args work as excpected.**

**example:**

from the command line this will work fine:

{{{
./manage.py flush --no-input
}}}

However if called from the `call_command` with one of the recommended ways
we might expect `no_input=True` to work the same but it doesn't.

{{{
from django.core.management import call_command

call_command("flush", no_input=True)

You have requested a flush of the database.
This will IRREVERSIBLY DESTROY all data currently in the ":memory:"
database,
and return each table to an empty state.
Are you sure you want to do this?

Type 'yes' to continue, or 'no' to cancel:

call_command("flush", no_input=False) # This will continue with no input
required
}}}

I'm not sure how widespread this is but `flush` is definitely affected

--

--
Ticket URL: <https://code.djangoproject.com/ticket/33892#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.