{"id": 8549, "created": "2008-08-26 00:38:30", "changetime": "2008-08-26 00:41:52", "last_pulled_from_trac": "2022-03-06 03:42:33.293323", "stage": "Unreviewed", "status": "closed", "component": "Core (Serialization)", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "Fields added via the extra() QuerySet modifier are not outputted when QuerySet is run through serializer", "description": "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.\r\n\r\nThe context in which I discovered this bug, brief:\r\n\r\nI 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:\r\n\r\n{{{\t\r\nentries = Entry.objects.extra(select={'distance': \"SQRT(POW((locations.lat-%s),2) + POW((locations.lon-%s),2))\"}, select_params=(str(centerLat), str(centerLng)))\r\nentries = entries.extra(order_by = ['distance'])[:5]\r\n}}}\r\n\r\nThis works. {{{entries[0].distance}}} returns a float correctly, for example.\r\n\r\nThe bug arises when this {{{QuerySet}}} is serialized and output, as follows:\r\n\r\n{{{\r\nfrom django.core import serializers\r\n\r\njson_serializer = serializers.get_serializer(\"json\")()\r\njson_serializer.serialize(entries, ensure_ascii=False, stream=response)\r\n}}}\r\n\r\nThe 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\r\n\r\nI 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.", "owner": "nobody", "reporter": "Jim Dalton <jim.dalton@furrybrains.com>", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8550, "created": "2008-08-26 03:05:13", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:33.438088", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "date filter  can't right work in object_history.html.", "description": "object_history.html:30\r\n<th scope=\"row\">{{ action.action_time|date:_(\"DATETIME_FORMAT\") }}</th>\r\n\r\n_(\"DATETIME_FORMAT\") translate in the zh_CN/LC_MESSAGE/django.po\r\nmsgid \"DATETIME_FORMAT\"\r\nmsgstr \"DATETIME_FORMAT\"\r\n\r\nso the date filter is\r\ndate:\"DATETIME_FORMAT\"\r\n\r\nit would be showed in browser at last :\r\nSunPM\u4e2d\u56fd\u6807\u51c6\u65f6\u95f4E\u4e2d\u56fd\u6807\u51c6\u65f6\u95f40\u516b\u6708E_\u516b\u6708+0800R\u516b\u6708PM\u4e2d\u56fd\u6807\u51c6\u65f6\u95f4\r\n", "owner": "nobody", "reporter": "soldier", "keywords": "DATETIME_FORMAT", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8557, "created": "2008-08-26 12:59:52", "changetime": "2009-02-25 19:51:44", "last_pulled_from_trac": "2022-03-06 03:42:34.413732", "stage": "Design decision needed", "status": "closed", "component": "Template system", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "intpoint filter for contrib.humanize", "description": "for european users would be really useful an intpoint filter in contrib.humanize,\r\n\r\nhere is the necessary code (similar to intcomma)\r\n\r\ndef intpoint(value):\r\n    \"\"\"\r\n    Converts an integer to a string containing point every three digits.\r\n    For example, 3000 becomes '3.000' and 45000 becomes '45.000'.\r\n    \"\"\"\r\n    orig = force_unicode(value)\r\n    new = re.sub(\"^(-?\\d+)(\\d{3})\", '\\g<1>.\\g<2>', orig)\r\n    if orig == new:\r\n        return new\r\n    else:\r\n        return intpoint(new)\r\nintpoint.is_safe = True\r\nregister.filter(intpoint)\r\n\r\nhope this would be in 1.0,\r\n\r\nthanks\r\ndrakkan\r\n", "owner": "nobody", "reporter": "drakkan", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8562, "created": "2008-08-26 18:09:13", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:35.101521", "stage": "Accepted", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "OneToOnes + primary_key = True ...  fails in Admin", "description": "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.\r\n\r\n1) Addition of an element\r\n2) editing a OneToOne directly\r\n\r\n{{{\r\n#create a simple model\r\nfrom django.db import models\r\n\r\nclass BaseMoo(models.Model):\r\n\tname = models.CharField(max_length = 50)\r\n\tis_moo = models.BooleanField(default = True)\r\n\r\n\r\nclass MooOne(models.Model):\r\n\tbasemoo = models.OneToOneField(BaseMoo, primary_key = True)\r\n\tis_moo_one = models.BooleanField(default = True)\r\n\r\n}}}\r\n\r\n{{{ \r\n#create the ADmin\r\nfrom testmod.models import BaseMoo, MooOne\r\n\r\nfrom django.contrib import admin\r\n\r\nclass MooOne_Inline(admin.StackedInline):\r\n\tmodel = MooOne\r\n\textra = 1\r\n\tmax_num = 1\r\n\traw_id_fields = ('basemoo',)\r\n\t\r\nclass BaseMooOptions(admin.ModelAdmin):\r\n\tinlines = [MooOne_Inline]\r\n\tlist_display = ('name', 'is_moo',)\r\n\r\nclass MooOneOptions(admin.ModelAdmin):\r\n\traw_id_fields = ('basemoo',)\r\n\tlist_display = ('basemoo', 'is_moo_one',)\r\n\r\nadmin.site.register(BaseMoo, BaseMooOptions)\r\nadmin.site.register(MooOne, MooOneOptions)\r\n\r\n}}}\r\n\r\n1) 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\r\n\r\n2) 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 .. \r\n\r\n3) Go back to the BaseMoo object, try to edit and save .. boom\r\n\r\n{{{\r\nTraceback:\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/core/handlers/base.py\" in get_response\r\n  86.                 response = callback(request, *callback_args, **callback_kwargs)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/sites.py\" in root\r\n  173.                 return self.model_page(request, *url.split('/', 2))\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/views/decorators/cache.py\" in _wrapped_view_func\r\n  44.         response = view_func(request, *args, **kwargs)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/sites.py\" in model_page\r\n  192.         return admin_obj(request, rest_of_url)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/options.py\" in __call__\r\n  191.             return self.change_view(request, unquote(url))\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/db/transaction.py\" in _commit_on_success\r\n  238.                 res = func(*args, **kw)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/options.py\" in change_view\r\n  573.                     self.save_formset(request, form, formset, change=True)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/options.py\" in save_formset\r\n  373.         formset.save()\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/forms/models.py\" in save\r\n  280.         return self.save_existing_objects(commit) + self.save_new_objects(commit)\r\nFile \"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/forms/models.py\" in save_existing_objects\r\n  294.             obj = existing_objects[form.cleaned_data[self.model._meta.pk.attname]]\r\n\r\nException Type: KeyError at /testmod/basemoo/34/\r\nException Value: 'basemoo_id'\r\n}}}\r\n\r\n4) Ok so now go back to the MooOne raw object and try to edit it.  Well you can, except now the raw_id_fields of 'BaseMoo\" is NOT filled in automatically, (If i turn off raw_id_fields, the select box does _not_ choose the current BaseMoo Object).  Meaning the 'save' will fail until you pick the old object again.\r\n\r\nI Imagine all of these little issues are related to the primary_key vs autofield display bits in admin.\r\n\r\n", "owner": "brosner", "reporter": "magneto", "keywords": "admin onetoone", "easy": 0, "has_patch": 1, "needs_better_patch": 1, "needs_tests": 1, "needs_docs": 0, "ui_ux": 0}
{"id": 8564, "created": "2008-08-26 18:35:07", "changetime": "2008-08-31 20:12:41", "last_pulled_from_trac": "2022-03-06 03:42:35.410401", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "newforms-admin doesn't support linking to it via {% url %} or reverse()", "description": "In the old admin, that was possible to have a link to the admin area in the UI, like:\r\n{{{\r\n{% if user.is_staff %}\r\n    <a href=\"{% url django.contrib.admin.views.main.index %}\">Admin area</a>\r\n{% endif %}\r\n}}}\r\n\r\nor even:\r\n{{{\r\n<a href=\"{% url django.contrib.admin.views.main.change_stage \"app\",\"model\",instance.id %}\">Edit instance</a>\r\n}}}\r\n\r\nIn newforms-admin, that crashes with:\r\n{{{\r\nReverse for 'src.django.contrib.admin.site.root' not found.\r\n}}}\r\n\r\nI do realize that admin.site is now a Site instance, not a module, that's why {% url %} will never work for it.\r\nHowever, I can't see how to put a link to the admin area now?\r\n\r\nCurrently I'm using the following hack:\r\n{{{\r\n#!python\r\nurlpatterns = # ...\r\n        #(r'^admin/(.*)', admin.site.root),\r\n\t(r'^admin/(.*)', 'views.admin_site_root'),\r\n\r\n# ...\r\n\r\ndef admin_site_root(request, url):\r\n\treturn admin.site.root(request, url)\r\n}}}\r\nand then:\r\n{{{\r\n<a href=\"{% url views.admin_site_root \"\" %}\">Admin</a>\r\n}}}\r\n\r\nwhich is pretty ugly (since of complete redundancy) but solves the problem.\r\n\r\nI defenitely think there should be a standard way to pull the admin site urls. I can suggest two approaches:\r\n\r\n1. Extend reverse() and {% url %} to recognize/understand bound methods, in particular django.contrib.admin.site.root\r\n\r\n2. 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\" %}", "owner": "nobody", "reporter": "semenov", "keywords": "newforms-admin reverse url", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8572, "created": "2008-08-26 21:04:18", "changetime": "2008-08-26 22:39:45", "last_pulled_from_trac": "2022-03-06 03:42:36.604616", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "Improve flexibility of admin.autodiscover for custom admin sites", "description": "{{{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:\r\n\r\n{{{\r\n#!python\r\n\r\n# urls.py\r\n\r\nfrom django.contrib import admin\r\n\r\nfrom yourproject.admin import custom_admin_site\r\n\r\nadmin.autodiscover(site=custom_admin_site)\r\n\r\nurlpatterns = patterns('',\r\n    ...\r\n    ('^admin/(.*)', custom_admin_site.root),\r\n}}}\r\n\r\nI will attach a patch that implement that feature, without backwards incompatibility", "owner": "msaelices", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8548, "created": "2008-08-26 00:09:34", "changetime": "2016-01-07 01:58:34", "last_pulled_from_trac": "2022-03-06 03:42:33.166125", "stage": "Accepted", "status": "closed", "component": "Core (Management commands)", "type": "Bug", "severity": "Normal", "version": "1.4", "resolution": "fixed", "summary": "Lengthy verbose_name results in fatal mysql 'warning' error during syncdb.", "description": "{{{\r\n#!python\r\nclass Thingie(models.Model)\r\n#fields go here\r\n  class Meta:\r\n    verbose_name = 'A String Greater Than 50 Characters Long, Probably For The Admin'\r\n}}}\r\n\r\nRunning 'python manage.py syncdb' results in MySQLdb trying to run the following:\r\n{{{\r\n#!sql\r\nINSERT 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')\r\n}}}\r\n\r\nThe 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.\r\n\r\nSuggestions (since I'm nowhere near qualified to contribute, yet):\r\n - Maybe just catch the warning and ignore it?  This seems to be a display-only field, so it probably won't hurt.\r\n - Or maybe catch the warning and explain the cause?\r\n - Model validator could complain about verbose_name being too long?\r\n - Increase the size of the field?\r\n - Maybe just let google index this ticket so that the next person to google the error sees why it happened?\r\n\r\n{{{\r\nTraceback (most recent call last):\r\n  File \"manage.py\", line 11, in <module>\r\n    execute_manager(settings)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/__init__.py\", line 334, in execute_manager\r\n    utility.execute()\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/__init__.py\", line 295, in execute\r\n    self.fetch_command(subcommand).run_from_argv(self.argv)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py\", line 77, in run_from_argv\r\n    self.execute(*args, **options.__dict__)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py\", line 96, in execute\r\n    output = self.handle(*args, **options)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/base.py\", line 178, in handle\r\n    return self.handle_noargs(**options)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/commands/syncdb.py\", line 101, in handle_noargs\r\n    emit_post_sync_signal(created_models, verbosity, interactive)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/core/management/sql.py\", line 205, in emit_post_sync_signal\r\n    interactive=interactive)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/dispatch/dispatcher.py\", line 148, in send\r\n    response = receiver(signal=self, sender=sender, **named)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/contrib/auth/management/__init__.py\", line 28, in create_permissions\r\n    defaults={'name': name, 'content_type': ctype})\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/manager.py\", line 84, in get_or_create\r\n    return self.get_query_set().get_or_create(**kwargs)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/query.py\", line 331, in get_or_create\r\n    obj.save()\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/base.py\", line 282, in save\r\n    self.save_base(force_insert=force_insert, force_update=force_update)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/base.py\", line 356, in save_base\r\n    result = manager._insert(values, return_id=update_pk)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/manager.py\", line 126, in _insert\r\n    return insert_query(self.model, values, **kwargs)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/query.py\", line 884, in insert_query\r\n    return query.execute_sql(return_id)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/sql/subqueries.py\", line 308, in execute_sql\r\n    cursor = super(InsertQuery, self).execute_sql(None)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/models/sql/query.py\", line 1641, in execute_sql\r\n    cursor.execute(sql, params)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/django/db/backends/util.py\", line 20, in execute\r\n    return self.cursor.execute(sql, params)\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/MySQL_python-1.2.2-py2.5-macosx-10.5-i386.egg/MySQLdb/cursors.py\", line 168, in execute\r\n  File \"/usr/local/python-x/lib/python2.5/site-packages/MySQL_python-1.2.2-py2.5-macosx-10.5-i386.egg/MySQLdb/cursors.py\", line 82, in _warning_check\r\n  File \"/usr/local/python-x/lib/python2.5/warnings.py\", line 62, in warn\r\n    globals)\r\n  File \"/usr/local/python-x/lib/python2.5/warnings.py\", line 102, in warn_explicit\r\n    raise message\r\n_mysql_exceptions.Warning: Data truncated for column 'name' at row 1\r\n}}}", "owner": "marcelor", "reporter": "samt@darkhorse.com", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 1, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8551, "created": "2008-08-26 04:15:55", "changetime": "2009-02-21 07:29:21", "last_pulled_from_trac": "2022-03-06 03:42:33.581527", "stage": "Ready for checkin", "status": "closed", "component": "Testing framework", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Add REMOTE_ADDR: '127.0.0.1' to TestClient environment by default", "description": "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).\r\n\r\nLuckily this issue is very easy to work around when instantiating the test Client:\r\n\r\n{{{\r\nc = Client(REMOTE_ADDR='127.0.0.1')\r\n}}}", "owner": "ericholscher", "reporter": "schmichael", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8552, "created": "2008-08-26 07:49:41", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:33.727914", "stage": "Unreviewed", "status": "closed", "component": "contrib.auth", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Use the LOGIN_REDIRECT_URL in auth test views", "description": "Use the LOGIN_REDIRECT_URL setting in the login method instead of the hard coded '/accounts/profile/' to respect user settings.", "owner": "nobody", "reporter": "aeby", "keywords": "auth test views LOGIN_REDIRECT_URL", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8554, "created": "2008-08-26 11:00:29", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:33.998309", "stage": "Accepted", "status": "closed", "component": "contrib.comments", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Comment object_pk isn't correctly cast to text for lookups", "description": "The title says it all... (http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/models.py#L22) Postgres throws a nice error:\r\n{{{\r\n   Caught an exception while rendering: operator does not exist: text = integer\r\nLINE 1: ...public\" = true  AND \"django_comments\".\"object_pk\" = 139  AND...\r\n                                                             ^\r\nHINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.\r\n}}}", "owner": "nobody", "reporter": "apollo13", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8555, "created": "2008-08-26 11:47:22", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:34.141287", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "comments documentation issues: get_comment_form raising argument errors in comments.py", "description": "the documentation @ http://docs.djangoproject.com/en/dev/ref/contrib/comments/#notes-on-the-comment-form says to simply use\r\n\r\n{{{\r\n{% get_comment_form for [object] %}\r\n}}}\r\n\r\n\r\nas the documentation stands it doesn't seem like it would work (i.e. tripping the handle_token method).\r\n\r\nonce i added the 'as x' arguments it worked.", "owner": "jacob", "reporter": "imacqueen", "keywords": "comments get_comment_form", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8556, "created": "2008-08-26 12:20:07", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:34.277215", "stage": "Accepted", "status": "closed", "component": "Forms", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "models.CommaSeperatedIntegerField doesn't return a forms field of any use", "description": "CommaSeperatedIntegerField just returns a normal charfield, which obviously preforms no validation that it matches the purpose of the field.", "owner": "nobody", "reporter": "Alex", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8558, "created": "2008-08-26 13:04:45", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:34.546453", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "\"from django.db import models\" missing in tutorial02", "description": "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\".", "owner": "nobody", "reporter": "Jerzy.Ludwichowski@uni.torun.pl", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8559, "created": "2008-08-26 16:44:09", "changetime": "2019-08-30 06:45:44", "last_pulled_from_trac": "2022-03-06 03:42:34.681286", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "new comment.get_absolute_url returns ''", "description": "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.", "owner": "nobody", "reporter": "TrevorFSmith", "keywords": null, "easy": null, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": null}
{"id": 8560, "created": "2008-08-26 17:03:57", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:34.822350", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Small typo in tutorial 2", "description": "A followup to #8392 and [8432], sorry for not noticing it was also present in part 2 of the tutorial.", "owner": "nobody", "reporter": "ramiro", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8561, "created": "2008-08-26 18:05:32", "changetime": "2014-03-05 23:15:40", "last_pulled_from_trac": "2022-03-06 03:42:34.953106", "stage": "Accepted", "status": "closed", "component": "contrib.admin", "type": "New feature", "severity": "Normal", "version": "dev", "resolution": "fixed", "summary": "Pat\u0441h for Lithuanian support to Javascript slug creation", "description": "Path for Lithuanian support to Javascript slug creation in django/contrib/admin/media/js/urlify.js\r\n\r\nWhen slug is auto-generated some Lithuanian's letters are missing. So there is a patch for quick fix.\r\nActualy I am not very happy with current auto-generated slug creation, but for quick result it will do the trick.", "owner": "nobody", "reporter": "petraszd", "keywords": "LITHUANIAN_MAP", "easy": 0, "has_patch": 1, "needs_better_patch": 1, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8566, "created": "2008-08-26 19:35:10", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:35.681539", "stage": "Unreviewed", "status": "closed", "component": "Core (Other)", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "mark_safe not propagating from widgets to templates", "description": "\r\nI 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.\r\n\r\nRegards,\r\n\r\nAlex.\r\n\r\n====\r\n\r\nHi there,\r\n\r\nI have been trying to get a function call into a widget argument, but\r\nhave not been able to at the template level, because it would appear\r\nthat my safe_strings are being escaped somewhere down in the\r\nframework.  I have created a widget and mark_safe'd an attribute\r\nvalue, but no matter what, since it's pre-escaped by the time it\r\nbubbles up to the template level, I can't not escape it (well... I\r\ncould use an html library to de-escape it, but that seems kludgy).\r\n\r\nI've traced the execution and found the culprit to be the\r\ndjango.forms.util.flatatt function.  That is:\r\n\r\n{{{\r\nfrom django import forms\r\nfrom django.utils.safestring import mark_safe\r\n\r\nclass MyWidget(forms.TextInput):\r\n    def __init__(self, *args, **kwargs):\r\n        attrs = kwargs.setdefault('attrs', {})\r\n        attrs['safe_string'] = mark_safe(\"will o' the wisp\")\r\n        attrs['normal_string'] = \"cat o' nine tails\"\r\n        super(MyWidget, self).__init__(*args, **kwargs)\r\n\r\nw = MyWidget()\r\nw.render(\"field_name\", \"\")\r\n\r\n#=> u'<input normal_string=\"cat o&#39; nine tails\" type=\"text\"\r\nname=\"field_name\" safe_string=\"will o&#39; the wisp\" />'\r\n\r\n}}}\r\n\r\nYou can see that both the unsafe and safe strings were escaped.  I\r\ndon't know if this is intentional or not, but it prevents me from\r\nmaking something like:\r\n\r\n{{{\r\n<input type=\"text\" onBlur=\"myFunction('string_arg')\">\r\n}}}\r\n\r\nbecause it is always escaping my single-quotes.  Is this the desired\r\nbehavior?  Anyway, like I said, the culprit is:\r\n\r\n{{{\r\n\r\n# django.forms.util\r\n\r\ndef flatatt(attrs):\r\n\r\n\"\"\"\r\n    Convert a dictionary of attributes to a single\r\nstring.\r\n    The returned string will contain a leading space followed by\r\nkey=\"value\",\r\n    XML-style pairs.  It is assumed that the keys do not need to be\r\nXML-\r\nescaped.\r\n    If the passed dictionary is empty, then return an empty\r\nstring.\r\n    \"\"\"\r\n    return u''.join([u' %s=\"%s\"' % (k, escape(v)) for k, v in\r\nattrs.items()])  # <-- right there, the escape(v) call... should this\r\nbe conditional_escape?\r\n\r\n}}}\r\n\r\nSince there are a lot of calls to mark_safe scattered through the\r\nwidget and form-level calls used in rendering, I assume you're meant\r\nto be able to mark something as safe down here and have it get to the\r\ntop level unaltered...  no?\r\n\r\n", "owner": "nobody", "reporter": "agirman", "keywords": "mark_safe, safe string, escape, escaping, widgets", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8567, "created": "2008-08-26 19:47:08", "changetime": "2010-08-07 07:58:58", "last_pulled_from_trac": "2022-03-06 03:42:35.838662", "stage": "Ready for checkin", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Formwizard documentation does not clearly describe how to specify forms", "description": "When I read the Form Wizard doc, it took me a lots of searching before the \u201cglue\u201d between Form and FormWizard showed up in the urls.py example a long way down in the document.\r\n\r\nWhy don't put the urls.py much earlier in the document and/or describe the connection.\r\n", "owner": "ElliottM", "reporter": "ClaesBas", "keywords": "Form wizard", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8568, "created": "2008-08-26 20:17:31", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:35.987603", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Remove note about missing signals documentation in models doc.", "description": "I've attached a patch", "owner": "nobody", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8569, "created": "2008-08-26 20:21:46", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:36.143062", "stage": "Unreviewed", "status": "closed", "component": "Uncategorized", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Admin fieldsets can cause \"'str' object has no attribute '_default_manager'' under mod_wsgi", "description": "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: \r\n\r\n'str' object has no attribute '_default_manager'\r\n\r\nToday'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:\r\n\r\n{{{\r\nclass Maker(models.Model):\r\n    dummy = models.CharField(blank=True, max_length=80)\r\n\r\n    def __unicode__(self):\r\n        return self.dummy\r\n}}}\r\n\r\nsimplepromo (a simplified version of what Maciek sent me), also has a single model in models.py:\r\n\r\n{{{\r\nclass SimplePromo(models.Model):\r\n    \r\n    name = models.CharField(blank=False, max_length=250, help_text=\"Displayed in overlay tooltip\")\r\n    slug = models.SlugField()\r\n    promo_maker = models.ForeignKey(\"catalogue.Maker\", null=True, blank=False)\r\n    def __unicode__(self):\r\n        return self.name\r\n}}}\r\n\r\nand an admin.py file:\r\n\r\n{{{\r\nfrom django.contrib import admin\r\nfrom simplepromo.models import *\r\nclass SimplePromoAdmin(admin.ModelAdmin):\r\n    prepopulated_fields = {'slug': ('name',)}\r\n    \r\n    fieldsets = (\r\n        (\"Base\", {\r\n            \"fields\": [\"name\",\"slug\",\"promo_maker\",],\r\n        }),\r\n    )\r\n    \r\nadmin.site.register(SimplePromo, SimplePromoAdmin)\r\n}}}\r\n\r\nThe 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:\r\n\r\n{{{\r\nEnvironment:\r\n\r\nRequest Method: GET\r\nRequest URL: http://localhost/admin/\r\nDjango Version: 1.0-beta_1-SVN-8582\r\nPython Version: 2.5.2\r\nInstalled Applications:\r\n['django.contrib.admin',\r\n 'django.contrib.auth',\r\n 'django.contrib.contenttypes',\r\n 'django.contrib.humanize',\r\n 'django.contrib.markup',\r\n 'django.contrib.sessions',\r\n 'django.contrib.sites',\r\n 'catalogue',\r\n 'simplepromo']\r\nInstalled Middleware:\r\n('django.middleware.common.CommonMiddleware',\r\n 'django.contrib.sessions.middleware.SessionMiddleware',\r\n 'django.contrib.auth.middleware.AuthenticationMiddleware',\r\n 'django.middleware.doc.XViewMiddleware')\r\n\r\n\r\nTraceback:\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\core\\handlers\\base.py\" in get_response\r\n  77.                     request.path_info)\r\nFile \"c:/u/kmt/django/trunk\\django\\core\\urlresolvers.py\" in resolve\r\n  238.             for pattern in self.urlconf_module.urlpatterns:\r\nFile \"c:/u/kmt/django/trunk\\django\\core\\urlresolvers.py\" in _get_urlconf_module\r\n  257.              self._urlconf_module = __import__(self.urlconf_name, {}, {}, [''])\r\nFile \"c:/u/kmt/software/web/ppi-test\\urls.py\" in <module>\r\n  9. admin.autodiscover()\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\__init__.py\" in autodiscover\r\n  19.         __import__(\"%s.admin\" % app)\r\nFile \"c:/u/kmt/software/web/ppi-test\\simplepromo\\admin.py\" in <module>\r\n  12. admin.site.register(SimplePromo, SimplePromoAdmin)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\sites.py\" in register\r\n  91.             validate(admin_class, model)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\validation.py\" in validate\r\n  19.     _validate_base(cls, model)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\validation.py\" in _validate_base\r\n  201.             _check_form_field_existsw(\"fieldsets[%d][1]['fields']\" % idx, field)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\validation.py\" in _check_form_field_existsw\r\n  162.         return _check_form_field_exists(cls, model, opts, label, field)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\contrib\\admin\\validation.py\" in _check_form_field_exists\r\n  282.         fields = fields_for_model(model)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\forms\\models.py\" in fields_for_model\r\n  145.         formfield = formfield_callback(f)\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\forms\\models.py\" in <lambda>\r\n  124. def fields_for_model(model, fields=None, exclude=None, formfield_callback=lambda f: f.formfield()):\r\nFile \"c:\\u\\kmt\\django\\trunk\\django\\db\\models\\fields\\related.py\" in formfield\r\n  726.         defaults = {'form_class': forms.ModelChoiceField, 'queryset': self.rel.to._default_manager.complex_filter(self.rel.limit_choices_to)}\r\n\r\nException Type: AttributeError at /admin/\r\nException Value: 'str' object has no attribute '_default_manager'\r\n}}}\r\n\r\nI added a couple of local variables so I could see what's what and the local vars in that last routine are:\r\n\r\n{{{\r\nkwargs  {}\r\nself  <django.db.models.fields.related.ForeignKey object at 0x01EC8390>\r\nself_rel <django.db.models.fields.related.ManyToOneRel object at 0x01EC83B0>\r\nself_rel_to 'catalogue.Maker'\r\n}}}\r\n\r\nRunning the exact same app code under the development server plus putting a stop exception where the exception is generated under wsgi, I can see the local vars are different when running under the dev server:\r\n\r\n{{{\r\nkwargs  {}\r\nself  <django.db.models.fields.related.ForeignKey object at 0x01067BB0>\r\nself_rel  <django.db.models.fields.related.ManyToOneRel object at 0x01067BD0>\r\nself_rel_to  <class 'catalogue.models.Maker'>\r\n}}}\r\n\r\nSo somehow when running under the dev server (and anything other than wsgi, according to Maciek) self.rel.to has been transformed from a string to an actual class reference before this code is called.  I haven't a clue how this happens or why it isn't happening when running under mod_wsgi, so that's about as far as I can go with this one.  Hopefully someone else can shed some light?", "owner": "mtredinnick", "reporter": "kmtracey", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8570, "created": "2008-08-26 20:26:12", "changetime": "2008-09-14 07:04:40", "last_pulled_from_trac": "2022-03-06 03:42:36.286147", "stage": "Ready for checkin", "status": "closed", "component": "contrib.formtools", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Wrong indentation style in django/contrib/formtools/utils.py", "description": "This file has 8 space padding. This should be 4, as [http://docs.djangoproject.com/en/dev/internals/contributing/#coding-style contributing docs] said", "owner": "nobody", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8573, "created": "2008-08-26 21:24:34", "changetime": "2008-09-17 05:15:02", "last_pulled_from_trac": "2022-03-06 03:42:36.735178", "stage": "Unreviewed", "status": "closed", "component": "django-admin.py inspectdb", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "inspectdb doesn't make use of FK and uniqueness information when the column name has upper case characters", "description": "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`.\r\n\r\nProblem 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).\r\n\r\nAlso, 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.\r\n\r\nExample:\r\n\r\nThis `models.py` file:\r\n\r\n{{{\r\n#!python\r\nclass Magazine(models.Model):\r\n    ident = models.AutoField(primary_key=True, db_column='Ident')\r\n\r\nclass ReaderComment(models.Model):\r\n    text = models.TextField(max_length=30, primary_key=True, db_column='reader_comment')\r\n}}}\r\n\r\nwhen `syncdb`ed to the database (sqlite3) and the introspected back gives:\r\n\r\n{{{\r\n#!python\r\nclass IntrosBugMagazine(models.Model):\r\n    ident = models.IntegerField()\r\n    class Meta:\r\n        db_table = u'intros_bug_magazine'\r\n\r\nclass IntrosBugReadercomment(models.Model):\r\n    reader_comment = models.TextField(primary_key=True)\r\n    class Meta:\r\n        db_table = u'intros_bug_readercomment'\r\n}}}\r\n\r\nNote the `ident` field of the `Magazine` model is missing:\r\n\r\n 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.)\r\n b. The `db_column='Ident'` option\r\n", "owner": "nobody", "reporter": "ramiro", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8574, "created": "2008-08-26 21:40:47", "changetime": "2008-09-17 04:56:05", "last_pulled_from_trac": "2022-03-06 03:42:36.880202", "stage": "Unreviewed", "status": "closed", "component": "Contrib apps", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Sitemap should be a new style class", "description": "django.contrib.sitemaps.Sitemap should be a new-style class deriving from object.", "owner": "nobody", "reporter": "hvendelbo", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8575, "created": "2008-08-26 22:14:05", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:37.060439", "stage": "Accepted", "status": "closed", "component": "Database layer (models, ORM)", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "get_or_create testcase fails under MySQL", "description": "As mentioned here: http://groups.google.com/group/django-developers/browse_thread/thread/806b0168b150c8d4?hl=en\r\n\r\nIt 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.", "owner": "nobody", "reporter": "kmtracey", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8577, "created": "2008-08-26 22:43:31", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:37.379426", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Admin raises UnboundLocalError", "description": "{{{\r\nTraceback (most recent call last):\r\n\r\n  File \"/usr/lib/python2.3/site-packages/django/core/handlers/base.py\", line 86, in get_response\r\n    response = callback(request, *callback_args, **callback_kwargs)\r\n\r\n  File \"/usr/lib/python2.3/site-packages/django/contrib/admin/sites.py\", line 175, in root\r\n    return self.app_index(request, url)\r\n\r\n  File \"/usr/lib/python2.3/site-packages/django/contrib/admin/sites.py\", line 392, in app_index\r\n    app_dict = {\r\n\r\nUnboundLocalError: local variable 'model_dict' referenced before assignment\r\n}}}\r\nCode added in [8474] for #1390 produced this error.  The untested patch should fix this.", "owner": "nobody", "reporter": "evenrik", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8578, "created": "2008-08-26 22:55:41", "changetime": "2008-08-28 12:22:33", "last_pulled_from_trac": "2022-03-06 03:42:37.557976", "stage": "Ready for checkin", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Typo in testing docs, that also makes bad highlight", "description": "The incorrect typo was in this URL:\r\n  http://docs.djangoproject.com/en/dev/topics/testing/#id1\r\n\r\n", "owner": "nobody", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8579, "created": "2008-08-26 23:08:22", "changetime": "2014-01-20 02:50:58", "last_pulled_from_trac": "2022-03-06 03:42:37.719748", "stage": "Accepted", "status": "closed", "component": "contrib.admin", "type": "New feature", "severity": "Normal", "version": "dev", "resolution": "fixed", "summary": "Move admin validation to only run as part of \"validate\" management command", "description": "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.\r\n\r\nThis isn't entirely trivial, since it's a bit tied up with admin registration and that's an issue when `admin.autodiscover()` is used. ", "owner": "nobody", "reporter": "mtredinnick", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8580, "created": "2008-08-26 23:10:29", "changetime": "2008-09-07 23:08:02", "last_pulled_from_trac": "2022-03-06 03:42:37.865574", "stage": "Ready for checkin", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Missing links to django source files in settings doc.", "description": null, "owner": "nobody", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8581, "created": "2008-08-26 23:28:44", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:38.012703", "stage": "Ready for checkin", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Obsolete command in whatsnext docs", "description": "Now, source docs are in several directories. In whatnext.txt doc there are a {{{grep}}} command now obsolete.\r\n\r\nPlease see the patch.", "owner": "jacob", "reporter": "msaelices", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8563, "created": "2008-08-26 18:14:25", "changetime": "2008-08-27 17:03:01", "last_pulled_from_trac": "2022-03-06 03:42:35.269436", "stage": "Accepted", "status": "closed", "component": "GIS", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "[gis] Current locale considered when converting a geometry to WKT", "description": "I'm getting a OGRGeometry Exception intermittently, when saving a form.\r\n\r\nAfter debuging the code I noticed that the WKT string generated from\r\ngeometries were taking the current locale into account, thus raising\r\nthe Exceptions due to a bad WKT string representation. Here goes an\r\nexample:\r\n\r\n{{{\r\n>>> import locale\r\n>>> from django.contrib.gis.geos import Point\r\n>>> p = Point(-45.23, -23.15)\r\n>>> p.wkt\r\n'POINT (-45.2299999999999969 -23.1499999999999986)'\r\n>>> locale.getlocale()\r\n(None, None)\r\n>>> locale.setlocale(locale.LC_ALL, ('pt_BR','UTF-8'))\r\n'pt_BR.UTF8'\r\n>>> p.wkt\r\n'POINT (-45,2299999999999969 -23,1499999999999986)'\r\n}}}\r\n\r\nNotice de comma \",\" for decimal separator in the last output.\r\n\r\nIt must be something in the GEOS C library and in this case should be\r\nfixed there, but maybe it should be avoided reseting de locale before\r\ncalling the C routine and restoring the locale to what it was just\r\nafter.\r\n\r\nI think the reason this problem was not always happening is related to\r\nthe some setlocale thread safety issue.\r\n\r\nI was using the wkt from the geometry in a custom form PointField to get the coordinate transformed to the desired srid.\r\n\r\n", "owner": "jbronn", "reporter": "luizvital <luiz.vital@gmail.com>", "keywords": "geos locale", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8553, "created": "2008-08-26 07:58:36", "changetime": "2011-08-18 01:42:47", "last_pulled_from_trac": "2022-03-06 03:42:33.862841", "stage": "Unreviewed", "status": "closed", "component": "Database layer (models, ORM)", "type": "Uncategorized", "severity": "Normal", "version": "dev", "resolution": "wontfix", "summary": "Add soundex support to MySQL (and others)", "description": "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.\r\n\r\nhttp://www.postgresql.org/docs/8.3/static/fuzzystrmatch.html\r\nhttp://www.sqlite.org/lang_corefunc.html\r\nhttp://www.techonthenet.com/oracle/functions/soundex.php\r\n\r\nI've attached my changes for MySQL.", "owner": "nobody", "reporter": "dacort <django@sevicron.com>", "keywords": "mysql, soundex", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8565, "created": "2008-08-26 19:15:31", "changetime": "2012-12-16 15:15:49", "last_pulled_from_trac": "2022-03-06 03:42:35.545120", "stage": "Someday/Maybe", "status": "closed", "component": "contrib.comments", "type": "Cleanup/optimization", "severity": "Normal", "version": "dev", "resolution": "wontfix", "summary": "Comments should use object_id instead of object_pk", "description": "`django.contrib.comments.models.BaseCommentAbstractModel` uses `object_pk` to create a generic relation\r\n\r\nI 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`", "owner": "nobody", "reporter": "baumer1122", "keywords": "comments generic object_pk object_id", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8576, "created": "2008-08-26 22:30:47", "changetime": "2021-11-23 15:54:31", "last_pulled_from_trac": "2022-03-06 03:42:37.222924", "stage": "Design decision needed", "status": "closed", "component": "Database layer (models, ORM)", "type": "Uncategorized", "severity": "Normal", "version": "dev", "resolution": "wontfix", "summary": "Multiple AutoFields in a model", "description": "Got the assertions failed recently:\r\n{{{\r\n  File \"C:\\Projects\\houserules\\www\\hrdb\\events\\hrpercustomerobject.py\", line 14, in <module>\r\n    class HRPerCustomerObject(models.Model):\r\n  File \"C:\\Projects\\houserules\\www\\hrdb\\events\\hrpercustomerobject.py\", line 37, in HRPerCustomerObject\r\n    id_percustomer = models.AutoField ( 'Per-customer ID' )\r\n  File \"C:\\Projects\\houserules\\www\\django\\db\\models\\fields\\__init__.py\", line 425, in __init__\r\n    assert kwargs.get('primary_key', False) is True, \"%ss must have primary_key=True.\" % self.__class__.__name__\r\nAssertionError: AutoFields must have primary_key=True.\r\nmake: *** [_reset] Error 1\r\n}}}\r\nand\r\n{{{\r\n  File \"C:\\Projects\\houserules\\www\\django\\db\\models\\options.py\", line 117, in _prepare\r\n    model.add_to_class('id', auto)\r\n  File \"C:\\Projects\\houserules\\www\\django\\db\\models\\base.py\", line 139, in add_to_class\r\n    value.contribute_to_class(cls, name)\r\n  File \"C:\\Projects\\houserules\\www\\django\\db\\models\\fields\\__init__.py\", line 459, in contribute_to_class\r\n    assert not cls._meta.has_auto_field, \"A model can't have more than one AutoField.\"\r\nAssertionError: A model can't have more than one AutoField.\r\nmake: *** [_reset] Error 1\r\n}}}\r\nDepending 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.\r\nI roughly described one of possible scenarios in [http://oebfare.com/logger/django/2008/08/26/ IRC], though this may be not the only one.\r\nPlease 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.\r\nThe existing documentation on AutoField also does not imply it should be used for primary keys only.\r\n\r\nMy proposal is to withdraw such a limitation; seems that it is only required to remove two assert lines from the code\ufffd(well, and the related tests, of course).\r\n", "owner": "nobody", "reporter": "honeyman", "keywords": "multiple autofield", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}
{"id": 8571, "created": "2008-08-26 21:00:41", "changetime": "2010-01-16 19:13:22", "last_pulled_from_trac": "2022-03-06 03:42:36.444864", "stage": "Unreviewed", "status": "closed", "component": "contrib.comments", "type": null, "severity": null, "version": "1.0", "resolution": "worksforme", "summary": "comment framework throws obscure exception in {% comment_form_target %}", "description": "Today I updated Django to trunk version 8580, and I saw new comments \r\nframework. \r\nI updated my app acording to docs, made sql data migration but it \r\nlooks like new comments are not working. \r\nI am getting: \r\nCaught an exception while rendering: Reverse for '<function \r\npost_comment at 0x01894770>' not found. \r\n\r\nwhen I try to call  render_comment_form ,or get_comment_form, and all \r\nbecasue of \r\n {% comment_form_target %}, this seams to be the problem. \r\n\r\nIt is some kind of strange bug, Has someone some kind of clue what I \r\ncan do to fix this. \r\nThanx, \r\n\r\nBelow is original trace: \r\n\r\nOriginal Traceback (most recent call last): \r\n  File \"D:\\dev\\django-svn\\django\\template\\debug.py\", line 71, in \r\nrender_node \r\n    result = node.render(context) \r\n  File \"D:\\dev\\django-svn\\django\\template\\__init__.py\", line 876, in \r\nrender \r\n    return func(*resolved_vars) \r\n  File \"D:\\dev\\django-svn\\django\\contrib\\comments\\templatetags \r\n\\comments.py\", line 245, in comment_form_target \r\n    return comments.get_form_target() \r\n  File \"D:\\dev\\django-svn\\django\\contrib\\comments\\__init__.py\", line \r\n43, in get_form_target \r\n    return \r\nurlresolvers.reverse(\"django.contrib.comments.views.comments.post_comment\") \r\n  File \"D:\\dev\\django-svn\\django\\core\\urlresolvers.py\", line 307, in \r\nreverse \r\n    *args, **kwargs))) \r\n  File \"D:\\dev\\django-svn\\django\\core\\urlresolvers.py\", line 291, in \r\nreverse \r\n    raise NoReverseMatch(\"Reverse for '%s' not found.\" % lookup_view) \r\nNoReverseMatch: Reverse for '<function post_comment at 0x01894770>' \r\nnot found.Request Method:       GET \r\nRequest URL:    http://localhost/article/novi/ \r\nException Type: TemplateSyntaxError \r\nException Value:        Caught an exception while rendering: Reverse for \r\n'<function post_comment at 0x01894770>' not found. \r\n\r\nOriginal Traceback (most recent call last): \r\n  File \"D:\\dev\\django-svn\\django\\template\\debug.py\", line 71, in \r\nrender_node \r\n    result = node.render(context) \r\n  File \"D:\\dev\\django-svn\\django\\template\\__init__.py\", line 876, in \r\nrender \r\n    return func(*resolved_vars) \r\n  File \"D:\\dev\\django-svn\\django\\contrib\\comments\\templatetags \r\n\\comments.py\", line 245, in comment_form_target \r\n    return comments.get_form_target() \r\n  File \"D:\\dev\\django-svn\\django\\contrib\\comments\\__init__.py\", line \r\n43, in get_form_target \r\n    return \r\nurlresolvers.reverse(\"django.contrib.comments.views.comments.post_comment\") \r\n  File \"D:\\dev\\django-svn\\django\\core\\urlresolvers.py\", line 307, in \r\nreverse \r\n    *args, **kwargs))) \r\n  File \"D:\\dev\\django-svn\\django\\core\\urlresolvers.py\", line 291, in \r\nreverse \r\n    raise NoReverseMatch(\"Reverse for '%s' not found.\" % lookup_view) \r\nNoReverseMatch: Reverse for '<function post_comment at 0x01894770>' \r\nnot found.", "owner": "nobody", "reporter": "slavus@gmail.com", "keywords": "comment, comment_form_target", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}