Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
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 all your ModelAdmins,
looking at the code the check if it is a foreignkey happens before that in
all cases, so having non foreignkey fields in the list shouldn't matter.
On Wednesday, 16 January 2019 23:02:57 UTC+1, Santiago Basulto wrote:
>
> 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 couple of
> medium (not even large) Django websites (around +20K users) and we rely on
> the admin heavily. We have multiple models pointing to Users (or other
> derived models) and every time we create a new model, we MUST remember to
> include User in `raw_id_fields` for that model. If we forget to do so, the
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include
> in their `__str__` both the User + something else. Think about the model
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example.
> If you open the `Inquiry` add/change page on the admin, the whole thing
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on
> the admin when starting a new Django projects (specially for beginners),
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think?
>
> Thanks for all the support, this community rocks 🤘!
>
> PS: I can create a ticket if that's a better medium of discussion, just
> let me know?
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3d043e53-c8c5-4e14-a2d3-404164093625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
Btw, for reference, not the only one with this problem:
* https://twitter.com/mbrochh/status/1049209871583797248
* https://twitter.com/poswald/status/1072134086041300992
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 i thought it might be better
> to ask everybody for opinions on the matter first. I am running a couple of
> medium (not even large) Django websites (around +20K users) and we rely on
> the admin heavily. We have multiple models pointing to Users (or other
> derived models) and every time we create a new model, we MUST remember to
> include User in `raw_id_fields` for that model. If we forget to do so, the
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include
> in their `__str__` both the User + something else. Think about the model
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example.
> If you open the `Inquiry` add/change page on the admin, the whole thing
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on
> the admin when starting a new Django projects (specially for beginners),
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think?
>
> Thanks for all the support, this community rocks 🤘!
>
> PS: I can create a ticket if that's a better medium of discussion, just
> let me know?
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/007c1f0f-b5a2-493d-bfcf-6ea788870e68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
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 couple of
medium (not even large) Django websites (around +20K users) and we rely on
the admin heavily. We have multiple models pointing to Users (or other
derived models) and every time we create a new model, we MUST remember to
include User in `raw_id_fields` for that model. If we forget to do so, the
whole testing site crashes when the whole `SELECT * FROM User` query is run.
To add to the problem, some derived models (for example Customer) include
in their `__str__` both the User + something else. Think about the model
Customer in this way:
class Customer(models.Model):
user = models.ForeignKey(User)
plan = models.ForeignKey(Plan)
def __str__(self):
return f"{self.user} - {self.plan}"
(Not a real example, but to make the point)
Imagine any other model with an FK to Customer, an `Inquiry`, for example.
If you open the `Inquiry` add/change page on the admin, the whole thing
will blow up.
I know the related select field is an amazing feature, and looks slick on
the admin when starting a new Django projects (specially for beginners),
but it just doesn't scale for large websites.
*My proposal*
I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
[raw|select]` would work and help us (running a medium/large site) a lot.
What do you think?
Thanks for all the support, this community rocks 🤘!
PS: I can create a ticket if that's a better medium of discussion, just let
me know?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/5dae8b31-356c-45f3-b707-83b5ef33f396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: status of 2.2 release blockers
These features are in. We're planning to do the alpha release tomorrow. On Sunday, January 13, 2019 at 9:04:29 PM UTC-5, Tim Graham wrote: > > Time to kick off the progress tracker for the next major release! > > The 2.2 feature freeze is scheduled (according to > https://code.djangoproject.com/wiki/Version2.2Roadmap) for tomorrow, > January 14. Typically we've released the alpha a few days later to finish > up a few last minutes things. > > I have a few patches I want to finish reviewing: > > https://github.com/django/django/pull/10840 - Refs #28478 -- Adjusted > prevention of connections to disallowed databases. (regression fixes) > https://github.com/django/django/pull/10381 - Fixed #11154, #17904 and > #22270 -- Inconsistency with permissions for proxy models > https://github.com/django/django/pull/10171 - Fixed #20147 -- Added > HttpRequest.headers. > https://github.com/django/django/pull/8981 - Fixed #9475 -- allow add(), > create(), etc for m2m with through > > I guess Claude will also like to update translations catalogs as he did > for 2.1. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/88e869ca-5bd6-48d9-a569-094f7f397634%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave
Hey, I ran into this today. I am reusing the password reset views for user signup, so it affects me quite heavily :) No idea if it is going to be of any use, but I sent a report on https://www.apple.com/feedback/safari.html with links to your ticket and this discussion. I will try to get my hands on a Mac for further debugging soon. Cheers, René -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ad17bd8e-417b-4e6c-2ddc-322b3e59d0f6%40fleschenberg.net. For more options, visit https://groups.google.com/d/optout.
Re: status of 2.2 release blockers
Hi Vaclav, I think current status is "Still work to do" there, so not really... C. On Wednesday, 16 January 2019 17:52:17 UTC+1, Václav Řehák wrote: > > Hi, > > is it possible to get this fix included in 2.2? > > https://github.com/django/django/pull/10643 - Fixed #29915 -- Support > hyphens in UUIDField filtering > > Vaclav > > Dne pondělà 14. ledna 2019 3:04:29 UTC+1 Tim Graham napsal(a): >> >> Time to kick off the progress tracker for the next major release! >> >> The 2.2 feature freeze is scheduled (according to >> https://code.djangoproject.com/wiki/Version2.2Roadmap) for tomorrow, >> January 14. Typically we've released the alpha a few days later to finish >> up a few last minutes things. >> >> I have a few patches I want to finish reviewing: >> >> https://github.com/django/django/pull/10840 - Refs #28478 -- Adjusted >> prevention of connections to disallowed databases. (regression fixes) >> https://github.com/django/django/pull/10381 - Fixed #11154, #17904 and >> #22270 -- Inconsistency with permissions for proxy models >> https://github.com/django/django/pull/10171 - Fixed #20147 -- Added >> HttpRequest.headers. >> https://github.com/django/django/pull/8981 - Fixed #9475 -- allow add(), >> create(), etc for m2m with through >> >> I guess Claude will also like to update translations catalogs as he did >> for 2.1. >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1dccf9db-f6de-4c9b-a936-dae5768f31cd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: status of 2.2 release blockers
Hi, is it possible to get this fix included in 2.2? https://github.com/django/django/pull/10643 - Fixed #29915 -- Support hyphens in UUIDField filtering Vaclav Dne pondělà 14. ledna 2019 3:04:29 UTC+1 Tim Graham napsal(a): > > Time to kick off the progress tracker for the next major release! > > The 2.2 feature freeze is scheduled (according to > https://code.djangoproject.com/wiki/Version2.2Roadmap) for tomorrow, > January 14. Typically we've released the alpha a few days later to finish > up a few last minutes things. > > I have a few patches I want to finish reviewing: > > https://github.com/django/django/pull/10840 - Refs #28478 -- Adjusted > prevention of connections to disallowed databases. (regression fixes) > https://github.com/django/django/pull/10381 - Fixed #11154, #17904 and > #22270 -- Inconsistency with permissions for proxy models > https://github.com/django/django/pull/10171 - Fixed #20147 -- Added > HttpRequest.headers. > https://github.com/django/django/pull/8981 - Fixed #9475 -- allow add(), > create(), etc for m2m with through > > I guess Claude will also like to update translations catalogs as he did > for 2.1. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/da7e8275-c05c-4792-a88a-56855e91ce9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Google Summer of Code 2019
Hey Parth here. I am genuinely interested in doing a project with django as student in gsoc 2019. I have been working hard since past few months to get myself familiar with the famework. I had few project ideas in mind, but I'm confused about the intricacies and needed some help. Also i haven't contributed much yet, it would be very helpful if anyone can give me proper channel from where i can seek help or discuss with other people. Also where can i find the contact of people who have already done a gsoc project with django. P.S.:- I have tried posting on groups and messaging few people, but haven't gone far with that -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87532f2a-a44d-4417-ab0e-a13b0fad58d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Google Summer of Code 2019
Org applications for Google's Summer of Code are now open (deadline February 6). Do you think the Django Software Foundation should participate? We haven't had any high quality student applications that we could accept for the past two years. Perhaps it's partly a function of a poor ideas page (https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we don't do a great job of publicizing our involvement and attracting high quality students. Perhaps it's because the student payment isn't all that much (+/-$6000 USD, depending on student's country)* for the amount of work involved (also, students have to put in a lot of work up front in their application, with no guarantee of being accepted into the program). If you have any ideas about mentoring or suggesting a project, or if you're serious about being a student (you should start contributing to Django now if you don't already), please share. * https://developers.google.com/open-source/gsoc/help/student-stipends -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b2d64a6b-c33a-43e0-8b8f-7cbf36888a3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fellow Reports -- January 2019
Hi All, Calendar Week 2 -- ending 13 January. Triaged: https://code.djangoproject.com/ticket/30097 -- InlineModelAdmin.has_add_permission() requires obj argument (Accepted) https://code.djangoproject.com/ticket/30096 -- Use case of extra() (invalid) Reviewed: https://github.com/django/django/pull/10381 -- Fixed #11154, #17904 and #22270 -- Inconsistency with permissions for proxy models https://code.djangoproject.com/ticket/28554 -- Add support for multiple file fields https://code.djangoproject.com/ticket/29943 -- Document that admin changelist adds `pk` to ordering. https://github.com/django/django/pull/10692 -- Refs #17198 -- Detected existing total ordering in admin changelist. https://code.djangoproject.com/ticket/20147 -- Provide an alternative to request.META for accessing HTTP headers https://code.djangoproject.com/ticket/23829 -- Allow customizing the `ping_google` URL Kind Regards, Carlton -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5d3af7c7-dd41-49a3-bcc7-7c845d4e8a93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
