42 rows where "changetime" is on date 2007-02-26

View and edit SQL

Suggested facets: stage, component, type, severity, version, owner, has_patch, needs_better_patch, needs_docs, created (date), last_pulled_from_trac (date)

changetime (date)

  • 2007-02-26 · 42
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
317 2005-08-14 08:01:21 2007-02-26 11:42:12 2019-06-24 00:18:38.972877 Accepted closed Generic views defect normal 0.95 fixed [Patch] slugify delimits words by hyphens, but its validator doesn't like them ''. words separated by underscores ("_") or hyphens ("-") in URLs. Google will treat "keyword-phrase" as "keyword phrase" and "keyword_phrase" as "keywordphrase.'' - google handles _ and - differently, where the - form usually is what the user needs. So the slugify code should just handle multi-word sentences by delimiting the slugified words by hyphens. jacob hugo <gb@bofh.ms> slugs slug slugify validation 0 1 0 0 0 0
639 2005-10-17 21:23:25 2007-02-26 17:17:11 2019-06-24 00:22:05.105867 Accepted closed Core (Other) defect major   fixed Model FileFields empty on first pass through save() For models with file fields ({{{FileField/ImageField etc.}}}) save() is called twice on manipulator form submission - the first time the _pre_save() and _post_save() hooks are called the file fields are empty meaning that you must explicitly check that the field value is not empty string before taking any related action. This behaviour seems confusing and I think it explains this problem: http://groups.google.com/group/django-users/browse_frm/thread/99a9aa63b343d27e?tvc=1&q=filefield+_post_save adrian django@kieranholland.com   0 0 0 0 0 0
760 2005-11-09 10:52:24 2007-02-26 17:45:33 2019-06-24 00:23:22.109736 Accepted closed contrib.admin defect normal   wontfix Error reason not seen when 500 template is missing When DEBUG = False (production environment) and an error happens, and the 500 template is not provided - one gets a traceback about the template not existing, but does not get a traceback for the exception that caused the actual failure. turkey wojtek@brandlay.com   0 0 0 0 0 0
834 2005-11-18 14:48:04 2007-02-26 22:19:03 2019-06-24 00:24:09.253409 Ready for checkin closed Documentation defect minor 0.91 fixed authentication documentation should document the viewfuncs in django.views.auth.login It's a missing part in the auth documentation: the user is told how to hook a viewfunc into authentication, but not how to do the actual login functionality. Maybe that should be added to the documentation, those views are quite handy. adrian hugo   0 0 0 0 0 0
1027 2005-12-08 08:54:29 2007-02-26 21:16:28 2019-06-24 00:26:11.733553 Unreviewed closed contrib.admin defect normal   invalid AutoTimeField raises KeyError if included in META.admin.fields see: http://groups.google.com/group/django-users/browse_thread/thread/c6f657572ed23984/81ee8f9b17d3e208#81ee8f9b17d3e208 for discussion I'm not sure if anything is wrong here or what the intended behaviour should be... probably consistency. AFAICS any field that has editable=False and is included in the META.admin.fields will throw KeyError so presumably this should be true for DateTimeFields and DateFields as well. What would probably be nicer though is if editable=False and inclusion in the Admin would be valid and non-editable fields would be just that: not editable. adrian deric <deric@monowerks.com>   0 0 0 0 0 0
1248 2006-01-19 19:26:03 2007-02-26 21:48:11 2019-06-24 00:28:31.683026 Design decision needed closed Documentation enhancement minor   wontfix [patch] API Reference The online docs are great, but an organized API Reference would be very useful. One popular generator is Epydoc (http://epydoc.sourceforge.net/). jacob linicks@gmail.com API Reference 0 1 0 0 0 0
1383 2006-02-21 14:31:37 2007-02-26 22:39:44 2019-06-24 00:29:58.064742 Unreviewed closed contrib.admin defect normal 0.91 worksforme ManyToManyField to a class with a OneToOneField fails This refers to django 0.91. Under the following circumstances, the admin pages for class C fail on update: class A(meta.Model): name = meta.StringField(maxlength=60) class B(meta.Model): a = meta.OneToOneField(A) class C(meta.Model): b = meta.MultiToMultiField(B) Inserting works, but as soon as you update, there's a bug in the following line: file core/meta/__init__.py, lines 1139-1140 def method_set_many_to_many(rel_field, self, id_list): current_ids = [obj.id for obj in method_get_many_to_many(rel_field, self)] ^^^^^^ Since B is a "child" in a OneToOneField, it does not get an "id" attribute (instead, the primary key is in the object attribute b_id). adrian mir@django.m1.spieleck.de OneToOneField 0 0 0 0 0 0
2014 2006-05-26 21:49:39 2007-02-26 04:35:40 2019-06-24 00:36:40.048835 Ready for checkin closed Validators enhancement normal master fixed [patch] Error messages of RequiredIfOtherField* validators are not userfriendly When working with RequiredIfOtherFieldEquals and RequiredIfOtherFieldDoesNotEqual validators the error messages can be quite user unfriendly. Assuming you have a select-box named 'action' where the currently selected option has a value of 2 and a label of 'Forward Message to' you get error messages like:[[BR]] ''This field must be given if action is 2'' That sort of let's the user sit there feeling dumb. 2, where does that 2 come from and what does it mean ??? With the attached patch applied you can have error messages like:[[BR]] ''This field must be given if action is Forward Message to'' The label is passed as a third, optional, argument to the validators constructor. e.g.:[[BR]] RequiredIfOtherFieldEquals('action', 2) becomes:[[BR]] RequiredIfOtherFieldEquals('action', 2, 'Forward Message to') This is a backwards compatible change. jacob Steven Armstrong   0 1 0 0 0 0
2386 2006-07-21 02:35:12 2007-02-26 22:25:59 2019-06-24 00:40:37.595865 Accepted closed Generic views defect normal master duplicate [patch]previous_month and previous_day are non-empty even if there are no objects in previous months/days Yes, I know this is documented behavior, but it is completely illogical. In the {{{django.views.generic.date_based}}} generic views, {{{previous_month}}} and {{{previous_day}} are not empty when there are no objects in previous months/days. {{{next_month}}} and {{{next_day}} are empty when there are no next months and days, which is logical. I'd expect {{{previous_month}}} and {{{previous_day}} to be empty when there are no objects in the previous months/days. How else are you supposed to implement date-based navigation? adrian Tyson Tate <tyson@fallingbullets.com> previous_month previous_day genericviews 0 1 1 0 1 0
2440 2006-07-27 22:42:02 2007-02-26 18:05:59 2019-06-24 00:41:12.141466 Unreviewed closed Template system enhancement normal master wontfix Template Loader for PHP files (integrate django into existing PHP site) There are a number of sites out there which already have a PHP framework for the base page generation. Some of them use other tools like Zope, RoR or J2EE to do CMS style applications for which PHP is not a good fit. Switching to django is difficult because there is no easy way to integrate the two. For [http://us.pycon.org/apps/roomy/tables/ PyCon06] we created a custom template loader. A template name prefixed with 'php:' denotes passing the template throught the PHP process and returning the result. The initial template is loaded from the loader system as well. This worked better than a custom inclusion tag because it works with the base template loader calls and regular template include tags. (Some django templates get the sub-template name to include from the context and do not know to load some custom tag or to use a custom include tag) The base PHP template (index.php) needs to be accessable via TEMPLATE_DIRS and has html like: {{{ <html> <head> <title><!-- {% block title %} -->PyCon<-- {% endblock %} --></title> </head> <body> <!-- imagine a bunch of menu and other html here --> <!-- {% block body %} --> <!-- {% endblock %} --> </body> </html> }}} for example, and can be used for all the regular php generated pages, or when included in a django template, overloaded. In this example you need to remember to do something like: {{{ {% include "php:index.php" %} {% block body %} --> <!-- django template code here --> -->{% endblock %} }}} The loader has been converted to 9.5, works on both unix and windows, is highly configurable, and can use the cache system (because PHP executions may be expensive). It does not use any temporary files (uses the subprocess module and pipes the stdin/stdout). Due to complications with windows IO blocking, threading is used by default on that OS. {{{ # optional settings.py options for this loader: PHP_BIN # defaults to: unix='/usr/bin/php', win32='php.exe') PHP_ARGS # defaults to: ['-q',] (supress http header… adrian django@dougma.com template loader PHP 0 0 0 0 0 0
2490 2006-08-06 03:37:33 2007-02-26 22:34:56 2019-06-24 00:41:44.159489 Accepted closed Testing framework enhancement minor master fixed [patch] make runtests.py error messages more user friendly Patched to check if environ has a DJANGO_SETTINGS_MODULE, when no --settings arg. is present. If no settings module is found, it attempts to load settings.py in the runtests dir. If that doesn't work, then it displays the usage/help and an error message asking for --settings. I'm aware of ticket:2333 to improve the test framework, but this had me stumped for a while, and might make it easier for others to write/use tests. adrian dev@simon.net.nz   0 1 1 0 1 0
2592 2006-08-23 02:30:57 2007-02-26 20:51:21 2019-06-24 00:42:49.189375 Accepted closed Documentation enhancement normal   fixed [patch] tutorial01.txt should note that you can't name your site "site" My very first experience with Django, I executed the command : {{{ django-admin.py startproject site }}} And the rest of the tutorial didn't work. I then deleted the site folder, and did it again, this time with a folder named "www" it worked that time. Does this mean the site can't be named site? jacob marcdm@phronein.com tutorials 0 1 0 0 0 0
2642 2006-09-02 03:58:02 2007-02-26 01:04:16 2019-06-24 00:43:21.969800 Unreviewed closed Generic views defect minor 0.95 duplicate Timezone handling is incorrect: Uses GMT instead of localtime Hi from sunny New Zealand. I'm playing around at writting a blog system, and there seems to be some problems with the date and time handling. Using plain old vanilla python on Freebsd, the time functions return correct values. e.g. {{{ [smurf@black psc]# python Python 2.4.1 (#2, Apr 24 2005, 12:02:35) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import os, datetime, time >>> time.localtime() (2006, 9, 2, 15, 42, 26, 5, 245, 0) >>> time.gmtime() (2006, 9, 2, 3, 42, 37, 5, 245, 0) >>> }}} In my settings.py the timezone is set to TIME_ZONE = 'Pacific/Auckland NZ'. But, alas, the time values produced under django are out, viz: {{{ [smurf@black psc]# python manage.py shell Python 2.4.1 (#2, Apr 24 2005, 12:02:35) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> import datetime, os, time >>> time.localtime() (2006, 9, 2, 3, 42, 57, 5, 245, 0) >>> time.gmtime() (2006, 9, 2, 3, 43, 16, 5, 245, 0) }}} Note the 12 hour differnce between the 15 and the 3. Okay that shouldn't be too much of a problem but when django updates the datebase (say by adding something through the admin interface) the date a time on the object is something like "2006-09-02 15:24:00". In otherwords the datebase is updated using the correct localtime. And when django iterates over the objects using the generic views, because it uses the incorrect localtime; it thinks that the objects date is 12 hours or so in the future and consequently doesn't include it (unless of course, I set allow_future to True, which I don't want to do). jacob psmith@consulting.co.nz timezone 0 0 0 0 0 0
2759 2006-09-18 17:20:40 2007-02-26 01:02:10 2019-06-24 00:44:35.927184 Accepted closed Generic views defect normal   worksforme "allow_future" missing from date based generic views Allow_future is in doc. I've Added to my local copy for classes I need. I still don't know how to contribute, though. jacob anonymous   0 0 0 0 0 0
2828 2006-09-26 18:45:41 2007-02-26 19:12:31 2019-06-24 00:45:18.947332 Ready for checkin closed contrib.admin defect normal   fixed TypeError when deleting objects with ManyToMany(self) relationships in the admin When trying to delete an object with a ManyToMany(self) relationship you get a "TypeError getattr(): attribute name must be string". Have played a little around it and it seems to work correctly when adding "filter_interface=models.HORIZONTAL" to the ManyToManyField(self) Field. Error: TypeError at /admin/person/person/2/delete/ getattr(): attribute name must be string Produces an error: {{{ class Person(models.Model): name = models.CharField(maxlength=20) friends = models.ManyToManyField('self',blank=True) idols = models.ManyToManyField('self', symmetrical=False,related_name='stalkers',blank=True) def __str__(self): return self.name class Admin: pass }}} Works ok: {{{ class Person(models.Model): name = models.CharField(maxlength=20) friends = models.ManyToManyField('self',blank=True) idols = models.ManyToManyField('self', symmetrical=False,related_name='stalkers',blank=True,filter_interface=models.HORIZONTAL) def __str__(self): return self.name class Admin: pass }}} adrian anonymous   0 1 0 0 0 0
3135 2006-12-12 12:27:15 2007-02-26 21:18:31 2019-06-24 00:48:39.634422 Accepted closed Documentation defect major   fixed Docs should clearly explain the "error message e-mails" feature Yes, I'm marking this as a high-priority bug, because it's serious. I like the error message e-mails. It can be a lifesaver. However, in high-traffic websites, a simple error message can lead to hundreds (even thousands) of e-mails sent to the admins. That can easily lead to the inclusion of the provider in spam-blocking lists (and many angry coleagues and customers yelling at you). The worst thing is, it's not clear that you can *NOT* turn such feature off. So, the docs should make things clear. jacob joaoma@gmail.com docs email ADMINS MANAGERS 404 0 1 1 0 0 0
3170 2006-12-20 05:00:48 2007-02-26 04:53:44 2019-06-24 00:49:02.153334 Ready for checkin closed Generic views enhancement normal   fixed [patch] object_list should pass last_on_page and first_on_page I think these are important for pagination because they help orientate the user. E.g. "Results foo - bar of baz". jacob Grimboy   0 1 0 0 0 0
3172 2006-12-20 05:31:38 2007-02-26 05:07:12 2019-06-24 00:49:03.421445 Ready for checkin closed Database layer (models, ORM) defect normal master fixed Model.validate raises TypeError on NULL for DateField, DateTimeField, and TimeField When you have a model with any of the date/time fields, it throws a TypeError. For example: {{{ class TestModel(models.Model): test_date = models.DateField() test_date_time = models.DateTimeField() test_time = models.TimeField() TestModel().validate() Traceback (most recent call last): File "<console>", line 1, in ? File "django/db/models/base.py", line 230, in validate setattr(self, f.attname, f.to_python(getattr(self, f.attname, f.get_default()))) File "django/db/models/fields/__init__.py", line 435, in to_python validators.isValidANSIDate(value, None) File "django/core/validators.py", line 146, in isValidANSIDate if not ansi_date_re.search(field_data): TypeError: expected string or buffer }}} Similar errors appear with DateTime and Time. adrian RahmCoff@Radio1190.org   0 1 0 0 0 0
3241 2007-01-06 23:31:22 2007-02-26 22:23:17 2019-06-24 00:49:46.947993 Design decision needed closed Core (Cache system) enhancement normal master wontfix [patch] memcached backend can't use keys containing spaces I wanted to use memcached to cache pages whose URLs contain spaces, but was told 'Client.MemcachedKeyCharacterError, "Control characters not allowed"'. The memcache module refuses to use keys longer than 250 characters or containing "control characters", which it defines as anything with a decimal ASCII code below 33 -- which includes the space character. So the attached memcached backend uses a hash (SHA1) of the URL as the cache key as necessary. Seems to perform OK in my limited seat-of-the-pants usage; I suppose urllib.quote might be faster, but wouldn't help with long URLs. jacob recalcitrare@gmail.com memcached 0 1 0 0 0 0
3249 2007-01-08 04:11:45 2007-02-26 05:07:54 2019-06-24 00:49:52.137409 Ready for checkin closed Documentation defect trivial master fixed [patch] inconsistent documentation on pagination with generic view object_list in the text to the optional parameter paginate_by it says {{{ The view will expect either a page query string parameter (via GET) containing a zero-indexed page number, or a page variable specified in the URLconf. See "Notes on pagination" below. }}} and in the mentioned "Notes on pagination" it says {{{ In both cases, page is 1-based, not 0-based, so the first page would be represented as page 1. }}} jacob Nikolaus Schlemm <nikl@nikl.net> inconsistent documentation on pagination 0 1 0 0 0 0
3251 2007-01-08 17:01:09 2007-02-26 08:23:33 2019-06-24 00:49:53.379128 Accepted closed Translations task normal   fixed [patch] Translation File for Kannada .po file with Kannada translations locale/kn Translation done by volunteers at http://dev.sampada.net - Kannada Localization Team. hugo pradeep.gowda@gmail.com translations kannada 0 1 0 0 0 0
3279 2007-01-11 00:59:47 2007-02-26 21:25:22 2019-06-24 00:50:10.923476 Design decision needed closed Documentation defect normal master fixed python-mysql-1.2.0 has a bug with threading, raising 'ReferenceError: weakly-referenced object no longer exists' I'm getting the following error every so often from a revision checked out on Jan 02, 2007. Sorry... I updated before checking the revision number. Jan 02 puts it somewhere between r4270 and r4274. {{{ 2007-01-10 16:36:40: (mod_fastcgi.c.2502) FastCGI-stderr: Traceback (most recent call last): File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 558, in run File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 1112, in handler File "/usr/lib/python2.4/site-packages/django/core/handlers/wsgi.py", line 193, in __call__ response = middleware_method(request, response) File "/usr/lib/python2.4/site-packages/django/contrib/sessions/middleware.py", line 81, in process_response session_key = request.session.session_key or Session.objects.get_new_session_key() File "/usr/lib/python2.4/site-packages/django/contrib/sessions/models.py", line 21, in get_new_session_key self.get(session_key=session_key) File "/usr/lib/python2.4/site-packages/django/db/models/manager.py", line 67, in get return self.get_query_set().get(*args, **kwargs) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 211, in get obj_list = list(clone) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 103, in __iter__ return iter(self._get_data()) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 430, in _get_data self._result_cache = list(self.iterator()) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 172, in iterator cursor.execute("SELECT " + (self._distinct and "DISTINCT " or "") + ",".join(select) + sql, params) File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line 137, in execute self.errorhandler(self, exc, value) File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line 33, in defaulterrorhandler raise errorclass, errorvalue ReferenceError: weakly-referenced object no longer exists }}} Let me know if there's any more info yo… adrian wbyoung@mcdonogh.org   0 1 0 0 0 0
3319 2007-01-18 10:11:55 2007-02-26 21:36:14 2019-06-24 00:50:36.273166 Ready for checkin closed Documentation     master fixed [patch] django-admin.py/manage.py documentation missing a couple options The [http://www.djangoproject.com/documentation/django_admin/ official documentation] for `django-admin.py` and `manage.py` are missing documentation for two options: `reset` and `runfcgi`. The `reset` docs should be fairly simple to add, and I can work up a patch easily enough. I'm not sure about the best way to handle `runfcgi`, though; perhaps it should give a short summary (e.g., "launches the project as a FastCGI application") and link to the [http://www.djangoproject.com/documentation/fastcgi/ FastCGI deployment docs] for further information? jacob ubernostrum   0 1 0 0 0 0
3325 2007-01-18 21:00:36 2007-02-26 23:23:01 2019-06-24 00:50:40.093102 Ready for checkin closed Documentation     master fixed Include distribution specific notes The installation document does not cover distribution specific notes (like which packages to install and so on) and, belive or not, there are distributions that provide Django packages!! On the attachments there is: * install.diff where a note has been added linking to "distribution specific notes" * distributions.txt where distribution specific notes could be placed, I added the ones for Debian. I put it on a separate file as those instructions can get larger and there are lots of distributions around there. To advocate for the patch: * It makes it easier for people: "apt-get install python-django python-sqlite2" and you're on the road! * User gets Django upgraded automatically (that's the nice thing of having software packaged) * It places one more site that talks about Debian hehehehe. Hope it's ok, could not find any info about "extending" the documentation. jacob Marc Fargas <telenieko@telenieko.com>   0 1 0 0 0 0
3354 2007-01-23 12:14:52 2007-02-26 05:15:52 2019-06-24 00:50:58.532413 Ready for checkin closed Documentation     master fixed Tutorial pages on website should direct users to django-users with problems I've just cleaned up #2592 and cross-referenced it with comments on the tutorials. Most of the comments on there are simple misconfigurations, or errors where the user hasn't followed the tutorial closely enough, and these should be directed to django-users/#django where they can be helped quickly, or asked to file a ticket if there's a bug. This would also have two follow on effects: First, it would leave a better impression on people than having 15-20 outdated and contradictory comments complaining that Django doesn't work. Second, it would increase visibility of common issues that people have with the tutorials so they can be fixed (because these are the first encounter with Django, we need to make them as smooth as possible). For example: {{{ If you have any problems with this tutorial, please post a message to django-users (http://groups.google.com/group/django-users) or drop by #django on IRC (irc://irc.freenode.net/django) and we'll try to help. If you think you've found a bug, please file open a ticket at http://code.djangoproject.com/simpleticket }}} jacob Simon G. <dev@simon.net.nz> docs 0 1 0 0 0 0
3390 2007-01-29 13:02:55 2007-02-26 17:33:28 2019-06-24 00:51:21.200766 Design decision needed closed Core (Serialization)     master fixed Deserializer cannot handle circular and forward references to object instances The current deserializers are not able to represent circular references between objects, or forward references to objects. This is because the reconstruction of m2o and m2m relations calls on the database API to resolve the ID's mentioned in the serialization string into object instances which can be saved. Therefore, if an object has not been saved, it cannot be successfully referenced in a serialization file. This is a serious impediment to the use of serialization files for test fixtures and database migration (see ticket #2333). To overcome this, I submit this modification to the deserializer that bypasses the database lookup step. The revised deserializer saves the primary key values defined in the serialization file directly into the object. This is the equivalent of doing: {{{ Article.author_id = 3 }}} instead of: {{{ Article.author = Author.objects.get(pk=3) }}} As well as being more flexible, it has the advantage of being faster (in that it requires less database lookups). In order to work for m2m relations, this patch requires that patch #3389 be applied (this patch allows assignment of m2m sets using pk values). This relatively simple approach works fine for all database backends except one - Postgres. Because Postgres has and enforces data consistency, it is not possible to INSERT an object with a foreign key value that does not have a corresponding entry in the foreign table. To work around this problem, I have modified table declarations to make all cross-table references DEFERRABLE INITIALLY DEFERRED. This has the effect that the row constraints and consistency checks are not executed until the end of each transaction, rather than after every insert (although if transactions are not in use, there is no difference in behaviour). In this way, if the deserialization process is placed inside a transaction, it is possible to deserialize an arbitrarily complex graph of foreign key relationships, and consistency is only checked once the entire graph has been deserialize… jacob russellm JSON deferrable deserialization circular forward reference 0 1 1 0 0 0
3396 2007-01-29 22:20:20 2007-02-26 19:01:09 2019-06-24 00:51:25.020720 Accepted closed Testing framework     master fixed test_client unittest fails under python 2.3 Running the Unittests for Django the following errors occur. {{{ $python runtests.py --settings=testdj.settings ====================================================================== ERROR: Request a page that is protected with @login, but use bad credentials ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/www/local/django/tests/modeltests/test_client/models.py", line 101, in test_view_with_bad_login self.assertFalse(response) AttributeError: 'ClientTest' object has no attribute 'assertFalse' ====================================================================== ERROR: Request a page that is protected with @login_required ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/www/local/django/tests/modeltests/test_client/models.py", line 92, in test_view_with_login self.assertTrue(response) AttributeError: 'ClientTest' object has no attribute 'assertTrue' ====================================================================== FAIL: POST an empty dictionary to a view ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/www/local/django/tests/modeltests/test_client/models.py", line 53, in test_empty_post self.assertEqual(response.status_code, 200) File "/usr/lib/python2.3/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 500 != 200 ---------------------------------------------------------------------- Ran 68 tests in 6.298s FAILED (failures=1, errors=2) }}} adrian Robert Myers <myer0052@gmail.com>   0 1 1 0 0 0
3438 2007-02-06 00:38:40 2007-02-26 06:16:19 2019-06-24 00:51:51.605826 Unreviewed closed Core (Other)     master fixed django.db.models.base.__init__ refactoring Short version; for iteration over records, there model's __init__ is rather unfriendly to the way the args are passed in. At least for sqlite, the sql row is passed in as args- issue is that __init__ shoots through self._model.fields playing with kwargs prior, doing rather costly exception catching, pulling default values, etc, then *finally* does args processing. If you're dealing in one or two records, this doesn't show up much, but if you're dealing in 53k records (my usage is slightly weird admittedly), it's a pretty heavy slow down. attached is a patch to refactor __init__, knocking around a third off the __init__ cost via refactoring the args/kwargs processing, essentially reversing the actual flow while maintaining the same behaviour as before. Have been using it for a few days, and passes tests; comments welcome, mainly since I need to get this integrated for my uses. adrian (removed)   0 1 0 0 0 0
3439 2007-02-06 01:07:33 2007-02-26 03:42:25 2019-06-24 00:51:52.271342 Accepted closed Core (Other)     master fixed django.dispatch.* is grossly slow Attached is a refactoring chopping off a good chunk of dispatch's overhead; hard to test it standalone, so testing was done for simple iteration over records and isolating the diff in the profiling for the refactoring. Short version, attached patch shows 5x boost in dispatch speed; for iteration (just that, no rendering) over 53k records, time drops from ~15.5s to ~11.6s just by cleaning up dispatch.* The internal data structs dispatch is using are still fairly innefficient- scaling will be an issue the more receivers there are for dispatched signals. So... can clean that up further, but there isn't any documentation re: the expectations of dispatcher. For example- order of connection to a signal, must the order be maintained for notifications at a specific sender/signal level? If I connect (in this order) func f1, func f2, both to object("foo") signal Any, must they be notified in order f1,f2? I realize pydispatcher is a seperate project- that said, they've already moved onto 2.0, and there are several 1.0.x's for pydispatcher released already- djangos' bundled copy is still at 1.0.0. Whats the intention? Intending on keeping it in sync, or is it just a fork point? Either way, the attached refactoring is not covered by tests at the moment- mainly since there are no tests in django for dispatcher. Would like to get feedback on the expectations of dispatcher (f1/f2 from above for example) prior to writing those tests, since the implementation (and google for that matter) lack any material on it. Finally, due to the massive number of calls to send (thus to getAllReceivers and friends), normal seperation (getAllReceivers using getReceivers for example) was intentionally broken down a bit- in other words, inlined a few functions. The codes invoked enough that the overheads seperation really isn't worth it, especially if you're not actually using signals for the most part (thus dispatcher is pretty much pure time waste). adrian (removed)   0 1 0 0 0 0
3448 2007-02-07 04:29:42 2007-02-26 05:19:32 2019-06-24 00:51:57.899357 Ready for checkin closed Documentation     master fixed python help() parsing problem for django.core.mail == Error when accessing django.core.mail through python help() == {{{ EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined }}} In python help(), if I do: {{{ help> django.core.mail }}} I get: {{{ problem in django.core.mail - EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined. }}} Other things in the django.core package display their docstrings and such.. It seems like something basic, but I didn't see anything obvious. I'm on OS X 10.4.8, python 2.4.4, installed the source from the svn repository, e.g. 'python setup.py install' jacob Michael VanLandingham <m.vanland@gmail.com> django.core.mail, help, docs 0 1 0 0 0 0
3455 2007-02-08 05:19:43 2007-02-26 21:40:16 2019-06-24 00:52:02.275961 Ready for checkin closed Documentation     master fixed Documentation for "choices" should mention "get_FOO_display" The documentation for the `choices` attribute on model fields mentions that `choices` should be a tuple of 2-tuples, including an actual value and a human-readable name, but documentation on how to retrieve the human-readable name of the selected choice from an instance of the model lives elsewhere, in the database API documentation, under the unintuitive name of `get_FOO_display`. This hinders a new user of Django trying to understand how best to make use of `choices`. At the very least, the model documentation should include, under `choices`, a link to the `get_FOO_display` entry in the DB documentation for an explanation of how to get the human-readable name back out of a model instance. Ideally, we'd do that and come up with better titles for the sections on the various `get_FOO_display`/`get_next_by_FOO`/etc. methods. jacob ubernostrum choices get_FOO_display 0 1 0 0 0 0
3517 2007-02-17 17:38:32 2007-02-26 08:18:59 2019-06-24 00:52:41.530202 Ready for checkin closed Translations     master fixed [patch] Updated Slovenian translation Attached is updated Slovenian (sl_SI) translation. hugo Jure Cuhalev <gandalf@owca.info> l10n 0 1 0 0 0 0
3531 2007-02-19 23:01:57 2007-02-26 15:39:00 2019-06-24 00:52:50.268597 Unreviewed closed Database layer (models, ORM)     master invalid ImageField - possible script injection ImageField field validates files using MIME which isn't 100% ok. It will allow uploading *py *php *pl or any other file extension when it will have image MIME signature at the beginning: {{{ cat image.png code.php > upload_me.php }}} It's dangerous for shared hosting and other where media folders can execute scripts like PHP where <?PHP starts the code and makes the binary image part meaningless for the interpreter ([http://www.fotosik.pl/showFullSize.php?id=3a0f587509d2b2d0 could look like this]). Example: [http://www.fotosik.pl/showFullSize.php?id=497419b9cfb92838 screenshot] - 11.py uploaded as image. '''Check the extensions''' adrian Piotr Maliński <riklaunim@gmail.com>   0 0 0 0 0 0
3535 2007-02-20 10:24:19 2007-02-26 08:26:58 2019-06-24 00:52:52.716741 Ready for checkin closed Translations     master fixed Serbian (sr) translation update   hugo nesh <nesh [at] studioquattro [dot] co [dot] yu> l10n serbian 0 1 0 0 0 0
3547 2007-02-22 00:09:37 2007-02-26 17:45:48 2019-06-24 00:53:00.183487 Unreviewed closed Database layer (models, ORM)     master duplicate OneToOneField is not validated as a required field, nor do explicitly defined isNotEmpty validators fire OneToOne field's don't properly validate the requirement that there _must_ be one object on each side of the relationship. after adding a model (Person) with a OneToOne field to User, i can go into the django admin and attempt to create a new person and leave the user field empty. no validation errors are returned (for example, "This is a required field"). if all other fields are valid, an uncaught type mismatch error will bubble up to the surface. i tried explicitly adding my own isNotEmpty validator to the field, but that doesn't seem to trigger, either. is this just the way things are, and i should use ForeignKey with unique=True? this works, and i can still use u.get_profile() (if i've configured AUTH_PROFILE_MODULE in settings.py, but this doesn't help if i have multiple apps within a project which have their own distinct extensions to User. u.get_profile() will only work for one of them, and only works when extending User, not when extending any model in a OneToOne manner generally, and is also tied to the idea of the extending model being a "profile". imho it would be nice to keep the u.person mapping in the ORM, either by using OneToOne fields (which could just be a ForeignKey with unique=True behind the scenes, plus an extra mapping on the user instance), or by adding some logic to ForeignKey which adds the extra mapping if unique=True. adrian mrmachine <real dot human at mrmachine dot net> OneToOne required validation validators 0 0 0 0 0 0
3555 2007-02-23 17:06:27 2007-02-26 08:48:46 2019-06-24 00:53:05.274188 Ready for checkin closed Translations     master fixed Swedish django.po file inaccurate. The Swedish django.po file in django/conf/locale/sv/LC_MESSAGES/ is inaccurate. I took the time to translate it into better Swedish, I do not guarantee that it is perfect, but it is definitely closer. hugo ludvig.ericson@gmail.com swedish translation l10n 0 1 1 0 0 0
3561 2007-02-24 11:59:55 2007-02-26 08:30:14 2019-06-24 00:53:08.952662 Unreviewed closed Translations     master fixed German translation update Hello, i've done a proof reading of the German translation and translated a few new strings in the development version while i was at it (using po files from r4557). I checked not only for typos, but also for consistency and style. For instance, there where two different terms used for 'password'. There are several German translators listed at the Localization page, but it's hard to tell who's the current maintainer. Maybe he wants to have a look at the attached translation files. Best Regards, Dirk Eschler hugo Dirk Eschler <dirk.eschler@gmx.net> german, translation, update, i18n 0 0 0 0 0 0
3562 2007-02-24 12:57:21 2007-02-26 08:32:59 2019-06-24 00:53:09.582970 Ready for checkin closed Translations     master fixed macedonian translation update Update of the macedonian translation. hugo Georgi Stanojevski <glisha gmail com> l10n, macedonian 0 1 0 0 0 0
3565 2007-02-24 17:33:12 2007-02-26 08:54:26 2019-06-24 00:53:11.416932 Unreviewed closed Internationalization     master fixed Update spanish translation and fixed some issues with some messages This is a patch against trunk. This patch update spanish translation and fix some problems with messages on django/core/validators.py : 364 and django/contrib/admin/views/doc.py: 171, 183, 214 There is a problem that I can't fix in django/utils/html.py : 10 To sucessfuly update .po file I had to comment that line, then execute bin/make-messages.py -a -l <put your languaje here/> and remove the comment. This is the error message whithout the comment: {{{ ./bin/make-messages.py -a -l es processing language es errors happened while running xgettext on html.py xgettext: Non-ASCII string at ./utils/html.py:10. Please specify the source encoding through --from-code. }}} Thx for your amazing work and sorry for my awful english. hugo agarfu@gmail.com Spanish i18n message 0 1 0 0 0 0
3573 2007-02-25 21:07:20 2007-02-26 08:35:49 2019-06-24 00:53:16.436353 Ready for checkin closed Translations     master fixed Updated Argentinean spanish l10n files Synchronized to the state of trunk as of r4578. hugo Ramiro Morales <rm0 _at_ gmx.net>   0 0 0 0 0 0
3576 2007-02-26 12:20:53 2007-02-26 12:25:19 2019-06-24 00:53:18.311059 Accepted closed Testing framework     master duplicate `manage.py test` should return error code on test failure Massimiliano Ravelli <massimiliano.ravelli@gmail.com> suggested that when a test suite is executed using ``manage.py test``, errors in the test should be returned as an error code. At present, no test status information is returned. russellm russellm   0 0 0 0 1 0
3581 2007-02-26 16:52:29 2007-02-26 17:38:56 2019-06-24 00:53:21.497915 Ready for checkin closed Forms     master fixed related.py's OneToOneField.formfield erroneously uses kwargs instead of defaults In related.py, OneToOneField.formfield takes kwargs, initializes the defaults dict, updates the defaults dict with the contents of kwargs, then just passes kwargs to ModelChoiceField, never doing anything with defaults again. The other similar methods in the file use defaults, I assume this was a typo. Attaching the trivial patch, and setting to django.newforms since that's where #3257 which touched this was binned. adrian Andrew Sutherland <andrew@theptrgroup.com>   0 1 0 0 0 0

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE "tickets_full" (
        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