tickets
29 rows where "created" is on date 2008-08-13 sorted by has_patch
This data as json, CSV (advanced)
Suggested facets: type, version, resolution, summary, description, owner, reporter, keywords, has_patch, needs_better_patch, needs_tests, needs_docs
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
8277 | 2008-08-13 03:17:31 | 2011-09-28 16:12:17 | 2022-03-06 03:41:49.694552 | Accepted | closed | Documentation | dev | fixed | Typo in forms documentation | "You might want to allow the user to create several articles at once. To create a formset '''of''' out of an ArticleForm you would do:" | nobody | jarrow | 0 | 0 | 0 | 0 | 0 | 0 | |||
8279 | 2008-08-13 04:39:16 | 2011-09-28 16:12:17 | 2022-03-06 03:41:50.013692 | Accepted | closed | Database layer (models, ORM) | dev | fixed | Models with multiple ManyToManyField to 'self' use the last table for every m2m | {{{ #!python class Entry(models.Model): more_fields related = models.ManyToManyField('self', verbose_name=_('related entries')) translations = models.ManyToManyField('self', verbose_name=_('translations')) }}} From the database (postgres): {{{ blango=# select * from blango_entry_related; id | from_entry_id | to_entry_id ----+---------------+------------- 1 | 27 | 29 2 | 29 | 27 3 | 27 | 30 4 | 30 | 27 5 | 27 | 38 6 | 38 | 27 (6 rows) blango=# select * from blango_entry_translations; id | from_entry_id | to_entry_id ----+---------------+------------- 3 | 4 | 3 4 | 3 | 4 7 | 8 | 7 8 | 7 | 8 11 | 13 | 12 12 | 12 | 13 (6 rows) blango=# }}} And from ./manage.py shell: {{{ In [2]: from blango.models import *;Entry.objects.get(pk=27).related.all() Out[2]: [] In [3]: from blango.models import *;Entry.objects.get(pk=27).translations.all() Out[3]: [] }}} The database query log indicates that Django is using the wrong table: {{{ 2008-08-12 22:38:10 CEST LOG: statement: SELECT "blango_entry"."id", "blango_entry"."title", "blango_entry"."slug", "blango_entry"."author_id", "blango_entry"."language_id", "blango_entry"."body", "blango_entry"."body_html", "blango_entry"."pub_date", "blango_entry"."draft", "blango_entry"."allow_comments" FROM "blango_entry" INNER JOIN "blango_entry_translations" ON ("blango_entry"."id" = "blango_entry_translations"."to_entry_id") WHERE "blango_entry_translations"."from_entry_id" = 27 }}} If I change the order of the m2m in the model to: {{{ #!python class Entry(models.Model): more_fields translations = models.ManyToManyField('self', verbose_name=_('translations')) related = models.ManyToManyField('self', verbose_name=_('related entries')) }}} … | mtredinnick | Alberto García Hierro <fiam@rm-fr.net> | 0 | 0 | 0 | 0 | 0 | 0 | |||
8282 | 2008-08-13 10:59:05 | 2011-09-28 16:12:17 | 2022-03-06 03:41:50.512055 | Accepted | closed | contrib.admin | 1.0-alpha | duplicate | admin models not properly unregistered when having exceptions in admin.py (using django development server) | If duing development one makes codeing errors in admin.py, the development server will require a full restart before functioning properly. Reason is that models registered to newforms-admin before the exception occours will still be registered and models unregistered (but not reregistered) before the exception, will not be registered. This will cause allready registered exceptions for every registration and not registered exceptions for unregistrations. Fix: Django needs to do proper cleanup upon exceptions. | nobody | ask@jillion.dk | 0 | 0 | 0 | 0 | 0 | 0 | |||
8283 | 2008-08-13 12:49:39 | 2011-09-28 16:12:17 | 2022-03-06 03:41:50.667027 | Accepted | closed | Database layer (models, ORM) | dev | fixed | .filter() is ignored after (query | query) construction | Model: {{{ from django.db import models from django.contrib.auth.models import User class Asset(models.Model): public = models.BooleanField(default=True) owner = models.ForeignKey(User) def __unicode__(self): return "%s, %d (%s)" % (self.owner.username, self.id, "public" if self.public else "private") }}} Let's create several assets: {{{ >>> from testqsbug.models import Asset >>> from django.contrib.auth.models import User >>> user1 = User.objects.get(username = "user1") >>> user2 = User.objects.get(username = "user2") >>> Asset.objects.create(public=True, owner=user1) <Asset: user1, 1 (public)> >>> Asset.objects.create(public=False, owner=user1) <Asset: user1, 2 (private)> >>> Asset.objects.create(public=True, owner=user2) <Asset: user2, 3 (public)> >>> Asset.objects.create(public=False, owner=user2) <Asset: user2, 4 (private)> }}} Let's query all public assets OR assets that belong to some user: {{{ >>> Asset.objects.filter(public=True) | Asset.objects.filter(owner=user1) [<Asset: user1, 1 (public)>, <Asset: user1, 2 (private)>, <Asset: user2, 3 (public)>] }}} Let's filter from the result assets owned by user again (silly, I know): {{{ >>> (Asset.objects.filter(public=True) | Asset.objects.filter(owner=user1)).filter(owner=user1) [<Asset: user1, 1 (public)>, <Asset: user1, 2 (private)>, <Asset: user2, 3 (public)>] }}} Uhm. Does not work. Both requests resulted in the same query: {{{ >>> q = (Asset.objects.filter(public=True) | Asset.objects.filter(owner=user1)) >>> print q.query SELECT "testqsbug_asset"."id", "testqsbug_asset"."public", "testqsbug_asset"."owner_id" FROM "testqsbug_asset" WHERE ("testqsbug_asset"."public" = True OR "testqsbug_asset"."owner_id" = 1 ) >>> q2 = (Asset.objects.filter(public=True) | Asset.objects.filter(owner=user1)).filter(owner=user1) >>> print q2.query SELECT "testqsbug_asset"."id", "testqsbug_asset"."public", "testqsbug_asset"."owner_id" FROM "testqsbug_asset" WHERE ("testqsbug_asset"."public" = Tr… | mtredinnick | dottedmag | 0 | 0 | 0 | 0 | 0 | 0 | |||
8284 | 2008-08-13 13:59:45 | 2008-08-13 14:39:19 | 2022-03-06 03:41:50.816428 | Unreviewed | closed | Uncategorized | dev | wontfix | raw_input broken in eclipse | There are a few constructs in django like {{{ response = raw_input() if response == 'yes': do_stuff() }}} In eclipse on windows the '\r' is not stripped out of the string so the equality fails ('yes' != 'yes\r'). This means django refuses to delete my test database if i abort the tests in the middle. See: http://mail.python.org/pipermail/python-list/2008-March/482847.html I suggest something like: {{{ def _django_raw_input(): return raw_input.replace('\r', '') raw_input = _django_raw_input }}} I will write a patch if someone recommends the correct solution. | nobody | adamlofts | 0 | 0 | 0 | 0 | 0 | 0 | |||
8286 | 2008-08-13 15:06:15 | 2011-09-28 16:12:16 | 2022-03-06 03:41:51.125596 | Accepted | closed | Uncategorized | dev | fixed | Tests fail with r8336 | Tested on r8336, Debian Etch, Python 2.4.4 {{{ vm3:~/dev/django-trunk/tests# ./runtests.py --settings settings ====================================================================== FAIL: Doctest: regressiontests.m2m_through_regress.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for regressiontests.m2m_through_regress.models.__test__.API_TESTS File "/home/dev/django-trunk/tests/regressiontests/m2m_through_regress/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/dev/django-trunk/tests/regressiontests/m2m_through_regress/models.py", line ?, in regressiontests.m2m_through_regress.models.__test__.API_TESTS Failed example: management.call_command('dumpdata', 'm2m_through_regress', format='json', indent=2) Expected: [ { "pk": 1, "model": "m2m_through_regress.membership", "fields": { "person": 1, "price": 100, "group": 1 } }, { "pk": 2, "model": "m2m_through_regress.membership", "fields": { "person": 1, "price": 100, "group": 2 } }, { "pk": 3, "model": "m2m_through_regress.membership", "fields": { "person": 2, "price": 100, "group": 1 } }, { "pk": 1, "model": "m2m_through_regress.usermembership", "fields": { "price": 100, "group": 1, "user": 1 } }, { "pk": 2, "model": "m2m_through_regress.usermembership", "fields": { "price": 100, "group": 2, … | nobody | jarrow | 0 | 0 | 0 | 0 | 0 | 0 | |||
8288 | 2008-08-13 16:06:47 | 2011-09-28 16:12:17 | 2022-03-06 03:41:51.454952 | Accepted | closed | Database layer (models, ORM) | 1.0-alpha | worksforme | Field lookup of __gt and __gte on DecimalField causes memory blowup | Somewhere between Django alpha 1 and 2, it seems a bug was introduced where using a field lookup of __gt or __gte on a DecimalField causes an instance of the development server (and probably other server instances, e.g. mod_python) to rapidly grow in memory and consume system resources (primarily memory). Perhaps a race condition is being triggered. I have to kill the dev server to get my system (running Linux) under control again. There were no such problems seen with the exact same code in the alpha 1 svn, as far as I recall. I notice some changes have been made to the DecimalField #8143, but these are pre-existing values already in the database. I'm using the trunk at revision 8336. | nobody | odonian | 0 | 0 | 0 | 0 | 0 | 0 | |||
8289 | 2008-08-13 16:45:46 | 2011-09-28 16:12:17 | 2022-03-06 03:41:51.622402 | Accepted | closed | Translations | dev | fixed | Update to Irish Translation | updating translation files to r8335 now 20% complete | nobody | mt | 0 | 0 | 0 | 0 | 0 | 0 | |||
8290 | 2008-08-13 18:34:58 | 2011-09-28 16:12:17 | 2022-03-06 03:41:51.759604 | Accepted | closed | Validators | dev | fixed | DecimalField does not handle validation of large decimal_places | If decimal_places is set to 2, and a number like 0.0000000001 tries to get validated, it passes when it should fail. If you make a form and look at the cleaned data for a DecimalField, you will see that a number like .0000001 looks something like the notation 1E-8, of the decimal.Decimal type. | gwilson | jb0t | DecimalField, decimal_places, validation | 0 | 0 | 0 | 0 | 0 | 0 | ||
8292 | 2008-08-13 20:34:04 | 2011-09-28 16:12:17 | 2022-03-06 03:41:52.071525 | Accepted | closed | contrib.admin | dev | fixed | InlineModelAdmin not honoring filter_horizontal | One would expect the `filter_horizontal` / `filter_vertical` admin options to function with the `InlineModelAdmin` classes for generic relationships `in contenttypes.generic`. Considering the code snippet below, I would have expected the nice javascript dual-picklist interface instead of the plain, single multiselect input. Sample models.py file: {{{ #!python from django.db import models from django.contrib.auth.models import User from django.contrib import admin from django.contrib.contenttypes import generic from django.contrib.contenttypes.models import ContentType class GenericDocument(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(User, blank=True) content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() class Publisher(models.Model): name = models.CharField(max_length=50) articles = generic.GenericRelation(GenericDocument) class GenericDocumentInline(generic.GenericStackedInline): model = GenericDocument filter_horizontal = ('authors', ) class PublisherAdmin(admin.ModelAdmin): list_display = ('name', ) inlines = [GenericDocumentInline] admin.site.register(Publisher, PublisherAdmin) }}} | brosner | dakrauth | 0 | 0 | 0 | 0 | 0 | 0 | |||
8293 | 2008-08-13 20:34:18 | 2011-09-28 16:12:17 | 2022-03-06 03:41:52.220619 | Unreviewed | closed | Uncategorized | dev | invalid | NJiKWWbgSqiqJS | 92cPNo <a href="http://dgvnmufchudp.com/">dgvnmufchudp</a>, [url=http://swuokhptbspg.com/]swuokhptbspg[/url], [link=http://sibuawgeaewg.com/]sibuawgeaewg[/link], http://tkszumxylrco.com/ | nobody | anonymous | nxPxrdftI | 0 | 0 | 0 | 0 | 0 | 0 | ||
8294 | 2008-08-13 20:34:20 | 2011-09-28 16:12:17 | 2022-03-06 03:41:52.375101 | Unreviewed | closed | Uncategorized | dev | invalid | NJiKWWbgSqiqJS | 92cPNo <a href="http://dgvnmufchudp.com/">dgvnmufchudp</a>, [url=http://swuokhptbspg.com/]swuokhptbspg[/url], [link=http://sibuawgeaewg.com/]sibuawgeaewg[/link], http://tkszumxylrco.com/ | nobody | anonymous | nxPxrdftI | 0 | 0 | 0 | 0 | 0 | 0 | ||
8295 | 2008-08-13 20:34:25 | 2011-09-28 16:12:17 | 2022-03-06 03:41:52.535459 | Unreviewed | closed | Uncategorized | dev | invalid | NJiKWWbgSqiqJS | 92cPNo <a href="http://dgvnmufchudp.com/">dgvnmufchudp</a>, [url=http://swuokhptbspg.com/]swuokhptbspg[/url], [link=http://sibuawgeaewg.com/]sibuawgeaewg[/link], http://tkszumxylrco.com/ | nobody | anonymous | nxPxrdftI | 0 | 0 | 0 | 0 | 0 | 0 | ||
8298 | 2008-08-13 22:47:21 | 2011-09-28 16:12:17 | 2022-03-06 03:41:52.966223 | Accepted | closed | Uncategorized | dev | fixed | Missing to_python methods causing issues with serialization | Lack of to_python on IntegerField? is breaking our tests that read from XML fixtures. From what I can tell, this how things are supposed to work: (1) an IntegerField is read in as unicode (from the XML fixture), (2) the row is saved to the database, and (3) field is an integer on the next read from db. However, on one model, we have a post-save signal handler that expects the field to be an integer. This handler throws an exception when it gets unicode, so our tests break. Is accepting strings a part of the database interface definition? I'm guessing we'd hit this same problem if using a form. | nobody | andrewbadr | 0 | 0 | 0 | 0 | 0 | 0 | |||
8300 | 2008-08-13 23:13:52 | 2009-02-25 19:51:44 | 2022-03-06 03:41:53.262410 | Unreviewed | closed | contrib.syndication | dev | duplicate | feedgenerator shouldn't use ascii to decode dates | if i use some locale like '''tr_TR.UTF-8''' or any other locale, a date for the rss feed could be '''"10 Ağu"''' instead of '''"10 Aug"'''.. Therefore, I get the following error messages: UnicodeDecodeError at /feeds/latest/[[BR]] 'ascii' codec can't decode byte 0xc4 in position 9: ordinal not in range(128) I think all decoding should be done using utf-8 instead of ascii.. And by the way there's a problem in line 241 of feedgenerator.py file: handler.addQuickElement(u"pubDate", rfc2822_date(item['pubdate']).decode('links')) 'links' here should be something like ascii or especially utf-8.. | nobody | alperkanat | 0 | 0 | 0 | 0 | 0 | 0 | |||
8272 | 2008-08-13 02:11:04 | 2013-04-07 18:04:21 | 2022-03-06 03:41:48.836748 | Accepted | closed | Forms | New feature | Normal | dev | duplicate | Patch to forms to add a fieldset attribute to Field for use with templates | I needed to create a complex form that used fieldsets to divide sections of the form. I finally figured out that to do this, I needed to modify the forms code a bit. I've tested this patch against the latest version of svn and it worked. Below is a snippet of a template to show you how you would use the new fieldset attribute for more complex form layouts. The diff file is attached. <form action="." method="post"> {% regroup form by fieldset as fields_list %} {% for field in fields_list %} <fieldset> <legend>{{ field.grouper|upper }}</legend> {% for f in field.list %} {{ f.label_tag }} {{ f }} {% endfor %} </fieldset> {% endfor %} <input type="submit" value="Submit" /> </form> | jbowman | jbowman | 0 | 1 | 0 | 1 | 1 | 0 | |
8273 | 2008-08-13 02:13:52 | 2012-10-15 19:37:28 | 2022-03-06 03:41:49.004388 | Accepted | closed | contrib.localflavor | Cleanup/optimization | Normal | dev | wontfix | Reduce amount of redundant code in django.contrib.localflavor | There is a plenty of somehow redundant code in {{{django.contrib.localflavor}}} which leads to potentially more bugs and what is quite inconvenient -- many translation strings. I would like to propose the patch that handles all fields with a checksum verification. Pros: * a lot fewer translation strings, which is more consistent and means less work when translating Django to 50 languages, * DRY compatible (and all benefits that it implies). Cons: * backwards incompatible, * new code may contain bugs (although all tests were OK). I volunteer for further modifications of {{{django.contrib.localflavor}}} code to use {{{NumberWithChecksumField}}} if this patch is accepted. | nobody | Piotr Lewandowski <django@icomputing.pl> | 0 | 1 | 1 | 0 | 0 | 0 | |
8274 | 2008-08-13 02:23:50 | 2010-07-05 04:39:53 | 2022-03-06 03:41:49.179051 | Ready for checkin | closed | contrib.auth | dev | fixed | Auth views should allow form customization | It is possible to make your own authentication backend. However, if you want to authenticate with usernames longer than 30 characters (e.g. emails) you cannot rely on the login view, since it's bound to use the AuthenticationForm, which itself only allows 30 characters usernames. You could easily find a way around if only the form was customizable. Curiously, some views already allow form customization -- `password_reset_confirm` and `password_reset` -- but the others don't -- `login` and `password_change` --. The attached patch fixes the latter. | julien | julien | 0 | 1 | 0 | 0 | 0 | 0 | |||
8275 | 2008-08-13 02:38:17 | 2009-03-26 03:45:49 | 2022-03-06 03:41:49.345347 | Accepted | closed | contrib.auth | dev | fixed | Unused and unnecessary imports in auth views | Attached patch removes those. | nobody | julien | 0 | 1 | 0 | 0 | 0 | 0 | |||
8276 | 2008-08-13 02:42:15 | 2011-09-28 16:12:17 | 2022-03-06 03:41:49.524817 | Accepted | closed | contrib.localflavor | Uncategorized | Normal | dev | fixed | Change fields' names in django.contrib.localflavor.pl.forms | I would like to propose backward incompatible change {{{django.contrib.localflavor.pl.forms}}}: Some classes present in {{{django.contrib.localflavor.pl.forms}}} are named in a werid way - they are neither short and useful, nor offical translations of corresponding numbers. ||Old name||New name|| ||`PLNationalIdentificationNumberField`||`PLPESELField`|| ||`PLTaxNumberField`||`PLNIPField`|| ||`PLNationalBusinessRegisterField`||`PLREGONField`|| ||`PLVoivodeshipSelect`||`PLProvinceSelect`|| ||`PLAdministrativeUnitSelect`||`PLCountiesSelect`|| Not only Polish people in everyday language use those acronyms, but even Polish officials refer to those numbers as `PESEL`, `REGON` and `NIP`: * http://www.mswia.gov.pl/portal/en/1/383/18102007_Meeting_of_G6_Ministers__Invitation_for_Conference.html * http://www.stat.gov.pl/bip/regon_ENG_HTML.htm I'm willing to prepare the patch if those changes are accepted. | nobody | Piotr Lewandowski <django@icomputing.pl> | 0 | 1 | 0 | 0 | 0 | 0 | |
8278 | 2008-08-13 04:32:20 | 2011-09-28 16:12:17 | 2022-03-06 03:41:49.849023 | Accepted | closed | Core (Other) | dev | fixed | QueryDict.update eats data when other_dict is a MultiValueDict | django.http.QueryDict supports .update, but it seems to assume that other_dict is a (builtin) dict. This is dangerous when mixing two QueryDicts. {{{ >>> x = QueryDict('a=1&a=2') >>> y = QueryDict('a=3&a=4') >>> print x <QueryDict: {u'a': [u'1', u'2']}> >>> print y <QueryDict: {u'a': [u'3', u'4']}> >>> x._mutable = True >>> x.update(y) >>> x._mutable=False >>> print x <QueryDict: {u'a': [u'1', u'2', u'4']}> }}} Note that a=3 was lost. As far as I can see, there's no really nice fix to this. QueryDict.update doesn't just defer to MultiValueDict because it needs to force keys and values into unicode. Defering to MultiValueDict first and then forcing means duplicate keys for items not yet coerced. Forcing individual items results in lists from QueryDict becoming (single) items in MultiValueDict. i.e. {{{ dict([(f(k), f(v)) for k, v in other_dict.items()]) -> dict([(f(k), [f(v) for v in values]) for k, values in other_dict.lists()]) }}} This seems to be a leaky abstraction here; I think QueryDict is not really a MultiValueDict, since MultiValueDict can have any (hashable) objects as keys and values, while QueryDict insists on unicode objects only. No patch from me since the solution isn't obvious to me. Marking as 1.0 since this is a bug, though. | nobody | jdunck | 0 | 1 | 1 | 0 | 0 | 0 | |||
8280 | 2008-08-13 07:08:07 | 2015-01-05 16:19:23 | 2022-03-06 03:41:50.160805 | Ready for checkin | closed | Core (Management commands) | Bug | Normal | dev | fixed | Commands framework doesn't support alternate import methods | From this thread on the developer mailing list http://groups.google.com/group/django-developers/browse_thread/thread/78975372cdfb7d1a# I understand that the Django team is keen on supporting alternate ways of packaging django: in a zip-file, in a jar-file(Jython) or other "frozen" formats. One place that'll need fixing to achieve this is to update the command framework. [[BR]] The find available commands, the current Django code is browsing the command subdirectories and looking for files that end with a .py extension[[BR]] To support alternate packaging, the code should use the proper Python APIs to iterate over the available modules in a package. A patch along these lines was already included with #5825. (The patch would need updating to the SVN version however - Once this ticket is accepted I can take care of it.) | nobody | jdetaeye | command zip | 0 | 1 | 0 | 0 | 0 | 0 |
8281 | 2008-08-13 08:39:34 | 2011-05-20 08:53:31 | 2022-03-06 03:41:50.350073 | Accepted | closed | HTTP handling | New feature | Normal | 1.0-alpha | wontfix | Django running ounder PyISAPIe on IIS doesn't detect HTTPS | The is_secure() function in django.http.Request uses os.environ to detect whether or not the request is HTTPS or not. This doesn't work on Windows because the environment doesn't contain this information. PyISAPIe makes this information available in META (well, actually it doesn't yet, but that's another bug and patch to file against PyISAPIe). The Django patch is against django.http.__init__.py and the PyISAPIe patch is against django.core.handlers.pysiapi.py. We're using Django trunk r8066. Some [http://www.kirit.com/Blog:/2008-08-13/HTTPS%20detection%20in%20Django%20under%20PyISAPIe extra information is available on my blog]. | nobody | KayEss | PyISAPIe HTTPS | 0 | 1 | 1 | 0 | 0 | 0 |
8285 | 2008-08-13 14:16:39 | 2011-09-28 16:12:17 | 2022-03-06 03:41:50.986252 | Accepted | closed | Core (Other) | dev | fixed | Signal Handlers can only be functions with DEBUG=True | When DEBUG=True, signal handlers can only be functions, rather than any callable object. This is because dispatch/dispatcher.py tries to ensure that signal handlers accept **kwargs, using inspect.getargspec. Unfortunately, inspect.getargspec accepts only actual function objects, and not any callable. Thus, the check does more harm than good in cases where the signal handler is not an actual function. I suggest this check simply be removed. | nobody | Zal | signals functions | 0 | 1 | 1 | 0 | 0 | 0 | ||
8287 | 2008-08-13 15:11:58 | 2011-09-28 16:12:17 | 2022-03-06 03:41:51.303091 | Accepted | closed | HTTP handling | dev | fixed | Debug page shows wrong URL info when altering request.path | Not sure if this is a bug or an expected behavior, but anyway... I have a middleware that alters {{{request.path}}} in order to hide a certain part of the URL to the views, so if I have an URL like {{{/en/view/page/}}} this should become {{{/view/page/}}}. With recent upgrades this stopped working, and after a bit of investigating I found that this was due to [8015]. I spent a lot of time trying to understand why this was failing, since the debug page was showing the output I was expecting. For example, for {{{/en/view/page}}} I got: {{{ Using the URLconf defined in project.urls, Django tried these URL patterns, in this order: ... 3. ^view/(?P<title_slug>[\w-]+)/$ ... The current URL, view/page/, didn't match any of these. }}} While {{{view/page/}}} ''matches'' the 3rd url pattern. This happens because the debug page shows {{{request.path}}}, while the URLconf actually evaluates {{{PATH_INFO}}} and {{{SCRIPT_NAME}}}. I fixed the problem by altering {{{request.path_info}}} as well, but shouldn't the debug page show the URL that is actually evaluated by URLconf? In case this should be fixed I can provide a patch, but actually I don't know if {{{.path_info}}} should be ''always'' shown or must be shown only in certain places within the debug page. | nobody | kratorius | request.path, urlconf, urls | 0 | 1 | 0 | 0 | 0 | 0 | ||
8291 | 2008-08-13 19:32:48 | 2012-02-04 19:56:40 | 2022-03-06 03:41:51.919782 | Accepted | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | "pk" alias doesn't work for Meta option "ordering" | Using the model below: {{{ class MyModel(models.Model): part_number = models.CharField(max_length=128) class Meta: ordering = ['pk'] }}} ... yields the error message: "ordering" refers to "pk", a field that doesn't exist | dgouldin | peterd12 | Meta ordering pk alias | 0 | 1 | 1 | 0 | 0 | 0 |
8296 | 2008-08-13 22:25:36 | 2009-07-29 15:52:52 | 2022-03-06 03:41:52.692010 | Design decision needed | closed | Template system | dev | duplicate | Allow template parser to parse until "complex" block node | For info, this was brought up in [1]. Currently, with block tags, you can only parse until a "simple" closure tag. For example: `{% endif %}` or `{% endfor %}`. Now, it would be nice if you could parse until something more "complex" like `{% elseif blah and blahblah %}`. By "complex" I mean a tag that requires some parameters. Here I'm not asking for an `elseif` tag in particular, but I'd like to allow the parser to also consider "complex" closure tags. For example, a direct application of this would be a suggestion for a `{% withblock %}` tag. Here's a suggested syntax: {{{ {% withblock as myurl %} {% url path.to.some_view arg1,arg2,name1=value1 %} {% and as var %} {% whatever %} {% in %} Click the link: <a href="{{ myurl }}">{{ var }}</a>. {% endwithblock %} }}} Currently the `{% and as var %}` tag cannot be recognized. The problem is in `django.template.Parser.parse()`: {{{ ... elif token.token_type == TOKEN_BLOCK: if token.contents in parse_until: ... }}} It basically checks if the tag's hard string name is in the list. The attached patch, which is *backward compatible*, only looks at the first piece of text in the node, namely the tag's name. With that, in your tag you could parse the block like follows: {{{ nodelist = parser.parse(('and', 'in')) # Parse until {% and as var %} or {% in %} }}} [1] http://groups.google.com/group/django-developers/browse_thread/thread/c81a9fe156af71e7 | nobody | julien | 0 | 1 | 0 | 0 | 0 | 0 | |||
8297 | 2008-08-13 22:31:50 | 2009-02-25 19:51:44 | 2022-03-06 03:41:52.828046 | Unreviewed | closed | Template system | dev | wontfix | Withblock template tag | '''Important note''': This ticket can work only if #8296 gets checked in. Currently there is the convenient `{% with %}` tag to create variables in templates. Unfortunately there is no built-in counterpart for blocks. The attached patch does just that, with the following suggested syntax: {{{ {% withblock as myurl %} {% url path.to.some_view arg1,arg2,name1=value1 %} {% and as var %} {% whatever %} {% in %} Click the link: <a href="{{ myurl }}">link</a>. <p>{{ var }}</p> {% endwithblock %} }}} | nobody | julien | 0 | 1 | 0 | 0 | 0 | 0 | |||
8299 | 2008-08-13 23:00:18 | 2011-09-28 16:12:17 | 2022-03-06 03:41:53.115221 | Accepted | closed | Documentation | dev | fixed | Docs on ModelAdmin.form attribute need improvement | At the moment it is not really clear from the docs that you have to supply a subclass that already has a Meta class in it. From reading it I thought this would be added by the admin (as happens if you don't set the form attribute). This interpretation is also enforced by the lack of a Meta class in the validation example given later on. The attached patch fixes the example and tries to be a bit more explicit in the form attribute explanation. | nobody | jarrow | 0 | 1 | 0 | 0 | 0 | 0 |
Advanced export
JSON shape: default, array, newline-delimited, object
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 );