#4926, Ordering in admin listview ignores ordering in admin options
This issue has been up with a patch for quite awhile, and wanted to get some feedback from some devs on this. The fix is pretty simple, and seems to work ok for me. Here's my thoughts on it: When I specify ordering with multiple fields on my Model or my ModelAdmin, the changelist should respect that ordering by default. If the user changes the ordering using the column headers, then it should use that ordering on the single field. I don't I see why it should only be one or the other. I know there's another discussion going on about adding multiple field ordering to the UI, but that's a much bigger change. Is there any reason why this can't make it into trunk in the meantime? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Status of InstalledAppsRevision, soc2010/app-loading branch?
It looks like the last discussion on this was back in Apr 2010, and the last trunk-merge was 4 months ago. The last comment on #3591 by russelm was that the GSOC branch "is looking reasonably good".So, my question is, is there still any interest in getting this merged into trunk, or is there still a design decision needed? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re-open #7231: New "join" parameter for the "extra" QuerySet method
http://code.djangoproject.com/ticket/7231 I'd like to start a discussion on this since russelm closed the issue. There are a few other people that believe the issue should be left open. I've been using this patch for nearly two years, and have found it to be useful in several different cases. I disagree that the .raw() functionality is a sufficient alternative, as it is not possible to modify an existing queryset using .raw(). For example, if I have a function that accepts a queryset, I want to be able to modify that queryset by giving it a extra info for the JOIN and SELECT clauses. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
PyCon 2014 Sprints
I know Django will be sprinting at PyCon, and I thought I might like to participate. I haven't done conference sprints before, so I'm curious, what's the process? If I have a particular ticket that I'm interested in, do I just work on that bug at the sprint? Or will there be a proposed list of bugs that we will be working on? -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ec0cc8d3-ec3f-469a-b24e-e824d0358d5f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
