django_tickets: tickets: 29 rows where "created" is on date 2008-08-13 sorted by resolution

29 rows where "created" is on date 2008-08-13 sorted by resolution

descending

id	created	changetime	last_pulled_from_trac	stage	status	component	type	severity	version	resolution ▼	summary	description	owner	reporter	keywords	has_patch	needs_better_patch	needs_tests	needs_docs
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		1	0	1	1
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
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		1	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
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		1	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		1	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>		1	0	0	0
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
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		1	1	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
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	1	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
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	1	1	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
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	1	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
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
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	1	1	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
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
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		1	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
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
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
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>		1	1	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	1	1	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
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		1	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

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
    );