django_tickets: tickets: 5 rows where "created" is on date 2008-08-13 and needs_better

5 rows where "created" is on date 2008-08-13 and needs_better_patch = 1 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
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
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
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
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
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

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