Opinions, Feedback & Review needed for PR #8191 & Ticket #27944 -- returning pk from .get_field('pk')

Earlier I fixed bug #27897 that resulted in a crash when the field name 'pk' was used in an admin search filter. The fix was to special case the check for 'pk' before calling `.get_field`. Afterwards I grepped through the code base and found 3 or 4

Re: Easy pickings are not that easy for a new contributor

I recommend narrowing down the huge number of tickets using the "Component" category in Trac. Look at https://code.djangoproject.com/query?status=assigned=new=contrib.admin=Accepted=id=summary=status=owner=type=version=1=id and pick a Component that you're interested in and have some

#21381 PR review needed

I've completed code and tests and would like to have someone review it before I'll start working on documentation. PR Ticket Thanks in advance. -- You received this message because you are subscribed to

Re: Support for database level on delete cascade 21961

Thanks for the feedback Anssi. The original ticket talked about making DB_CASCADE work where it can, and adding warnings to most other places. I've updated the PR with checks warnings for the following cases (including tests for said checks cases): - GenericForeignKey + DB_CASCADE (#4 in

Django security releases issued: 1.11.5 and 1.10.8

Today the Django team issued 1.11.5 and 1.10.8 as part of our security process. These releases address a security issue, and we encourage all users to upgrade as soon as possible: https://www.djangoproject.com/weblog/2017/sep/05/security-releases/ As a reminder, we ask that potential security

Re: Dynamic Model with Foreign Key

Hi, there's nothing in the Django documentation about dynamic models, so there's no official support for it. I'm not aware of any recent discussions about it but searching this mailing list's archives for "dynamic models" or searching Google for "django dynamic models" might yield something

Dynamic Model with Foreign Key

Hi, I need a comment by Django developer, because I feel like things I am asking about are too complex for users mailing list. Start of discussion is here. https://groups.google.com/forum/#!topic/django-users/_u83xxJOIFU *TL/DR* Is it impossible to get reverse relation to dynamically added

Re: Easy pickings are not that easy for a new contributor

There are also some other repos in the Django organization on GitHub that could do with some love: https://github.com/django . For example localflavor and formtools, which were removed from Django core, still have some users and you might something to work on there. On 5 September 2017 at 15:06,

Re: Easy pickings are not that easy for a new contributor

On Tue, Sep 5, 2017, Alexander Lyabah wrote: >A lot of articles that I've read say that I should start with ticket from >Easy pickings. >The problem is that there are not that many tickets I can choose from. All >of them are already assign. > >Maybe I can start with

Easy pickings are not that easy for a new contributor

Hi guys, A lot of articles that I've read say that I should start with ticket from Easy pickings https://code.djangoproject.com/query?status=assigned=new=1=Accepted=id=summary=status=owner=type=component=version=changetime=1=id The problem is that there are not that many tickets I can choose

Re: Use of HTML autofocus attribute in admin (#27692)

> If there were a way to autofocus on first page load only that would be the best, it might be possible with JS. Yes, It should be possible by parsing document.referrer in JS. On Monday, January 9, 2017 at 10:21:15 AM UTC+2, Adam Johnson wrote: > > I just found out that's it not new behavior in

Re: Custom Join Conditions

On Tue, Sep 5, 2017 at 5:10 AM Adam Johnson wrote: > from django.db.models import FilteredRelation is what I'd expect > This is what I'd expect too. > On 5 September 2017 at 09:44, Nicolas Delaby wrote: > >> It seems we have a consensus. >> I'll be glad to

Re: Custom Join Conditions

from django.db.models import FilteredRelation is what I'd expect On 5 September 2017 at 09:44, Nicolas Delaby wrote: > It seems we have a consensus. > I'll be glad to push that change. > > I just have a question, from where do you want users importing the class >

About #8500 and #27728

Hi all, I'm working to ticket #8500 and #27728 to improve a bit the admin, and being asked to ask to django-developers about some decision. In ticket #8500 I've used a LazyObject to defer the the real django.contrib.admin.sites.site instantiation, so admin.site is always the custom one. The first

Re: Custom Join Conditions

It seems we have a consensus. I'll be glad to push that change. I just have a question, from where do you want users importing the class FilteredRelation ? >From its current location ? from django.db.models.query import FilteredRelation or from its parent module ? from django.db.models

Re: Publish workflow for all apps

See also: https://github.com/andersinno/django-model-publisher-ai/issues/15 Am Dienstag, 5. September 2017 10:19:49 UTC+2 schrieb googl...@jensdiemer.de: > > > Any news here? > > > I use https://github.com/andersinno/django-model-publisher-ai for this. > But it would be nice to have this

Re: Publish workflow for all apps

Any news here? I use https://github.com/andersinno/django-model-publisher-ai for this. But it would be nice to have this feature from django-cms, with the same workflow. I think the effort is manageable, isn't it? I see nothing on the roadmap: https://www.django-cms.org/en/roadmap/ --