The proposed patch adds very little extra API surface. Django admin in fact
already support this, but for this arbitrary restriction in
`get_ordering_field`. The patch just makes it possible to pass a list down
to `get_queryset` method.
I would argue that this patch removes a special case in
Having a 5 seconds “forbidden window” could be bad UX for users with password
managers (like LastPass, or even just Apple’s built-in whatever-they-call-it
fingerprint-scanning password autofill). It often takes about a second to
submit the login form in such cases.
Maybe 1 second interval
I ran into this same issue last week. That ticket raises a valid question IMHO:
why even save permission descriptions in the DB?
Anyone seeing any downsides of the proposed approach to fetch the descriptions
from code (and apply translation on the fly)?
Fran
> On 22.05.2021., at 02:08,
> On 10.03.2021., at 13:06, Mariusz Felisiak wrote:
>
>> I suggest we add the flag as "--random" taking an integer that is the seed,
>> or 0 to disable.
>
> This kind of APIs are always confusing. Moreover I don't think that changing
> the current behavior is a good idea, it should be opt-in
I would love to get only one line of output when running `collectstatic`
command with `-v1`. This is actually so, except when using `--clear`
option. With it I still get hundreds of lines of output similar to:
Deleting 'admin/img/icon-calendar.svg'
There seemed to be a consensus about this,
Personally I would prefer to get a ProgrammingError, so option 3.
Explicit is better then implicit
Here is a great explanation of this exact issue, cleared it up for me:
https://blog.jooq.org/2018/07/13/how-sql-distinct-and-order-by-are-related/
> On 28.10.2020., at 20:04, Tobias McNulty
I believe the behaviour you're seeing is due to the fact that the admin
view first has to save the instance of the model being edited, and only
then can it save the related objects and relationships. So it is a two-step
thing:
Just my $.02, literally yesterday I saw a str(queryset.query) used to construct
a raw SQL query. It of course suffers from the worst kind of SQL injection as
well.
+1 to make it obvious, somehow, that kittens die every time it is used for a
real query.
>> On 11 Sep 2020, at 15:58, Alexander
Meaning "owner of slaves" is only one of many meanings of the word, and not
its primary meaning:
https://dictionary.cambridge.org/dictionary/english/master
https://www.merriam-webster.com/dictionary/master
Renaming the master branch would mean we agree that this one meaning is
somehow more
On Wed, 6 May 2020 at 17:49, Adam Johnson wrote:
> +1 request.data
>>
>> We shouldn’t be POSTists, there is also PUT and PATCH.
>>
>
> Would just like to point out - that's not the proposal. The proposal is to
> rename the existing request.POST to request.form_data, which is based on
> parsing
+1 request.query_params
If request.method == "POST":
thing = request.GET.get("thing")
That’s just silly.
+1 request.data
We shouldn’t be POSTists, there is also PUT and PATCH.
And apparently GET requests can also have a body:
+1 on the proposed changes.
Very little extra complexity for something useful.
Would it be more future-proof if the second param was a dict like {“title”:
“Related Tag”}? Maybe, not sure. KISS, YAGNI and all that? I could get
behind either choice.
I would love for this to also work:
class
I’ve been in both situations more than once:
1. wanting to just run makemigrations and never look back,
2. naming each migration and reminding people to do the same.
Small teams / solo = 1, Large teams = 2.
Perhaps a new setting?
AUTO_NAME_MIGRATIONS = None # makemigrations fails if no
If I’m understanding correctly, the difference between `makemigrations
--check` and your use case is that one checks if we need to *create* any
migrations while the other checks (or would check) if we need to *run* any
migrations.
Seems reasonable to me. Although I would prefer we just add a
I think this might be the discussion which Aymeric referenced:
https://groups.google.com/forum/m/?utm_medium=email_source=footer#!searchin/django-developers/Mongo$20orm/django-developers/N6WOdGGfmWk
It certainly looks like the idea won’t be easily accepted. Unless something has
changed in the
We can message the user by calling
self.message_user(
request,
“This is a waaarning...",
messages.WARNING,
)
form within a ModelAdmin. This works for success level (default green message),
warning level and error level. I was also expecting it to support “info” level
with a blue
Just a quick note: issues that have an owner but weren’t updated in a
reasonably long time are usually open for taking. It is probably polite to
ask the owner first, because maybe they just resumed working on the issue
yesterday :) What is “reasonably long time” is probably open to
interpretation,
A similar ticket from 6 years ago (with some more filters) was closed as a
wontfix: https://code.djangoproject.com/ticket/22162
Unless there was a change in the phylosiphy, I don’t think this will be
accepted either (I don’t have an opinion about whether it shouldbe, though
leaning towards
FWIW, for me the question here is why isn't Django applying the same
protection agains enumeration attacks on sign-up pages?
On Thursday, 9 January 2020 02:08:16 UTC+1, SANYAM MITTAL wrote:
>
> PasswordResetView returns a success message for emails not in database
> also.
>
> *Problems Faced*
Just skimming this mailing list occasionally, I find pretty comical all
those "I think you found the wrong mailing list" replies. Not that there is
anything wrong with that, what else can one do? Just imho any new
communication channel should have a way of moving messages to a correct
place. Maybe
20 matches
Mail list logo
