Dear Django Core Developers,
first and foremost, thank you for Django, which is a wonderful
project.
I realize that this is a volunteer-based project, but I was wondering
if you have any updates regarding the wiki page for the 1.4 roadmap?
(https://code.djangoproject.com/wiki/Version1.4Roadmap)
I'm
On Nov 24, 4:53 pm, Marcob wrote:
> Dear Django Core Developers,
> I'm big on providing feedback as I feel it contributes to the health
> of valuable projects like Django.
Ops... I really hope I didn't hurt anyone's feelings :-)
Ciao.
Marco.
--
You received this
On Nov 26, 1:19 pm, Aymeric Augustin
wrote:
> On 24 nov. 2011, at 16:53, Marcob wrote:
>
> > I realize that this is a volunteer-based project, but I was wondering
> > if you have any updates regarding the wiki page for the 1.4 roadmap?
> > (https://code.djangoproject.co
On Nov 28, 9:33 pm, Adrian Holovaty wrote:
> On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee
>
> wrote:
> > So -- what we need is for someone in the core team who is able to find
> > the resources in their schedule to commit to shepherding a release.
> > Speaking for myself, I know that this
The ticket 16317 has a very nice 4 months old patch (it's has a two
lines fix, remainder are just test fixes).
It was marked for 1.3 version but now it's better to change it to 1.4
version.
As I really hate to patch django I think my only solution is "to
lobby" this ticket here :-)
Is there anythin
In previous Django major releases I used to apply lots of patches (and
suffer some major headaches :-).
After 1.4 only this little one-liner is left:
https://code.djangoproject.com/ticket/15754
Leaving it out is impossible for me, as the user experience with some
custom forms can be painfully sl
On Monday, August 6, 2012 4:49:12 PM UTC+2, Marcob wrote:
>
> I'd really like to see it in Django 1.5 trunk, and it looks like the only
> blocking reason are missing tests.
>
Wow, thanks a lot Alex Gaynor! :-)
https://code.djangoproject.com/ticket/15754#comment:7
Ciao.
Marco.
With postgresql count(*) is a slow operation because it forces a full
table scan:
http://groups.google.it/group/pgsql.performance/browse_thread/thread/6f94b296019a0e1e/d2d6ca3018f51cb3?hl=it&ie=UTF-8&q=postgresql+django+slow+count%28*%29#d2d6ca3018f51cb3
I've a table with only 160.000 records (but
On 27 Mag, 23:13, Jacob Kaplan-Moss wrote:
> I thought there was already a ticket open for this, but I can't seem
> to find one. Can you open a ticket so that we don't forget?
Sure. Meanwhile I solved my problem with LazyPaginator and a bit of
monkey patching.
I'll post my ugly code within the
On May 27, 11:13 pm, Jacob Kaplan-Moss wrote:
> I thought there was already a ticket open for this, but I can't seem
> to find one. Can you open a ticket so that we don't forget?
To posterity: http://code.djangoproject.com/ticket/13643
:-)
Ciao.
Marco.
--
You received this message because yo
On 27 Mag, 22:58, Alex Gaynor wrote:
> FWIW Jacob was wrong, there is another tiket, but I can't find out now
> (yay trac search ;)), so don't be offended if I close your ticket.
Alex, no offense at all :-)
Ah, you don't be offended but I already closed it as a dupe of 8408
(thanks to Jeremy).
I see a huge list of tickets that shoud be in 1.3 release:
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=1.3
Within them I didn't found some that are, imho, a must for every
Django installation I did in the last two years:
Better raw_id_fields feedback i
On 30 Set, 07:34, "subs...@gmail.com" wrote:
> Hello all,
> I was browsing the tickets and saw a few of them nagging about some
> restrictions to raw_id_fields.
Since my first Django installation, a couple of years ago, I fixed and
used this patch:
http://code.djangoproject.com/ticket/7028
I see
I think that #6903 ticket http://code.djangoproject.com/ticket/6903
(together with http://code.djangoproject.com/ticket/12241) should be
considered to be in 1.3 release.
Every single person I know that use admin without this patch asks for
this functionality.
On 3/23/2009 Jacob said: This has gone
On 4 Ott, 04:09, Chuck Harmston wrote:
> An Ajax admin solution (of the autocomplete sort, which I presume is what
> you're proposing) does not have the same use case for raw_id_fields. It's
> based on the assumption that the user knows the value of the unicode
> representation of the object. It d
Not a big issue, I know... but aren't we perfectionist? :-)
Looking here:
http://code.djangoproject.com/browser/django/trunk/django/template/defaultfilters.py#L794
and here:
http://en.wikipedia.org/wiki/Kibibyte
I see that a more correct value should be 1000 or more correct labels
should be KiB
On 12 Gen, 14:26, Russell Keith-Magee wrote:
> You won't see me disagreeing. +1 to keeping as is.
> Until I start seeing kibibyte being used in the New York Times, or the
> prefered usage in the Chicago Manual of Style, the kibibyte is little
> more to me than an intriguing expression of pedantry
I have a model with a FK on User table:
from django.contrib.auth.models import User
class Ticket(models.Model):
assigned_to = models.ForeignKey(User, null=True, blank=True)
...
Then I have these two querysets:
>>> q1 = Ticket.objects.filter(assigned_to__isnull=True)
Reading the following documentation I deduced that partial date
settings (used in date_hierarchy filter) could be set in settings.py:
http://docs.djangoproject.com/en/dev/ref/settings/#year-month-format
http://docs.djangoproject.com/en/dev/ref/settings/#month-day-format
Unfortunately the
On 15 Set, 19:32, Marcob wrote:
> LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =
I translated from italian, obviously assigned_id should be
assigned_to_id.
Sorry.
Ciao.
Marco.
--~--~-~--~~~---~--~~
You
On Sep 15, 8:05 pm, Alex Gaynor wrote:
> This has already been filed as a bug in Django's ticket
> tracker:http://code.djangoproject.com/ticket/10790. In the future please try
> searching the tracker before filing a bug.
Thanks Alex, but:
1) I searched the trac
2) I didn't find the bug
3) So
I saw these tickets:
http://code.djangoproject.com/ticket/9484 (closed: duplicate)
Admin, raw_id_fields, not int value
Msg: #8746 covers this.
http://code.djangoproject.com/ticket/8746 (closed: fixed)
Data entered in raw_id_fields needs better checking
Msg: Please file a new ticket for this
htt
Often I got this remark about date_hierarchy "Wonderful! May we have
this also with this hierarchical field on that table?".
And my answer is invariably: "Unfortunately no: it works only with
date and/or time field".
I would like a generic_hierarchy option in admin where you can insert
every kind
On 16 Ott, 15:08, Marcob wrote:
> P.S. Perhaps you can already obtain this with a custom changelist_form
> and a custom date_hierarchy block, moreover I'd like to have a proper
> option.
Obviuosly instead of changelist_form I meaned change_list_template
It's about 4 hours I'm trying to find the real culprit...
To narrow the problem I create the simplest admin test:
from django.test import TestCase
class AdminViewBasicTest(TestCase):
def testAdmin(self):
from django.contrib.auth.models import User
user = User
On Mar 22, 1:53 pm, Karen Tracey wrote:
> No, turns out it was a change made farther back, and it was in fact a change
> specifically in response to the change in Python:
> http://code.djangoproject.com/changeset/11821
Karen,
thanks! :-)
Btw, I think this is a users-developers-gray-area-thread
http://code.djangoproject.com/ticket/7028
This little patch improves a lot the user feedback experience during
raw-id-fields selection.
When a big table hasn't a clear id (for example just a numeric id) and
an user chooses an item from the popup window, the item description
appears only after s
On 16 Apr, 02:24, Marcob <[EMAIL PROTECTED]> wrote:
> http://code.djangoproject.com/ticket/7028
I just modifed this patch and added a new one for django test suite
(one liner!):
- improved-raw-id-admin-feedback-fixed-regression-test.diff (3.7 kB)
- tests-fix-for-improved-raw-id-admin-pa
I just exported newforms-admin branch e try to apply this patch
http://code.djangoproject.com/ticket/7028
It fails on django/contrib/admin/templatetags/admin_list.py because it
is in DOS mode!!!
Why on earth?
Ciao.
Marco.
--~--~-~--~~~---~--~~
You received this me
On 19 Apr, 13:37, Marcob <[EMAIL PROTECTED]> wrote:
> I just exported newforms-admin branch e try to apply this
> patchhttp://code.djangoproject.com/ticket/7028
> It fails on django/contrib/admin/templatetags/admin_list.py because it
> is in DOS mode!!!
> Why on earth?
I found that after queryset-merge in newforms-admin date_hierarchy
filter doesn't work anymore: years and month are repeated.
To fix it I wrote this quick hack in django/contrib/admin/templatetags/
admin_list.py:
Line 240:
-days = cl.query_set.filter(**{year_field: year_lookup,
month_
31 matches
Mail list logo