tickets
23 rows where "created" is on date 2011-06-09 and resolution = "fixed" sorted by changetime
This data as json, CSV (advanced)
Suggested facets: component, owner, reporter, easy, needs_better_patch, needs_tests, needs_docs, ui_ux
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
16186 | 2011-06-09 12:48:10 | 2011-06-09 15:39:13 | 2022-03-06 04:02:30.588387 | Ready for checkin | closed | contrib.admin | Cleanup/optimization | Normal | dev | fixed | Remove inline CSS from admin templates | The templates in contrib.admin have a lot of inline javascript. Also inline css styling appears at several places. This should be cleaned up so improving or redesigning the admin in the future is more easy. Javascripts could and should also be more based on jQuery, since it has been available in the admin anyway for some time now. | cscheng | bsimons | admin, templates, html, css, javascript | 0 | 1 | 0 | 0 | 0 | 1 |
16178 | 2011-06-09 04:03:13 | 2011-06-09 23:15:44 | 2022-03-06 04:02:29.461590 | Ready for checkin | closed | HTTP handling | Cleanup/optimization | Normal | 1.3 | fixed | Cleanup request classes' __repr__() | As discussed in https://code.djangoproject.com/ticket/14614#comment:16, there are a few small inconsistencies and some duplicated code in `HttpRequest`'s, `ModPythonRequest`'s, and `WSGIRequest`'s `__repr__()` methods, and since [16339] also in `ExceptionReporterFilter.get_request_repr ()`. The attached patch consolidates all that code into a single function. Note that I had to initialise the `_post_parse_error` attribute in the `HttpRequest` constructor, which should make sense since that attribute is used in some of `HttpRequest`'s methods anyway. | nobody | julien | 0 | 1 | 0 | 0 | 0 | 0 | |
16185 | 2011-06-09 12:03:45 | 2011-06-10 08:26:06 | 2022-03-06 04:02:30.431603 | Ready for checkin | closed | Testing framework | New feature | Normal | 1.3 | fixed | Allow to override TEST_RUNNER setting with a command-line option to 'manage.py 'test' | In order to enable the integration of the Django test framework with IDE test runners, it's useful to be able to replace or decorate the test runner specified by the TEST_RUNNER setting in settings.py. Currently, the only way to do so is to provide our own settings.py which imports the user's settings.py and then changes the TEST_RUNNER setting. This is ugly and not always works. A much preferred solution is to be able to override the test runner with a command line option passed to 'manage.py test'. I've discussed this approach with russelm at the DjangoCon.EU sprint, and it was approved in general. | nobody | intelliyole | 0 | 1 | 0 | 0 | 0 | 0 | |
16196 | 2011-06-09 15:57:03 | 2011-06-10 10:18:07 | 2022-03-06 04:02:32.150766 | Ready for checkin | closed | Uncategorized | Cleanup/optimization | Normal | dev | fixed | Redundant or incorrect code in tests | Ran a static analysis tool on Django tests, found and fixed several classes of issues: - Unnecessary semicolons - Unnecessary backslashes - Duplicate keys in dictionaries containing testdata (sometimes causing testcases present in the code to be missed) - One case of incorrectly inserted line break preventing the execution of an assertion Attached patch fixing the issues. | melinath | intelliyole | 0 | 1 | 0 | 0 | 0 | 0 | |
16198 | 2011-06-09 15:58:59 | 2011-06-10 14:08:52 | 2022-03-06 04:02:32.474874 | Ready for checkin | closed | Testing framework | Cleanup/optimization | Normal | 1.3 | fixed | model_forms tests are still doctests. | Refactor model_forms tests to be unittests instead of doctests. | nobody | gregmuellegger | model_forms, doctests | 0 | 1 | 0 | 0 | 0 | 0 |
16195 | 2011-06-09 15:39:30 | 2011-06-11 15:43:52 | 2022-03-06 04:02:32.003277 | Ready for checkin | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | Document the ModelAdmin.get_changelist | Was commited in [11910]. It need some documentation. | msaelices | msaelices | modeladmin changelist | 0 | 1 | 0 | 0 | 0 | 0 |
16183 | 2011-06-09 11:45:09 | 2011-06-14 10:45:50 | 2022-03-06 04:02:30.154612 | Ready for checkin | closed | contrib.auth | Bug | Normal | 1.3 | fixed | Incorrect test in contrib.auth silently passes | There are a test case: [source:django/trunk/django/contrib/auth/tests/permissions.py@16341#L36 auth.TestAuthPermissions]. It checks that the ordering of autogenerated permissions is the same (ticket [ticket:14731]) by creating permissions and trying to load fixture, then checking that 'loaddata' passed with clean stderr. The problem is that this fixture ("test_permissions.json") has been checked in with different name ("permissionstestdata.json"). The bigger problem is that "loaddata test_permissions.json" yields "No fixtures found." in stdout, leaving stderr clean. So the test was here and passed without an error since checkin. Attaching patch that fixes fixture name and the fixture itself (as it contains contenttype for legacy auth.Message model which breaks the test). | desh | desh | 0 | 1 | 0 | 0 | 0 | 0 | |
16200 | 2011-06-09 16:06:11 | 2011-06-16 16:33:47 | 2022-03-06 04:02:32.967466 | Ready for checkin | closed | Template system | Bug | Normal | 1.3 | fixed | __init__ of TemplateIfParser has return statement | nobody | traff | 0 | 1 | 0 | 0 | 0 | 0 | ||
16207 | 2011-06-09 18:33:45 | 2011-06-25 12:39:57 | 2022-03-06 04:02:33.903554 | Ready for checkin | closed | Documentation | Bug | Normal | 1.3 | fixed | UserProfile documentation (not extensive enough) | https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users# {{{The method get_profile() does not create the profile, if it does not exist. You need to register a handler for the signal django.db.models.signals.post_save on the User model, and, in the handler, if created=True, create the associated user profile.}}} However, it does not show how to do this. For new users, this will be quite off putting, especially as most people skim the documentation, and don't bother with the 'fat'. May I suggest the documentation is included to use the following snippet: http://stackoverflow.com/questions/44109/extending-the-user-model-with-custom-fields-in-django {{{ #in models.py from django.contrib.auth.models import User from django.db.models.signals import post_save class UserProfile(models.Model): user = models.OneToOneField(User) #other fields here def __str__(self): return "%s's profile" % self.user def create_user_profile(sender, instance, created, **kwargs): if created: profile, created = UserProfile.objects.get_or_create(user=instance) post_save.connect(create_user_profile, sender=User) #in settings.py AUTH_PROFILE_MODULE = 'YOURAPP.UserProfile' }}} | melinath | foxwhisper | userprofile | 0 | 1 | 0 | 0 | 0 | 0 |
16189 | 2011-06-09 13:38:41 | 2011-06-25 13:17:34 | 2022-03-06 04:02:31.063585 | Ready for checkin | closed | Testing framework | Cleanup/optimization | Normal | 1.3 | fixed | Tests with URLField(verify_exists=True) should use a mock and not access the internet directly. | Currently the testsuite tries to hit some domains to test the verify_exists=True behaviour of URLFields. However unittests should not require any external resources. urllib2.urlopen should be mocked in the tests to provide faster and more reliable tests. | gregmuellegger | gregmuellegger | verify_exists | 0 | 1 | 0 | 0 | 0 | 0 |
16209 | 2011-06-09 20:27:56 | 2011-06-26 16:52:14 | 2022-03-06 04:02:34.164293 | Ready for checkin | closed | Documentation | New feature | Normal | 1.3 | fixed | Add alternative repositories to 'Installing the development version' in the docs. | https://docs.djangoproject.com/en/dev/topics/install/#installing-development-version The current page only refers to the subversion repo, but there are official github and bitbucket repos which some users will find more convenient. | ShawnMilo | ShawnMilo | 1 | 1 | 0 | 0 | 0 | 0 | |
16199 | 2011-06-09 15:59:23 | 2011-06-26 17:00:25 | 2022-03-06 04:02:32.722465 | Accepted | closed | contrib.sessions | New feature | Normal | dev | fixed | Create a secure cookie-based session backend | I have built a third-party implementation of this, but after talking to some core devs at DjangoCon.eu, it seems there's some interest in having this be in core. Here's my implementation: https://github.com/ericflo/django-cookie-sessions There's really not a whole lot of code there, it passes all of Django's session tests, and it seems to work great (except the one that checks for existence, which doesn't make sense in a cookie backend, so that test is overwritten with a no-op.) Most of the code is here: https://github.com/ericflo/django-cookie-sessions/blob/master/cookiesessions/engine.py | nobody | floguy | 0 | 1 | 1 | 0 | 1 | 0 | |
16204 | 2011-06-09 16:42:23 | 2011-08-22 02:52:21 | 2022-03-06 04:02:33.511909 | Ready for checkin | closed | contrib.admin | Cleanup/optimization | Normal | dev | fixed | Remove unused functions in admin core.js (getCorrectYear and getISODate). | Functions getCorrectYear and getISODate are not used anymore. They should be removed. | nobody | mbraak | 0 | 1 | 0 | 0 | 0 | 0 | |
16201 | 2011-06-09 16:09:56 | 2011-08-23 15:57:01 | 2022-03-06 04:02:33.100229 | Ready for checkin | closed | HTTP handling | Bug | Normal | 1.3-rc | fixed | When Content-Length is 0, MultiPartParser violates RFC2616 | RFC 2616 says that: "Any Content-Length greater than or equal to zero is a valid value." http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 Currently {{{ MultiPartParser }}} doesn't handle "Content-Length: 0". The patch I've attached returns an empty request.POST in {{{ MultiPartParser.parser() }}} if the "Content-Length: 0" instead of raising an exception on {{{ MultiPartParser.__init__() }}}. I've also added the tests for this particular case in requests/tests. ( {{{ ./runtests.py --settings=test_sqlite requests.RequestsTests.test_POST_multipart_with_content_length_zero }}} ) | nobody | albsen | http multipart | 0 | 1 | 0 | 0 | 0 | 0 |
16202 | 2011-06-09 16:09:58 | 2011-08-28 13:51:29 | 2022-03-06 04:02:33.239504 | Ready for checkin | closed | contrib.localflavor | New feature | Normal | 1.3 | fixed | Localflavor support for Slovenia (si) | Attached patch provides checking for: personal id number for slovenia, tax number, postal codes and a postal code widget. Slovenian localflavor patch done in collaboration with Gasper Zejn and Domen Kozar. | nobody | Jure Cuhalev <gandalf@owca.info> | 0 | 1 | 1 | 0 | 0 | 0 | |
16179 | 2011-06-09 09:21:48 | 2011-09-28 16:12:30 | 2022-03-06 04:02:29.607101 | Unreviewed | closed | contrib.formtools | New feature | Normal | dev | fixed | Formwizard enhancement proposal | I'd like to propose the following changes to the formwizard: Add **kwargs to the get_initkwargs method to allow for calling the wizard from the urls.py with changed attributes (storage, template_name) The reasons behind this that the same wizard might be used in multiple locations and you might for instance want to change the storage backend based on the fact if the user is logged in or not. Add extra_context as a default attribute and use it in the get_extra_context, this I needed when I tried to get the wizard integrated in the admin add and change views. Here some extra context for the templates is needed to get everything working correctly (breadcrumbs etc). This way a user could specify a wizard that is also used in the frontend without needing to change anything for the admin. I'll be working on this during the djangocon eu 2011 sprints :) | nobody | hvdklauw | dceu2011 | 0 | 1 | 0 | 0 | 0 | 0 |
16203 | 2011-06-09 16:12:10 | 2012-01-02 19:56:09 | 2022-03-06 04:02:33.376412 | Accepted | closed | contrib.admin | Bug | Release blocker | 1.3 | fixed | 'servers' test fails on Windows | The failure happens because the expected path is normalized with os.path.normcase, but the actually returned path is not. {{{ C:\Python27\python.exe C:/src/django/django/tests/runtests.py --settings=test_sqlite servers Creating test database for alias 'default'... Creating test database for alias 'other'... F ====================================================================== FAIL: test_media_urls (regressiontests.servers.tests.AdminMediaHandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\src\django\django\tests\regressiontests\servers\tests.py", line 62, in test_media_urls "Got: %s, Expected: %s, URL was: %s" % (output, desired, url)) AssertionError: Got: C:\src\django\django\django\contrib\admin\media\css\base.css, Expected: c:\src\django\django\django\contrib\admin\media\css\base.css, URL was: /static/admin/css/base.css ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) Destroying test database for alias 'default'... Destroying test database for alias 'other'... }}} | nobody | intelliyole | 0 | 1 | 0 | 0 | 0 | 0 | |
16188 | 2011-06-09 13:29:44 | 2012-10-12 21:19:18 | 2022-03-06 04:02:30.921564 | Ready for checkin | closed | Internationalization | Cleanup/optimization | Normal | dev | fixed | Added locale formats for swiss german language | The swiss german number formats are slightly different than the german ones: {{{ DECIMAL_SEPARATOR = '.' THOUSAND_SEPARATOR = "'" }}} [http://lh.2xlibre.net/locale/de_CH/] | ojii | sspross | locale, formats | 1 | 1 | 0 | 0 | 0 | 0 |
16192 | 2011-06-09 14:06:02 | 2014-02-08 10:00:33 | 2022-03-06 04:02:31.521404 | Accepted | closed | Database layer (models, ORM) | New feature | Normal | dev | fixed | Make unique_together error messages in ModelForms customizable | This is related to ticket #8913 and Google groups discussion: http://groups.google.com/group/django-developers/browse_thread/thread/6306fea94a537c3b Allow developers to specify a unique_together custom error_message on their model. This is more difficult than #8913 since the syntax is less obvious. Should there be something in the Meta? | nobody | leahculver | 0 | 1 | 0 | 0 | 0 | 0 | |
16205 | 2011-06-09 18:24:36 | 2014-04-08 15:29:30 | 2022-03-06 04:02:33.640537 | Accepted | closed | Documentation | New feature | Normal | dev | fixed | Beginners install guide for Windows | When people are completely new to Python and Django there are often easy to stumble upon certain show stoppers making the interest fade away. When people are attending basic tutorials or classes, there should be an easy way to get Django installed as fast as possible. This is not well documented for the Windows platform. Documentation on how to get a basic Django environment running on Windows is included as a rst file. I have not made a lot of thoughts of where in the documentation this should be included. Maybe as a topic? Or in intro? Comments and improvements are more than welcome. | anubhav9042 | erlingbo | install, windows | 0 | 1 | 0 | 0 | 0 | 0 |
16184 | 2011-06-09 11:49:33 | 2014-06-28 14:33:13 | 2022-03-06 04:02:30.291821 | Accepted | closed | GIS | Bug | Normal | dev | fixed | GeoDjango inspectdb fails for PostGIS | !GeoDjango inspectdb fails for PostGIS if there are more data types 'geometry' (in more schemas) because PostGISIntrospection.get_postgis_types() is taking simply the first one. Patch is attached. Another problem is that PostGISIntrospection.get_geometry_type() raises exception if a geometry column has no record in geometry_column which is quite usual. In that case I would suggest to return simply {{{ return 'TextField', {} }}} instead of raising exception. | nobody | radim.blazek@gmail.com | inspectdb | 0 | 1 | 0 | 1 | 0 | 0 |
16193 | 2011-06-09 14:23:17 | 2015-07-24 13:33:27 | 2022-03-06 04:02:31.679449 | Accepted | closed | Testing framework | New feature | Normal | dev | fixed | Use qunit to test javascript in django source | Use qunit to test javascript in django source, especially in contrib.admin. I have a patch which tests some Date functions in core.js in the admin. | slurms | mbraak@ridethepony.nl | testing javascript qunit | 0 | 1 | 1 | 0 | 1 | 0 |
16187 | 2011-06-09 13:03:56 | 2017-05-01 04:42:08 | 2022-03-06 04:02:30.755572 | Accepted | closed | Database layer (models, ORM) | Cleanup/optimization | Normal | dev | fixed | Refactor lookup system | There are a few tickets that propose adding new lookup types [1][2][3][4] and also one [5] that suggests adding the possibility for custom fields to have the ability to add their own lookup types. The current implementaion is not able to distinguish between field names and lookup types when querying through a relation. I briefly talked about this topic with Russel, Janis and Alex at the djangocon.eu 2011 sprints. The consensus was that it would be worthwile to do a refactor in this area. It would also allow django to have "awesome fields" as Alex called it :) I'm starting this ticket to track work in this area and also "bundle" the other related tickets. I'll also attach a patch with a basic testcase that fails with the current implementation. [1] #8424 [[BR]] [2] #9596 [[BR]] [3] #10911 [[BR]] [4] #12489 [[BR]] [5] #14263 [[BR]] | akaariai | UloPe | 0 | 1 | 1 | 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 );