tickets

34 rows where "created" is on date 2008-08-26 sorted by resolution

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: changetime, stage, version, resolution, reporter, has_patch, needs_better_patch, created (date), changetime (date)

needs_tests 2 ✖

  • 0 33
  • 1 1
id created changetime last_pulled_from_trac stage status component type severity version resolution ▼ summary description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
8549 2008-08-26 00:38:30 2008-08-26 00:41:52 2022-03-06 03:42:33.293323 Unreviewed closed Core (Serialization)     dev duplicate Fields added via the extra() QuerySet modifier are not outputted when QuerySet is run through serializer It appears that when you add a field via the {{{extra()}}} method on a {{{QuerySet}}}, that field is not made available to you when you run the {{{QuerySet}}} through the serializer. I am running django version 1.0-beta_1-SVN-8539. The context in which I discovered this bug, brief: I set a custom field using extra() so that i could order results by a distance form a given longitude/latitude pair. The custom field uses MySQL numeric functions. Example looks like: {{{ entries = Entry.objects.extra(select={'distance': "SQRT(POW((locations.lat-%s),2) + POW((locations.lon-%s),2))"}, select_params=(str(centerLat), str(centerLng))) entries = entries.extra(order_by = ['distance'])[:5] }}} This works. {{{entries[0].distance}}} returns a float correctly, for example. The bug arises when this {{{QuerySet}}} is serialized and output, as follows: {{{ from django.core import serializers json_serializer = serializers.get_serializer("json")() json_serializer.serialize(entries, ensure_ascii=False, stream=response) }}} The response stream does NOT include the distance attribute, though all other attributes of the model are set. Even explicitly setting the distance attribute in the fields argument of {{{serialize()}}} does not include the distance attribute. I tried changing the serializer to xml to see if it was an artifact of json, but still the attribute was not included. I did confirm that the attribute exists on the {{{QuerySet}}} itself I tried searching on this bug and I posted this on django-users and found nothing. My apologies if this is not a bug or its been reported elsewhere. I hope this is useful. nobody Jim Dalton <jim.dalton@furrybrains.com>   0 0 0 0 0 0
8550 2008-08-26 03:05:13 2011-09-28 16:12:17 2022-03-06 03:42:33.438088 Unreviewed closed contrib.admin     dev duplicate date filter can't right work in object_history.html. object_history.html:30 <th scope="row">{{ action.action_time|date:_("DATETIME_FORMAT") }}</th> _("DATETIME_FORMAT") translate in the zh_CN/LC_MESSAGE/django.po msgid "DATETIME_FORMAT" msgstr "DATETIME_FORMAT" so the date filter is date:"DATETIME_FORMAT" it would be showed in browser at last : SunPM中国标准时间E中国标准时间0八月E_八月+0800R八月PM中国标准时间 nobody soldier DATETIME_FORMAT 0 0 0 0 0 0
8557 2008-08-26 12:59:52 2009-02-25 19:51:44 2022-03-06 03:42:34.413732 Design decision needed closed Template system     dev duplicate intpoint filter for contrib.humanize for european users would be really useful an intpoint filter in contrib.humanize, here is the necessary code (similar to intcomma) def intpoint(value): """ Converts an integer to a string containing point every three digits. For example, 3000 becomes '3.000' and 45000 becomes '45.000'. """ orig = force_unicode(value) new = re.sub("^(-?\d+)(\d{3})", '\g<1>.\g<2>', orig) if orig == new: return new else: return intpoint(new) intpoint.is_safe = True register.filter(intpoint) hope this would be in 1.0, thanks drakkan nobody drakkan   0 1 0 0 0 0
8562 2008-08-26 18:09:13 2011-09-28 16:12:17 2022-03-06 03:42:35.101521 Accepted closed contrib.admin     dev duplicate OneToOnes + primary_key = True ... fails in Admin This goes back to the primary keys and missing in the Admin forms as hidden fields, but it also effect 2 things . I've brought this up before #7938 for instance, where a slightly different bug was mended. 1) Addition of an element 2) editing a OneToOne directly {{{ #create a simple model from django.db import models class BaseMoo(models.Model): name = models.CharField(max_length = 50) is_moo = models.BooleanField(default = True) class MooOne(models.Model): basemoo = models.OneToOneField(BaseMoo, primary_key = True) is_moo_one = models.BooleanField(default = True) }}} {{{ #create the ADmin from testmod.models import BaseMoo, MooOne from django.contrib import admin class MooOne_Inline(admin.StackedInline): model = MooOne extra = 1 max_num = 1 raw_id_fields = ('basemoo',) class BaseMooOptions(admin.ModelAdmin): inlines = [MooOne_Inline] list_display = ('name', 'is_moo',) class MooOneOptions(admin.ModelAdmin): raw_id_fields = ('basemoo',) list_display = ('basemoo', 'is_moo_one',) admin.site.register(BaseMoo, BaseMooOptions) admin.site.register(MooOne, MooOneOptions) }}} 1) In Admin, try to 'add' a BaseMoo Object. It will give you the option for the Inlined MooOne, but on save the MooOne object is _not_ saved 2) ok a work around (but assumes that MooOne is registered as not an inline like above), so try to add the MooOne directly buy adding one attached to BaseMoo .. 3) Go back to the BaseMoo object, try to edit and save .. boom {{{ Traceback: File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/core/handlers/base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/sites.py" in root 173. return self.model_page(request, *url.split('/', 2)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/views/decorators/cache.py" in _… brosner magneto admin onetoone 0 1 1 1 0 0
8564 2008-08-26 18:35:07 2008-08-31 20:12:41 2022-03-06 03:42:35.410401 Unreviewed closed contrib.admin     dev duplicate newforms-admin doesn't support linking to it via {% url %} or reverse() In the old admin, that was possible to have a link to the admin area in the UI, like: {{{ {% if user.is_staff %} <a href="{% url django.contrib.admin.views.main.index %}">Admin area</a> {% endif %} }}} or even: {{{ <a href="{% url django.contrib.admin.views.main.change_stage "app","model",instance.id %}">Edit instance</a> }}} In newforms-admin, that crashes with: {{{ Reverse for 'src.django.contrib.admin.site.root' not found. }}} I do realize that admin.site is now a Site instance, not a module, that's why {% url %} will never work for it. However, I can't see how to put a link to the admin area now? Currently I'm using the following hack: {{{ #!python urlpatterns = # ... #(r'^admin/(.*)', admin.site.root), (r'^admin/(.*)', 'views.admin_site_root'), # ... def admin_site_root(request, url): return admin.site.root(request, url) }}} and then: {{{ <a href="{% url views.admin_site_root "" %}">Admin</a> }}} which is pretty ugly (since of complete redundancy) but solves the problem. I defenitely think there should be a standard way to pull the admin site urls. I can suggest two approaches: 1. Extend reverse() and {% url %} to recognize/understand bound methods, in particular django.contrib.admin.site.root 2. Under django.contrib.admin.templatetags, create a set of tags like {% admin django.contrib.admin.site %} and {% admin_change_list django.contrib.site "app","model" %} nobody semenov newforms-admin reverse url 0 0 0 0 0 0
8572 2008-08-26 21:04:18 2008-08-26 22:39:45 2022-03-06 03:42:36.604616 Unreviewed closed contrib.admin     dev duplicate Improve flexibility of admin.autodiscover for custom admin sites {{{admin.autodiscover}}} is great, but you cannot customize admin sites. It would be wonderful that you can call autodiscover with a optional {{{site}}} parameter, like this: {{{ #!python # urls.py from django.contrib import admin from yourproject.admin import custom_admin_site admin.autodiscover(site=custom_admin_site) urlpatterns = patterns('', ... ('^admin/(.*)', custom_admin_site.root), }}} I will attach a patch that implement that feature, without backwards incompatibility msaelices msaelices   0 1 0 0 0 0
8548 2008-08-26 00:09:34 2016-01-07 01:58:34 2022-03-06 03:42:33.166125 Accepted closed Core (Management commands) Bug Normal 1.4 fixed Lengthy verbose_name results in fatal mysql 'warning' error during syncdb. {{{ #!python class Thingie(models.Model) #fields go here class Meta: verbose_name = 'A String Greater Than 50 Characters Long, Probably For The Admin' }}} Running 'python manage.py syncdb' results in MySQLdb trying to run the following: {{{ #!sql INSERT INTO `auth_permission` (`name`, `content_type_id`, `codename`) VALUES (%s, %s, %s)(u'A String Greater Than 50 Characters Long, Probably For The Admin', 11, u'add_thingie') }}} The field `name` has a length restriction of 50 characters. This results in a warning 'error' being generated (_mysql_exceptions.Warning: Data truncated for column 'name' at row 1) but no further useful information. This also halts syncdb, which is also called during the test suite. Suggestions (since I'm nowhere near qualified to contribute, yet): - Maybe just catch the warning and ignore it? This seems to be a display-only field, so it probably won't hurt. - Or maybe catch the warning and explain the cause? - Model validator could complain about verbose_name being too long? - Increase the size of the field? - Maybe just let google index this ticket so that the next person to google the error sees why it happened? {{{ Traceback (most recent call last): File "manage.py", line 11, in <module> execute_manager(settings) File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/__init__.py", line 334, in execute_manager utility.execute() File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/__init__.py", line 295, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py", line 77, in run_from_argv self.execute(*args, **options.__dict__) File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py", line 96, in execute output = self.handle(*args, **options) File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py", line 178, in… marcelor samt@darkhorse.com   0 1 1 0 0 0
8551 2008-08-26 04:15:55 2009-02-21 07:29:21 2022-03-06 03:42:33.581527 Ready for checkin closed Testing framework     dev fixed Add REMOTE_ADDR: '127.0.0.1' to TestClient environment by default The fake environment django.test.client.Client sets up is missing REMOTE_ADDR. It could be very safely and accurately defaulted to localhost (127.0.0.1). Luckily this issue is very easy to work around when instantiating the test Client: {{{ c = Client(REMOTE_ADDR='127.0.0.1') }}} ericholscher schmichael   0 1 0 0 0 0
8552 2008-08-26 07:49:41 2011-09-28 16:12:17 2022-03-06 03:42:33.727914 Unreviewed closed contrib.auth     dev fixed Use the LOGIN_REDIRECT_URL in auth test views Use the LOGIN_REDIRECT_URL setting in the login method instead of the hard coded '/accounts/profile/' to respect user settings. nobody aeby auth test views LOGIN_REDIRECT_URL 0 1 0 0 0 0
8554 2008-08-26 11:00:29 2011-09-28 16:12:17 2022-03-06 03:42:33.998309 Accepted closed contrib.comments     dev fixed Comment object_pk isn't correctly cast to text for lookups The title says it all... (http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/models.py#L22) Postgres throws a nice error: {{{ Caught an exception while rendering: operator does not exist: text = integer LINE 1: ...public" = true AND "django_comments"."object_pk" = 139 AND... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. }}} nobody apollo13   0 0 0 0 0 0
8555 2008-08-26 11:47:22 2011-09-28 16:12:17 2022-03-06 03:42:34.141287 Accepted closed Documentation     dev fixed comments documentation issues: get_comment_form raising argument errors in comments.py the documentation @ http://docs.djangoproject.com/en/dev/ref/contrib/comments/#notes-on-the-comment-form says to simply use {{{ {% get_comment_form for [object] %} }}} as the documentation stands it doesn't seem like it would work (i.e. tripping the handle_token method). once i added the 'as x' arguments it worked. jacob imacqueen comments get_comment_form 0 0 0 0 0 0
8556 2008-08-26 12:20:07 2011-09-28 16:12:17 2022-03-06 03:42:34.277215 Accepted closed Forms     dev fixed models.CommaSeperatedIntegerField doesn't return a forms field of any use CommaSeperatedIntegerField just returns a normal charfield, which obviously preforms no validation that it matches the purpose of the field. nobody Alex   0 1 0 0 0 0
8558 2008-08-26 13:04:45 2011-09-28 16:12:17 2022-03-06 03:42:34.546453 Accepted closed Documentation     dev fixed "from django.db import models" missing in tutorial02 The 2nd example in section "Adding related objects" in tutorial02 (multiple choices when adding a poll) should be amended by adding "from django.db import models". nobody Jerzy.Ludwichowski@uni.torun.pl   0 0 0 0 0 0
8559 2008-08-26 16:44:09 2019-08-30 06:45:44 2022-03-06 03:42:34.681286 Accepted closed Documentation     dev fixed new comment.get_absolute_url returns '' Just upgraded to the new comments system (sort of peaved that headlines went away, but hey) and {{ comment.get_absolute_url }} now returns ''. I can get comment.content_object.get_absolute_url with no problem. nobody TrevorFSmith     0 0 0 0  
8560 2008-08-26 17:03:57 2011-09-28 16:12:17 2022-03-06 03:42:34.822350 Accepted closed Documentation     dev fixed Small typo in tutorial 2 A followup to #8392 and [8432], sorry for not noticing it was also present in part 2 of the tutorial. nobody ramiro   0 1 0 0 0 0
8561 2008-08-26 18:05:32 2014-03-05 23:15:40 2022-03-06 03:42:34.953106 Accepted closed contrib.admin New feature Normal dev fixed Patсh for Lithuanian support to Javascript slug creation Path for Lithuanian support to Javascript slug creation in django/contrib/admin/media/js/urlify.js When slug is auto-generated some Lithuanian's letters are missing. So there is a patch for quick fix. Actualy I am not very happy with current auto-generated slug creation, but for quick result it will do the trick. nobody petraszd LITHUANIAN_MAP 0 1 1 0 0 0
8566 2008-08-26 19:35:10 2011-09-28 16:12:17 2022-03-06 03:42:35.681539 Unreviewed closed Core (Other)     dev fixed mark_safe not propagating from widgets to templates I submitted the below to Django Users and Malcolm Tredinnick suggested I open a ticket. Essentially, when making custom widgets, I encountered a problem wherein despite marking things as safe strings, when I tried to render my forms in a template, they were beings escaped. Turning off auto escaping and piping to the safe filter weren't working, and I found that they were being escaped at a very low level. Namely, there is a call in the Widget.render function to django.forms.util.flatatt that is escaping everything. I don't know if this by design or not, but given the number of calls to mark_safe in the Widget module, I suspect not. It is preventing me from, for example, making JS function calls in widgets that require string arguments. I hope this helps. Regards, Alex. ==== Hi there, I have been trying to get a function call into a widget argument, but have not been able to at the template level, because it would appear that my safe_strings are being escaped somewhere down in the framework. I have created a widget and mark_safe'd an attribute value, but no matter what, since it's pre-escaped by the time it bubbles up to the template level, I can't not escape it (well... I could use an html library to de-escape it, but that seems kludgy). I've traced the execution and found the culprit to be the django.forms.util.flatatt function. That is: {{{ from django import forms from django.utils.safestring import mark_safe class MyWidget(forms.TextInput): def __init__(self, *args, **kwargs): attrs = kwargs.setdefault('attrs', {}) attrs['safe_string'] = mark_safe("will o' the wisp") attrs['normal_string'] = "cat o' nine tails" super(MyWidget, self).__init__(*args, **kwargs) w = MyWidget() w.render("field_name", "") #=> u'<input normal_string="cat o&#39; nine tails" type="text" name="field_name" safe_string="will o&#39; the wisp" />' }}} You can see that both the unsafe and safe strings were escaped. I don't know if this is int… nobody agirman mark_safe, safe string, escape, escaping, widgets 0 0 0 0 0 0
8567 2008-08-26 19:47:08 2010-08-07 07:58:58 2022-03-06 03:42:35.838662 Ready for checkin closed Documentation     dev fixed Formwizard documentation does not clearly describe how to specify forms When I read the Form Wizard doc, it took me a lots of searching before the “glue” between Form and FormWizard showed up in the urls.py example a long way down in the document. Why don't put the urls.py much earlier in the document and/or describe the connection. ElliottM ClaesBas Form wizard 0 1 0 0 0 0
8568 2008-08-26 20:17:31 2011-09-28 16:12:17 2022-03-06 03:42:35.987603 Accepted closed Documentation     dev fixed Remove note about missing signals documentation in models doc. I've attached a patch nobody msaelices   0 1 0 0 0 0
8569 2008-08-26 20:21:46 2011-09-28 16:12:17 2022-03-06 03:42:36.143062 Unreviewed closed Uncategorized     dev fixed Admin fieldsets can cause "'str' object has no attribute '_default_manager'' under mod_wsgi As reported here: http://groups.google.com/group/django-users/browse_thread/thread/da39ac4b1e5c1751# (and earlier but never recreated/isolated), under some circumstances a fieldsets definition in a !ModelAdmin definition can cause the exception: 'str' object has no attribute '_default_manager' Today's poster isolated the problem to mod_wsgi, and I was able to recreate with an example project he sent to me. There are two apps: catalogue and simplepromo (listed in that order in INSTALLED_APPS, reversing them didn't change anything). catalogue has a single model in models.py: {{{ class Maker(models.Model): dummy = models.CharField(blank=True, max_length=80) def __unicode__(self): return self.dummy }}} simplepromo (a simplified version of what Maciek sent me), also has a single model in models.py: {{{ class SimplePromo(models.Model): name = models.CharField(blank=False, max_length=250, help_text="Displayed in overlay tooltip") slug = models.SlugField() promo_maker = models.ForeignKey("catalogue.Maker", null=True, blank=False) def __unicode__(self): return self.name }}} and an admin.py file: {{{ from django.contrib import admin from simplepromo.models import * class SimplePromoAdmin(admin.ModelAdmin): prepopulated_fields = {'slug': ('name',)} fieldsets = ( ("Base", { "fields": ["name","slug","promo_maker",], }), ) admin.site.register(SimplePromo, SimplePromoAdmin) }}} The call to admin.autodiscover() in urls.py is what generates the exception. If I remove the catch/transform to !ImproperlyConfigured done by urlresolvers.py (ref #7524) I can get the actual traceback: {{{ Environment: Request Method: GET Request URL: http://localhost/admin/ Django Version: 1.0-beta_1-SVN-8582 Python Version: 2.5.2 Installed Applications: ['django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.humanize', 'django.contrib.markup', … mtredinnick kmtracey   0 0 0 0 0 0
8570 2008-08-26 20:26:12 2008-09-14 07:04:40 2022-03-06 03:42:36.286147 Ready for checkin closed contrib.formtools     dev fixed Wrong indentation style in django/contrib/formtools/utils.py This file has 8 space padding. This should be 4, as [http://docs.djangoproject.com/en/dev/internals/contributing/#coding-style contributing docs] said nobody msaelices   0 1 0 0 0 0
8573 2008-08-26 21:24:34 2008-09-17 05:15:02 2022-03-06 03:42:36.735178 Unreviewed closed django-admin.py inspectdb     dev fixed inspectdb doesn't make use of FK and uniqueness information when the column name has upper case characters This was reported as an [http://code.google.com/p/django-pyodbc/issues/detail?id=12 issue] in the [http://code.google.com/p/django-pyodbc/ django-pyodbc] project but after some debugging turned to be a bug in `inspectdb`. Problem is it doesn't use the real database column name but rather a derived `att_name` value (used to represent the final Django model field name) when looking up the meta information about FK and indexes the DB backend provides via the `DatabaseIntrospection.get_relations()` method. This fails for database engines that are case sensitive (i.e. all but Oracle). Also, because of a related problem, it can attempt to use that same innaccurate `att_name` instead of the real table column when trying to introspect the `db_column` field option. Example: This `models.py` file: {{{ #!python class Magazine(models.Model): ident = models.AutoField(primary_key=True, db_column='Ident') class ReaderComment(models.Model): text = models.TextField(max_length=30, primary_key=True, db_column='reader_comment') }}} when `syncdb`ed to the database (sqlite3) and the introspected back gives: {{{ #!python class IntrosBugMagazine(models.Model): ident = models.IntegerField() class Meta: db_table = u'intros_bug_magazine' class IntrosBugReadercomment(models.Model): reader_comment = models.TextField(primary_key=True) class Meta: db_table = u'intros_bug_readercomment' }}} Note the `ident` field of the `Magazine` model is missing: a. The `'primary_key=True'`option(that's because the `syncdb` command didn't make use of the `'primary_key': True` info the database backend introspection support code correctly returned for it.) b. The `db_column='Ident'` option nobody ramiro   0 1 0 0 0 0
8574 2008-08-26 21:40:47 2008-09-17 04:56:05 2022-03-06 03:42:36.880202 Unreviewed closed Contrib apps     dev fixed Sitemap should be a new style class django.contrib.sitemaps.Sitemap should be a new-style class deriving from object. nobody hvendelbo   0 0 0 0 0 0
8575 2008-08-26 22:14:05 2011-09-28 16:12:17 2022-03-06 03:42:37.060439 Accepted closed Database layer (models, ORM)     dev fixed get_or_create testcase fails under MySQL As mentioned here: http://groups.google.com/group/django-developers/browse_thread/thread/806b0168b150c8d4?hl=en It isn't immediately apparent to me how to easily fix this for MySQL (Oracle guys had a pre-existing routine where they could transform one error to another -- mysql backend doesn't seem to have that). Opening this so it's not forgotten and someone can decide what to do about it and whether it needs to be done before 1.0. nobody kmtracey   0 0 0 0 0 0
8577 2008-08-26 22:43:31 2011-09-28 16:12:17 2022-03-06 03:42:37.379426 Unreviewed closed contrib.admin     dev fixed Admin raises UnboundLocalError {{{ Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/django/core/handlers/base.py", line 86, in get_response response = callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.3/site-packages/django/contrib/admin/sites.py", line 175, in root return self.app_index(request, url) File "/usr/lib/python2.3/site-packages/django/contrib/admin/sites.py", line 392, in app_index app_dict = { UnboundLocalError: local variable 'model_dict' referenced before assignment }}} Code added in [8474] for #1390 produced this error. The untested patch should fix this. nobody evenrik   0 1 0 0 0 0
8578 2008-08-26 22:55:41 2008-08-28 12:22:33 2022-03-06 03:42:37.557976 Ready for checkin closed Documentation     dev fixed Typo in testing docs, that also makes bad highlight The incorrect typo was in this URL: http://docs.djangoproject.com/en/dev/topics/testing/#id1 nobody msaelices   0 1 0 0 0 0
8579 2008-08-26 23:08:22 2014-01-20 02:50:58 2022-03-06 03:42:37.719748 Accepted closed contrib.admin New feature Normal dev fixed Move admin validation to only run as part of "validate" management command Normal practice within Django is that validation code is only run when requested, since code is correct more often than it is wrong. The admin validation code runs every time a URL conf file is imported and `DEBUG = True`. It should be moved to be part of the `django-admin.py validate` run. This isn't entirely trivial, since it's a bit tied up with admin registration and that's an issue when `admin.autodiscover()` is used. nobody mtredinnick   0 0 0 0 0 0
8580 2008-08-26 23:10:29 2008-09-07 23:08:02 2022-03-06 03:42:37.865574 Ready for checkin closed Documentation     dev fixed Missing links to django source files in settings doc.   nobody msaelices   0 1 0 0 0 0
8581 2008-08-26 23:28:44 2011-09-28 16:12:17 2022-03-06 03:42:38.012703 Ready for checkin closed Documentation     dev fixed Obsolete command in whatsnext docs Now, source docs are in several directories. In whatnext.txt doc there are a {{{grep}}} command now obsolete. Please see the patch. jacob msaelices   0 1 0 0 0 0
8563 2008-08-26 18:14:25 2008-08-27 17:03:01 2022-03-06 03:42:35.269436 Accepted closed GIS     dev invalid [gis] Current locale considered when converting a geometry to WKT I'm getting a OGRGeometry Exception intermittently, when saving a form. After debuging the code I noticed that the WKT string generated from geometries were taking the current locale into account, thus raising the Exceptions due to a bad WKT string representation. Here goes an example: {{{ >>> import locale >>> from django.contrib.gis.geos import Point >>> p = Point(-45.23, -23.15) >>> p.wkt 'POINT (-45.2299999999999969 -23.1499999999999986)' >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, ('pt_BR','UTF-8')) 'pt_BR.UTF8' >>> p.wkt 'POINT (-45,2299999999999969 -23,1499999999999986)' }}} Notice de comma "," for decimal separator in the last output. It must be something in the GEOS C library and in this case should be fixed there, but maybe it should be avoided reseting de locale before calling the C routine and restoring the locale to what it was just after. I think the reason this problem was not always happening is related to the some setlocale thread safety issue. I was using the wkt from the geometry in a custom form PointField to get the coordinate transformed to the desired srid. jbronn luizvital <luiz.vital@gmail.com> geos locale 0 0 0 0 0 0
8553 2008-08-26 07:58:36 2011-08-18 01:42:47 2022-03-06 03:42:33.862841 Unreviewed closed Database layer (models, ORM) Uncategorized Normal dev wontfix Add soundex support to MySQL (and others) I needed to use MySQL sounds like support in an app recently and found it to be seemingly easy to add support for this. Not sure what the policy is about database-specific calls, but at least both postgres, sqlite, and oracle all appear to support some form of soundex. http://www.postgresql.org/docs/8.3/static/fuzzystrmatch.html http://www.sqlite.org/lang_corefunc.html http://www.techonthenet.com/oracle/functions/soundex.php I've attached my changes for MySQL. nobody dacort <django@sevicron.com> mysql, soundex 0 0 0 0 0 0
8565 2008-08-26 19:15:31 2012-12-16 15:15:49 2022-03-06 03:42:35.545120 Someday/Maybe closed contrib.comments Cleanup/optimization Normal dev wontfix Comments should use object_id instead of object_pk `django.contrib.comments.models.BaseCommentAbstractModel` uses `object_pk` to create a generic relation I may be missing something, but straying from the expected and documented default of `object_id` seems to only create extra confusion. I noticed this when trying to add a `GenericTabularInline` nobody baumer1122 comments generic object_pk object_id 0 0 0 0 0 0
8576 2008-08-26 22:30:47 2021-11-23 15:54:31 2022-03-06 03:42:37.222924 Design decision needed closed Database layer (models, ORM) Uncategorized Normal dev wontfix Multiple AutoFields in a model Got the assertions failed recently: {{{ File "C:\Projects\houserules\www\hrdb\events\hrpercustomerobject.py", line 14, in <module> class HRPerCustomerObject(models.Model): File "C:\Projects\houserules\www\hrdb\events\hrpercustomerobject.py", line 37, in HRPerCustomerObject id_percustomer = models.AutoField ( 'Per-customer ID' ) File "C:\Projects\houserules\www\django\db\models\fields\__init__.py", line 425, in __init__ assert kwargs.get('primary_key', False) is True, "%ss must have primary_key=True." % self.__class__.__name__ AssertionError: AutoFields must have primary_key=True. make: *** [_reset] Error 1 }}} and {{{ File "C:\Projects\houserules\www\django\db\models\options.py", line 117, in _prepare model.add_to_class('id', auto) File "C:\Projects\houserules\www\django\db\models\base.py", line 139, in add_to_class value.contribute_to_class(cls, name) File "C:\Projects\houserules\www\django\db\models\fields\__init__.py", line 459, in contribute_to_class assert not cls._meta.has_auto_field, "A model can't have more than one AutoField." AssertionError: A model can't have more than one AutoField. make: *** [_reset] Error 1 }}} Depending on the logic and the scenario, it may be really worthy to have several AutoFields in a model (for example, when one or both of them in some cases is controlled manually), one of which will definitely not be a primary key. I roughly described one of possible scenarios in [http://oebfare.com/logger/django/2008/08/26/ IRC], though this may be not the only one. Please note that the databases itself do not imply such behaviour (auto_increment field in MySQL does not imply a primary key, neither SERIAL field in PostgreSQL does), so it is unsafe and overrestrictive to add such a limitation in Django. The existing documentation on AutoField also does not imply it should be used for primary keys only. My proposal is to withdraw such a limitation; seems that it is only required to remove two assert lines from the code�(well, and … nobody honeyman multiple autofield 0 0 0 0 0 0
8571 2008-08-26 21:00:41 2010-01-16 19:13:22 2022-03-06 03:42:36.444864 Unreviewed closed contrib.comments     1.0 worksforme comment framework throws obscure exception in {% comment_form_target %} Today I updated Django to trunk version 8580, and I saw new comments framework. I updated my app acording to docs, made sql data migration but it looks like new comments are not working. I am getting: Caught an exception while rendering: Reverse for '<function post_comment at 0x01894770>' not found. when I try to call render_comment_form ,or get_comment_form, and all becasue of {% comment_form_target %}, this seams to be the problem. It is some kind of strange bug, Has someone some kind of clue what I can do to fix this. Thanx, Below is original trace: Original Traceback (most recent call last): File "D:\dev\django-svn\django\template\debug.py", line 71, in render_node result = node.render(context) File "D:\dev\django-svn\django\template\__init__.py", line 876, in render return func(*resolved_vars) File "D:\dev\django-svn\django\contrib\comments\templatetags \comments.py", line 245, in comment_form_target return comments.get_form_target() File "D:\dev\django-svn\django\contrib\comments\__init__.py", line 43, in get_form_target return urlresolvers.reverse("django.contrib.comments.views.comments.post_comment") File "D:\dev\django-svn\django\core\urlresolvers.py", line 307, in reverse *args, **kwargs))) File "D:\dev\django-svn\django\core\urlresolvers.py", line 291, in reverse raise NoReverseMatch("Reverse for '%s' not found." % lookup_view) NoReverseMatch: Reverse for '<function post_comment at 0x01894770>' not found.Request Method: GET Request URL: http://localhost/article/novi/ Exception Type: TemplateSyntaxError Exception Value: Caught an exception while rendering: Reverse for '<function post_comment at 0x01894770>' not found. Original Traceback (most recent call last): File "D:\dev\django-svn\django\template\debug.py", line 71, in render_node result = node.render(context) File "D:\dev\django-svn\django\template\__init__.py", line 876, in render r… nobody slavus@gmail.com comment, comment_form_target 0 0 0 0 0 0

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE tickets (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );