date:20110214

Re: [Django] #15304: `Model.objects.create()` returns `long` instead of `int`.

2011-02-14 Thread Django

#15304: `Model.objects.create()` returns `long` instead of `int`.
+---
   Reporter:  mrmachine | Owner:  
nobody 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  int 
long primary key create get
   Triage Stage:  Unreviewed| Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---

Comment (by Alex):

 This test is wrong.  There's no guarntee that the objects will have the
 same identity, in fact, unless the primary key is less than 255 they
 won't.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15303: Functions passed as kwargs to View.as_view() should be bound

2011-02-14 Thread Django

#15303: Functions passed as kwargs to View.as_view() should be bound
-+--
   Reporter:  gg | Owner:  nobody
 Status:  new| Milestone:  1.3   
  Component:  Documentation  |   Version:  SVN   
 Resolution: |  Keywords:
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * component:  Generic views => Documentation
  * needs_tests:  => 0
  * stage:  Unreviewed => Accepted


Comment:

 As discussed on IRC: I'm not sure I see why we should make the
 implementation of the generic view base class a whole lot more complicated
 in order to allow users to avoid creating a subclass. Passing arguments in
 to as_view() is a convenience for the really simple cases -- it isn't
 intended as a way to avoid ever needed to create a View subclass.

 However, I can see how the phrasing about "overriding pattern" could lead
 to this expectation, so that should be cleaned up.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15304: `Model.objects.create()` returns `long` instead of `int`.

2011-02-14 Thread Django

#15304: `Model.objects.create()` returns `long` instead of `int`.
+---
   Reporter:  mrmachine | Owner:  
nobody 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  int 
long primary key create get
   Triage Stage:  Unreviewed| Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---
Changes (by mrmachine):

  * needs_better_patch:  => 1
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_docs:  => 0


Comment:

 Added a test.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15304: `Model.objects.create()` returns `long` instead of `int`.

2011-02-14 Thread Django

#15304: `Model.objects.create()` returns `long` instead of `int`.
-+--
 Reporter:  mrmachine|  Owner:  nobody
   Status:  new  |  Milestone:
Component:  Database layer (models, ORM) |Version:  SVN   
 Keywords:  int long primary key create get  |   Triage Stage:  Unreviewed
Has patch:  0|  
-+--
 Some database backends (I've only tested postgresql, sqlite seems OK) seem
 to return a `long` PK instead of `int` when creating new model objects.
 When getting an existing model object, `int` is correctly returned. I did
 find a comment about this in the
 [http://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-models
 tutorial], but I don't think this is by design and I think this difference
 in behaviour between new and existing objects and database backends is
 buggy and violates the principle of least surprise.

 It might be a bit of an edge case, but we were stumped for a while trying
 to figure out why created objects had a PK of a different type to existing
 objects. We initially noticed the problem because we use a pickle field to
 store various types of data -- PKs, dates and times, booleans, dicts, etc.
 -- and when passing in the value of a newly created PK to the pickle field
 we were then unable to filter on it unless we explicitly searched for
 `long` values.

 So to work-around this issue we need to a) know the type of the PK that
 should be returned for existing objects and coerce it before passing to
 the pickle field if it does not match.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15303: Functions passed as kwargs to View.as_view() should be bound

2011-02-14 Thread Django

#15303: Functions passed as kwargs to View.as_view() should be bound
---+
 Reporter:  gg |  Owner:  nobody
   Status:  new|  Milestone:  1.3   
Component:  Generic views  |Version:  SVN   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 Problem:

 At the moment, generic.base.View.as_view() passes kwargs to the class'
 init (which `setattr`s them), rather than dynamically subclassing. The
 [http://docs.djangoproject.com/en/dev//topics/class-based-views/
 introductory generic view docs], however, seem to imply that passing
 kwargs to the as_view() method is equivalent to overriding the class. For
 example, it [http://docs.djangoproject.com/en/dev//topics/class-based-
 views/#simple-usage refers to] "pass[ing] the new attributes into the
 as_view method call" as an "overriding pattern." This makes it rather
 surprising that functions passed to as_view() aren't bound to the
 resultant instance.

 Possible Resolutions:

 It seems to me that as_view() should dynamically create a subclass with
 the provided kwargs. Alternatively, if that is deemed undesirable, the
 docs should at least be clarified to better explain the true behaviour.

 I can provide a patch, but need someone (*cough* RKM :) to confirm the
 desired behaviour.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15302: DecimalField dumps string instead of Decimal

2011-02-14 Thread Django

#15302: DecimalField dumps string instead of Decimal
-+--
   Reporter:  v1v3kn | Owner:  nobody
 Status:  closed | Milestone:
  Component:  Uncategorized  |   Version:  1.2   
 Resolution:  invalid|  Keywords:
   Triage Stage:  Unreviewed | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * status:  new => closed
  * needs_docs:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_better_patch:  => 0


Comment:

 The test suite contains multiple examples that demonstrate this claim to
 be false.

 It's entirely possible that you have observed this, but the first rule of
 all bug reports is: Provide enough detail so that someone else can
 reproduce your problem. This is especially important when you're dealing
 with something that appears to be a fundamental failure of the framework.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15302: DecimalField dumps string instead of Decimal

2011-02-14 Thread Django

#15302: DecimalField dumps string instead of Decimal
---+
 Reporter:  v1v3kn |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Uncategorized  |Version:  1.2   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 When a DecimalField is retrieved from a model object, its type is string
 rather than a Decimal which seems counter-intuitive.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:  1.4   
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by russellm):

  * milestone:  1.3 => 1.4


Comment:

 This is a feature addition, and the deadline for new features in 1.3
 passed some time ago.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:  1.3   
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by v1v3kn):

  * milestone:  => 1.3


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14760: Admin inlines with file/image field fails to save_as

2011-02-14 Thread Django

#14760: Admin inlines with file/image field fails to save_as
--+-
   Reporter:  paulos  | Owner:  nobody
 Status:  reopened| Milestone:
  Component:  django.contrib.admin|   Version:  1.2   
 Resolution:  |  Keywords:
   Triage Stage:  Design decision needed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-

Comment (by SmileyChris):

 Thanks for clarifying this, ramiro.

 Regarding item 3, I looked over that other ticket yesterday and I'm happy
 enough with your opinion considering it works like that now (while
 discussing here I had forgotten I was monkey-fixing this for a client on a
 1.0 branch)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15295: GeoDjango model creation fails for MySQL during tests

2011-02-14 Thread Django

#15295: GeoDjango model creation fails for MySQL during tests
--+-
   Reporter:  adamnelson  | Owner:  nobody
 Status:  new | Milestone:
  Component:  GIS |   Version:  SVN   
 Resolution:  |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-

Comment (by adamnelson):

 It works fine if I don't use InnoDB I presume.  However, I'd like to use
 InnoDB in my environment so it would be best if the tests pass.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15301: GenericInlineModelAdmin's get_formset() method does not have same arg signature/behavior as InlineModelAdmin

2011-02-14 Thread Django

#15301: GenericInlineModelAdmin's get_formset() method does not have same arg
signature/behavior as InlineModelAdmin
--+-
 Reporter:  anonymous |  Owner:  nobody
   Status:  new   |  Milestone:
Component:  Contrib apps  |Version:  1.2   
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  
--+-
 This leads to difficulty when trying to override get_formset() in a
 subclass

 Note that it takes **kwargs and will update the defaults:
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L1297

 No kwargs/no update:
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/generic.py#L402

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14402: help_text is not displayed for ManyToMany raw_id fields

2011-02-14 Thread Django

#14402: help_text is not displayed for ManyToMany raw_id fields
+---
   Reporter:  tyrion| Owner:  nobody
 Status:  new   | Milestone:
  Component:  django.contrib.admin  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---
Changes (by acdha):

 * cc: chris@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15176: History view of AdminSite doesn't take in account user defined queryset

2011-02-14 Thread Django

#15176: History view of AdminSite doesn't take in account user defined queryset
+---
   Reporter:  t2y   | Owner:  nobody  
 Status:  new   | Milestone:  1.3 
  Component:  django.contrib.admin  |   Version:  1.2 
 Resolution:|  Keywords:  multi-db
   Triage Stage:  Accepted  | Has patch:  1   
Needs documentation:  0 |   Needs tests:  1   
Patch needs improvement:  0 |  
+---

Comment (by julien):

 Sorry, that was me just above.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15176: History view of AdminSite doesn't take in account user defined queryset

2011-02-14 Thread Django

#15176: History view of AdminSite doesn't take in account user defined queryset
+---
   Reporter:  t2y   | Owner:  nobody  
 Status:  new   | Milestone:  1.3 
  Component:  django.contrib.admin  |   Version:  1.2 
 Resolution:|  Keywords:  multi-db
   Triage Stage:  Accepted  | Has patch:  1   
Needs documentation:  0 |   Needs tests:  1   
Patch needs improvement:  0 |  
+---

Comment (by anonymous):

 I actually feel divided about this. The history is supposed to show all
 the things that have been changed/added/deleted in the past. Using a
 custom queryset means that the history may change over time, which seem
 kind of weird. I do recognise that there might be cases where we do want a
 custom queryset to be used, but I also think that in some other cases we
 might actually want the default one to be used. So I'd be in favour of a
 more granular system for the history view.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14129: Fix Slovenian translation plural-forms

2011-02-14 Thread Django

#14129: Fix Slovenian translation plural-forms
+---
   Reporter:  gasperzejn| Owner:  jezdez
 Status:  new   | Milestone:  1.3   
  Component:  Translations  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by gasperzejn):

 No, this isn't correct. The plural forms need shuffling around using this
 pseudocode assignment:

 {{{
 msgstr[0] = msgstr[3]
 msgstr[1] = msgstr[0]
 msgstr[2] = msgstr[1]
 msgstr[3] = msgstr[2]
 }}}

 Thanks.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15295: GeoDjango model creation fails for MySQL during tests

2011-02-14 Thread Django

#15295: GeoDjango model creation fails for MySQL during tests
--+-
   Reporter:  adamnelson  | Owner:  nobody
 Status:  new | Milestone:
  Component:  GIS |   Version:  SVN   
 Resolution:  |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by jbronn):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0


Comment:

 Replying to [ticket:15295 adamnelson]:
 > This is because MySQL InnoDB does not support SPATIAL indexes.  Options:
 >
 >  1. create a new variable for spatial_index that is set to true if using
 the MySQL backend with InnoDB
 >  1. or wrap table creation around a try...except that inserts
 spatial_index=False
 >  1. or do one of these for GeoDjango generally (not just the tests)

 How about not attempting to run the GeoDjango test suite with InnoDB in
 the first place?  What does your settings file look like when you ran
 `runtests.py`?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15300: Pull translation updates from transifex.net and update strings of English language files

2011-02-14 Thread Django

#15300: Pull translation updates from transifex.net and update strings of 
English
language files
+---
   Reporter:  jezdez| Owner:  jezdez 
 Status:  new   | Milestone:  1.3
  Component:  Translations  |   Version:  1.2
 Resolution:|  Keywords:  blocker
   Triage Stage:  Accepted  | Has patch:  0  
Needs documentation:  0 |   Needs tests:  0  
Patch needs improvement:  0 |  
+---
Changes (by jezdez):

  * keywords:  => blocker


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15300: Pull translation updates from transifex.net and update strings of English language files

2011-02-14 Thread Django

#15300: Pull translation updates from transifex.net and update strings of 
English
language files
+---
   Reporter:  jezdez| Owner:  jezdez  
 Status:  new   | Milestone:  1.3 
  Component:  Translations  |   Version:  1.2 
   Keywords:|  Triage Stage:  Accepted
  Has patch:  0 |   Needs documentation:  0   
Needs tests:  0 |   Patch needs improvement:  0   
+---
 Before releasing the release candidate we need to make sure to pull all
 translation updates from transifex.net and update the strings of the
 English language files.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14760: Admin inlines with file/image field fails to save_as

2011-02-14 Thread Django

#14760: Admin inlines with file/image field fails to save_as
--+-
   Reporter:  paulos  | Owner:  nobody
 Status:  reopened| Milestone:
  Component:  django.contrib.admin|   Version:  1.2   
 Resolution:  |  Keywords:
   Triage Stage:  Design decision needed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-

Comment (by ramiro):

 So, this ticket report and comments seem to be actually about three
 different issues about the admin ''Edit view'' of a model with inlines of
 instances of a model that has a FK to it and contains a !FileField or
 !ImageField:

 1. Pressing the "Save as" button reports back a validation error and the
 following:
   a. The image/file fields of  inlines already existing in the DB/FS
 will be empty and show "This field is required." message error.
   b. Values of other fields of the already existing inlines are
 preserved.
   c. All the information filled by the user in extra inlines is lost.

 2. If, in the resulting admin ''Add view'', new files are selected from
 the local FS for the fields reporting validation errors. You get a
 `'ValueError?: invalid literal for int() with base 10'` error.

 3. When the error of item 1 happens, the ''save_as_new'' button gets
 replaced with a ''save_and_add_another''

 I propose to limit this ticket to item 1.

 Item 2 is already covered by #13223.

 Item 3 is already covered by #5681, please see ticket:5681#comment:4 for a
 different opinion about it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14284: Support for Google Maps version 3

2011-02-14 Thread Django

#14284: Support for Google Maps version 3
-+--
   Reporter:  DaveWP196  | Owner:  ericpalakovichcarr
 Status:  assigned   | Milestone:
  Component:  GIS|   Version:  1.2   
 Resolution: |  Keywords:  Google Maps   
   Triage Stage:  Accepted   | Has patch:  1 
Needs documentation:  1  |   Needs tests:  1 
Patch needs improvement:  1  |  
-+--
Changes (by alanjds):

 * cc: alanjds (added)


Comment:

 (last ''anonymous'' is me. I forgot to login before comment, sorry)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14284: Support for Google Maps version 3

2011-02-14 Thread Django

#14284: Support for Google Maps version 3
-+--
   Reporter:  DaveWP196  | Owner:  ericpalakovichcarr
 Status:  assigned   | Milestone:
  Component:  GIS|   Version:  1.2   
 Resolution: |  Keywords:  Google Maps   
   Triage Stage:  Accepted   | Has patch:  1 
Needs documentation:  1  |   Needs tests:  1 
Patch needs improvement:  1  |  
-+--

Comment (by anonymous):

 Existing (broken) patch improved. Tested over 1.2.4 and working OK.
 [[BR]]
 Needs clean-up of some unneeded settings, but for now this settings
 remains as noops. Django API keeps the same too.

 http://github.com/django/django/pull/16

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14093: Unable to create a new session key on higher traffic

2011-02-14 Thread Django

#14093: Unable to create a new session key on higher traffic
---+
   Reporter:  szymon@… | Owner:  nobody 

 Status:  new  | Milestone: 

  Component:  django.contrib.sessions  |   Version:  1.2

 Resolution:   |  Keywords:  session, 
cache, session key
   Triage Stage:  Accepted | Has patch:  1  

Needs documentation:  0|   Needs tests:  0  

Patch needs improvement:  0|  
---+

Comment (by tomevans223):

 There is no problem with changing VALID_KEY_CHARS to include '-', the
 purpose of it is to sanitize user input to prevent directory traversals.

 Other comments replied to on thread.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14129: Fix Slovenian translation plural-forms

2011-02-14 Thread Django

#14129: Fix Slovenian translation plural-forms
+---
   Reporter:  gasperzejn| Owner:  jezdez
 Status:  new   | Milestone:  1.3   
  Component:  Translations  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by diegobz@…):

 * cc: diegobz@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15282: inlineformset_factory ignores overrides on base_fields when a form class is passed in

2011-02-14 Thread Django

#15282: inlineformset_factory ignores overrides on base_fields when a form 
class is
passed in
--+-
   Reporter:  coleifer| Owner:  nobody  
 
 Status:  closed  | Milestone:  
 
  Component:  Forms   |   Version:  1.2 
 
 Resolution:  invalid |  Keywords:  inlineformset_factory, 
ModelFormMetaclass
   Triage Stage:  Unreviewed  | Has patch:  1   
 
Needs documentation:  0   |   Needs tests:  0   
 
Patch needs improvement:  0   |  
--+-
Changes (by anonymous):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 base_fields is not a public API, so this isn't a bug. Reopen if there's a
 manifestation of the issue that can be triggered without poking directly
 at base_fields.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14129: Fix Slovenian translation plural-forms

2011-02-14 Thread Django

#14129: Fix Slovenian translation plural-forms
+---
   Reporter:  gasperzejn| Owner:  jezdez
 Status:  new   | Milestone:  1.3   
  Component:  Translations  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by jezdez):

 Okay, the Transifex developers now have tested it on test.transifex.net
 and ask us if the following plural form example is correct:

 {{{
 # This file is distributed under the same license as the Django package.
 #
 msgid ""
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: http://code.djangoproject.com/\n;
 "POT-Creation-Date: 2010-05-13 15:35+0200\n"
 "PO-Revision-Date: 2011-02-14 16:14+\n"
 "Last-Translator: Django team\n"
 "Language-Team: English \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Language: sl\n"
 "Plural-Forms: nplurals=4; plural=(n%100==1 ? 1 : n%100==2 ? 2 : n%100==3
 || n%100==4 ? 3 : 0)\n"

 #: contrib/admin/templates/admin/change_form.html:39
 #: contrib/admin/templates/admin/change_list.html:71
 #: contrib/admin/templates/admin/auth/user/change_password.html:24
 #: contrib/admin/templates/registration/password_change_form.html:15
 msgid "Please correct the error below."
 msgid_plural "Please correct the errors below."
 msgstr[0] "Prosimo, odpravite sledečo napako."
 msgstr[1] "Prosimo, odpravite sledeči napaki."
 msgstr[2] "Prosimo, odpravite sledeče napake."
 msgstr[3] "Prosimo, odpravite sledeče napake."
 }}}

 https://gist.github.com/b8b851f3c4bffa08378f

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by v1v3kn):

  * needs_docs:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15274: UpdateView raises exception about overiding get_object

2011-02-14 Thread Django

#15274: UpdateView raises exception about overiding get_object
--+-
   Reporter:  sergeybe@…  | Owner:  nobody  
 Status:  new | Milestone:  1.3 
  Component:  Generic views   |   Version:  1.3-beta
 Resolution:  |  Keywords:  blocker 
   Triage Stage:  Accepted| Has patch:  0   
Needs documentation:  0   |   Needs tests:  0   
Patch needs improvement:  0   |  
--+-

Comment (by russellm):

 I've found the cause -- you've overridden get_object, but you haven't
 provided a form, so the call to get_form_class() is calling get_queryset()
 as a cheats way to find the model that can be used to automatically
 construct a ModelForm.

 The simple workaround -- specify a form_class. I'm looking into what we
 can do as a permanent solution.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15125: UpdateView should introspect form_class instead of requiring you to pass the model

2011-02-14 Thread Django

#15125: UpdateView should introspect form_class instead of requiring you to pass
the model
-+--
   Reporter:  sontek | Owner:  nobody
 Status:  closed | Milestone:  1.3   
  Component:  Generic views  |   Version:  SVN   
 Resolution:  wontfix|  Keywords:
   Triage Stage:  Accepted   | Has patch:  1 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * status:  new => closed
  * resolution:  => wontfix


Comment:

 Looking at this more closely, I'm not sure this can be achieved:

  * UpdateView calls get_object() to find the object to edit
  * get_object() calls get_queryset()
  * If a queryset hasn't been specified, get_queryset() then calls
 get_model()
  * get_model() calls get_form_class()
  * If a form_class hasn't been specified, get_form_class() calls
 get_queryset().

 This means that get_model depends on get_queryset, and get_queryset
 depends on get_model. This dependency chain can be resolved in certain
 circumstances -- the provided test case is one such case. However, in the
 general case, it's a minefield. Any of these functions can be overridden
 -- get_object, get_model, or get_queryset -- which means that there needs
 to be a clear dependency of information, or else you could easily get
 stuck in a recursive loop of calls. The simplest way to break it is to not
 specify a form_class OR a queryset, but the complex dependency chain
 combined with extensibility strikes me as an accident waiting to happen.

 Closing wontfix, but only because I can't see a way to build this (and
 then explain it clearly) in the general case. Feel free to reopen if you
 can find a cleaner way to put the pieces together.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15181: FileSystemStorage generates wrong URL when path contains special characters

2011-02-14 Thread Django

#15181: FileSystemStorage generates wrong URL when path contains special 
characters
+---
   Reporter:  e.generalov   | Owner:  nobody
 Status:  closed| Milestone:
  Component:  File uploads/storage  |   Version:  SVN   
 Resolution:  fixed |  Keywords:
   Triage Stage:  Ready for checkin | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by paulegan):

 * cc: paulegan@… (added)


Comment:

 NB: This change means that URLs stored in !FileFields or !ImageFields
 using the default storage are now handled differently.

 Previously:
 {{{#!python
 >>> from django.core.files.storage import DefaultStorage, settings
 >>> settings.configure(MEDIA_URL='http://localhost')
 >>> DefaultStorage().url('http://media/test')
 'http://media/test'
 }}}
 Now:
 {{{#!python
 >>> from django.core.files.storage import DefaultStorage, settings
 >>> settings.configure(MEDIA_URL='http://localhost')
 >>> DefaultStorage().url('http://media/test')
 'http://localhost/http%3A//media/test'
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15125: UpdateView should introspect form_class instead of requiring you to pass the model

2011-02-14 Thread Django

#15125: UpdateView should introspect form_class instead of requiring you to pass
the model
-+--
   Reporter:  sontek | Owner:  nobody
 Status:  new| Milestone:  1.3   
  Component:  Generic views  |   Version:  SVN   
 Resolution: |  Keywords:
   Triage Stage:  Accepted   | Has patch:  1 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * stage:  Ready for checkin => Accepted


Comment:

 This isn't quite right -- again, form_class doesn't *necessarily* have a
 _meta attribute, because it might not be a ModelForm.

 I think there may be a better way to handle this, which has the added
 benefit of fixing #15274. We may not be able to reliably get the model
 class from form_class, but we *can* get it from self.object, which always
 exists on an UpdateView.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15287: Error messages in generic views are partialy translated

2011-02-14 Thread Django

#15287: Error messages in generic views are partialy translated
-+--
   Reporter:  szczav | Owner:  nobody   
  
 Status:  new| Milestone:  1.3  
  
  Component:  Generic views  |   Version:  SVN  
  
 Resolution: |  Keywords:  generic views 
http404 translation error blocker
   Triage Stage:  Ready for checkin  | Has patch:  1
  
Needs documentation:  0  |   Needs tests:  0
  
Patch needs improvement:  1  |  
-+--
Changes (by russellm):

  * stage:  Accepted => Ready for checkin
  * milestone:  => 1.3


Comment:

 This patch isn't strictly ready for checkin, because it's a superset of
 what is needed. However, I can distill what is needed from this patch. For
 posterity:

  * We're not going to add translation strings for deprecated features
 (i.e., old-style function based generics)
  * We don't need to translate InvalidConfiguration, TypeError and other
 internal errors. If a user ever sees these, there is something *badly*
 wrong. We only need to translate the 404s. This follows the pattern
 established by contrib.admin.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15281: Staticfiles sever view should use generator

2011-02-14 Thread Django

#15281: Staticfiles sever view should use generator
--+-
   Reporter:  FunkyBob| Owner:  
 
 Status:  new | Milestone:  1.4 
 
  Component:  django.contrib.staticfiles  |   Version:  SVN 
 
 Resolution:  |  Keywords:  
generator
   Triage Stage:  Accepted| Has patch:  1   
 
Needs documentation:  0   |   Needs tests:  1   
 
Patch needs improvement:  1   |  
--+-

Comment (by anonymous):

 Recent trunk changes have moved the work from contrib.staticfiles.views to
 views.static.

 Also, to address the test failures, I've adjusted them to consume the
 request.content only once.

 The new patch is smaller [doesn't clean up the stat.ST_* usage], and makes
 the tests pass for me.

 {{{
 Index: django/views/static.py
 ===
 --- django/views/static.py  (revision 15530)
 +++ django/views/static.py  (working copy)
 @@ -59,10 +59,9 @@
  if not was_modified_since(request.META.get('HTTP_IF_MODIFIED_SINCE'),
statobj[stat.ST_MTIME],
 statobj[stat.ST_SIZE]):
  return HttpResponseNotModified(mimetype=mimetype)
 -contents = open(fullpath, 'rb').read()
 -response = HttpResponse(contents, mimetype=mimetype)
 +response = HttpResponse(open(fullpath, 'rb'), mimetype=mimetype)
  response["Last-Modified"] = http_date(statobj[stat.ST_MTIME])
 -response["Content-Length"] = len(contents)
 +response["Content-Length"] = statobj.st_size
  if encoding:
  response["Content-Encoding"] = encoding
  return response
 Index: tests/regressiontests/views/tests/static.py
 ===
 --- tests/regressiontests/views/tests/static.py (revision 15530)
 +++ tests/regressiontests/views/tests/static.py (working copy)
 @@ -22,8 +22,9 @@
  for filename in media_files:
  response = self.client.get('/views/site_media/%s' % filename)
  file_path = path.join(media_dir, filename)
 -self.assertEquals(open(file_path).read(), response.content)
 -self.assertEquals(len(response.content), int(response
 ['Content-Length']))
 +content = str(response.content)
 +self.assertEquals(open(file_path).read(), content)
 +self.assertEquals(len(content), int(response['Content-
 Length']))
  self.assertEquals(mimetypes.guess_type(file_path)[1],
 response.get('Content-Encoding', None))

  def test_unknown_mime_type(self):
 @@ -65,9 +66,9 @@
  response = self.client.get('/views/site_media/%s' % file_name,
 HTTP_IF_MODIFIED_SINCE=invalid_date)
  file = open(path.join(media_dir, file_name))
 -self.assertEquals(file.read(), response.content)
 -self.assertEquals(len(response.content),
 -  int(response['Content-Length']))
 +content = str(response.content)
 +self.assertEquals(file.read(), content)
 +self.assertEquals(len(content), int(response['Content-Length']))

  def test_invalid_if_modified_since2(self):
  """Handle even more bogus If-Modified-Since values gracefully
 @@ -80,6 +81,6 @@
  response = self.client.get('/views/site_media/%s' % file_name,
 HTTP_IF_MODIFIED_SINCE=invalid_date)
  file = open(path.join(media_dir, file_name))
 -self.assertEquals(file.read(), response.content)
 -self.assertEquals(len(response.content),
 -  int(response['Content-Length']))
 +content = str(response.content)
 +self.assertEquals(file.read(), content)
 +self.assertEquals(len(content), int(response['Content-Length']))
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  1 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by lrekucki):

  * needs_docs:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by v1v3kn):

  * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15299: django.core.context_processors.PermWrapper should be moved to django.contrib.auth.context_processors

2011-02-14 Thread Django

#15299: django.core.context_processors.PermWrapper should be moved to
django.contrib.auth.context_processors
--+-
   Reporter:  shailesh| Owner:  nobody   
 Status:  new | Milestone:  1.3  
  Component:  Authentication  |   Version:  1.2  
 Resolution:  |  Keywords:  easy-pickings
   Triage Stage:  Accepted| Has patch:  0
Needs documentation:  0   |   Needs tests:  0
Patch needs improvement:  0   |  
--+-
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Authentication
  * needs_tests:  => 0
  * milestone:  => 1.3
  * keywords:  => easy-pickings
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted


Comment:

 This ticket requires a couple of things:

  * Adding a deprecation warning to the existing instances
  * Copying the code to the contrib.auth context processor module
  * Updating the references in the docs (two references at present, in
 ref/templates/api and topics/auth)

 It would be good to get this in for 1.3 -- we're already going to have to
 keep the alias around for a release longer than the auth processor that
 originally used it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15281: Staticfiles sever view should use generator

2011-02-14 Thread Django

#15281: Staticfiles sever view should use generator
--+-
   Reporter:  FunkyBob| Owner:  
 
 Status:  new | Milestone:  1.4 
 
  Component:  django.contrib.staticfiles  |   Version:  SVN 
 
 Resolution:  |  Keywords:  
generator
   Triage Stage:  Accepted| Has patch:  1   
 
Needs documentation:  0   |   Needs tests:  1   
 
Patch needs improvement:  1   |  
--+-
Changes (by jezdez):

  * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12489: Need a Field Lookup for day of year: __dayofyear

2011-02-14 Thread Django

#12489: Need a Field Lookup for day of year: __dayofyear
+---
   Reporter:  deanq | Owner:  
v1v3kn  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:
  
 Resolution:|  Keywords:  field 
lookup datetime filter
   Triage Stage:  Accepted  | Has patch:  0 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by v1v3kn):

  * status:  new => assigned
  * owner:  nobody => v1v3kn


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

2011-02-14 Thread Django

#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
-+--
   Reporter:  anonymous  | Owner:  nobody 
 Status:  new| Milestone:  1.3
  Component:  Forms  |   Version:  SVN
 Resolution: |  Keywords:  sprintdec01
   Triage Stage:  Accepted   | Has patch:  1  
Needs documentation:  0  |   Needs tests:  0  
Patch needs improvement:  0  |  
-+--

Comment (by stephaner):

 This ticket has a 1.3 milestone...

 Smiley, have you received feedback on this bug from django-dev?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

39 matches

Mail list logo