> On 19 Jan 2019, at 11:48, Santiago Basulto wrote:
> Haha, sorry, got overly excited. What's the usual process to make these sort
> of decisions in these cases? Should we ask the users list?
No problem. :)
We make decisions here. Say you’d have opened a Trac ticket for this, I’d have
> For *my* (completely unilateral) point of view, this is very important and
> I'd love to have a place to just flip a switch and change them all; well,
> I'd even prefer for it to be the default behavior, but I know selects look
> cool too.
How many projects do you need this on? I think the
Haha, sorry, got overly excited. What's the usual process to make these
sort of decisions in these cases? Should we ask the users list?
The setting proposal is purely from my perspective as a user. For *my*
(completely unilateral) point of view, this is very important and I'd love
to have a
> On 18 Jan 2019, at 17:20, Santiago Basulto wrote:
> Seems like everybody agrees that for large sites, it's necessary.
Hang on, slow down.
Personally, I’m not sure it’s too onerous as-is. I’ve not yet seen exactly why
subclassing ModelAdmin in one’s project isn’t good enough. It really
@Harro, it does work if the field is not part of the admin. It doesn't add
the way to link it directly, but it does resolve the problem of prefetching
a list and building the large select field. Here's an quick
example: https://i.imgur.com/uNRPCK6.png (the Country field is a FK and
> > One problem with any of the alternatives (besides making it readonly by
default) is that it requires the other model to be registered in the admin
> Off-hand I don't follow you here. Can you explain.
I stand corrected. raw_id_fields doesn't actually require the other model
to be registered.
The problem is that you can't just use it everywhere, like mentioned
earlier it only works if the other side of the relation is also available
in the admin (which might not be the case, or only for some of the fields.)
I would say add it to the good old djangosnippets
If we were happy with that particular implementation, then I'd prefer
adding it as an official subclass thats importable for users rather than
just dumping the code to the docs. But I guess the issue is a slippery
slope - how many subclasses do we add for various ModelAdmin use cases.
Ok, sorry for the Fake News, seems like it's not so complicated to make one
ModelAdmin parent class that provides this behavior. Here's a working
from django.contrib import admin
from django.contrib.admin import widgets
I think the proposed solution of "you can just extend/subclass ModelAdmin"
doesn't work, because the fields on different models can have different
names. I can't just write one global ModelAdmin and then use it for all my
models, because they'll have different names for their fields. Or if it
On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
> One problem with any of the alternatives (besides making it readonly by
> default) is that it requires the other model to be registered in the admin
Off-hand I don't follow you here. Can you explain.
> I hope
I agree that default load-all-options is an annoying default. I just ran
into this problem again myself in the last few weeks. One problem with any
of the alternatives (besides making it readonly by default) is that it
requires the other model to be registered in the admin, which could be also
Django's admin default widget for foreign keys is a select. If you try to
populate a select elements with 20,000 options, your page take at least a
few seconds to load. Probably a minute or two, if it load at all.
By configuring your model admin to display the foreign key as a
This topic has come up before.
(In which Aymeric suggests something similar to Harro's suggestion here.)
On Thursday, 17 January 2019 06:32:15 UTC+1, Harro wrote:
> If you want it in your whole project you could
actually i am new to django i am not able to understand the problem which
ur dealing with?
On Thu, Jan 17, 2019 at 3:33 AM Santiago Basulto
> Hey folks, I was about to submit a ticket but i thought it might be better
> to ask everybody for opinions on the matter first. I am running a
How would the raw_id_fields then work? Would that then turn them into
selects again or would that be another setting?
If you want it in your whole project you could just extend the ModelAdmin
and make the raw_id_fields a property that returns all the fields then use
that as a base class for
Btw, for reference, not the only one with this problem:
On Wednesday, January 16, 2019 at 5:02:57 PM UTC-5, Santiago Basulto wrote:
> Hey folks, I was about to submit a ticket but
Mail list logo