tickets
24 rows where "created" is on date 2008-08-14 and needs_better_patch = 0 sorted by owner
This data as json, CSV (advanced)
Suggested facets: changetime, stage, status, resolution, description, owner, reporter, keywords, has_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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8320 | 2008-08-14 18:20:13 | 2013-03-11 14:40:48 | 2022-03-06 03:41:56.521096 | Accepted | closed | contrib.admin | Bug | Normal | dev | fixed | Admin Transaction Management Error | When using admin from the trunk [r8346] on Ubuntu I am getting occasional tracebacks like the following. I *appears* only to happen when one of the foreign key fields is changed, or at least I haven't been able to trigger the problem without changing one of them. I am only selecting values using the drop-downs populated from the related models. Environment: * Request Method: POST * Request URL: http://test.holdenweb.com/admin/accounts/userprofile/14/ * Django Version: 1.0-alpha_2-SVN-8346 * Python Version: 2.4.3 Installed Applications: {{{ #!python ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'pages', 'grp', 'contact', 'registration', 'accounts'] }}} Installed Middleware: {{{ #!python ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware') }}} Traceback: {{{ File "/home/holdenwe/django-trunk/django/core/handlers/base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in root 172. return self.model_page(request, *url.split('/', 2)) File "/home/holdenwe/django-trunk/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in model_page 189. return admin_obj(request, rest_of_url) File "/home/holdenwe/django-trunk/django/contrib/admin/options.py" in __call__ 275. return self.change_view(request, unquote(url)) File "/home/holdenwe/django-trunk/django/db/transaction.py" in _commit_on_success 251. leave_transaction_management() File "/home/holdenwe/django-trunk/django/db/transaction.py" in leave_transaction_management 75. … | aaugustin | holdenweb | admin transaction | 0 | 0 | 0 | 0 | 0 | 0 |
| 8301 | 2008-08-14 00:20:04 | 2011-09-28 16:12:17 | 2022-03-06 03:41:53.398614 | Accepted | closed | Documentation | dev | fixed | ModelFormSet documentation is very confusing | It's very hard to understand the ModelFormSet documentation. Also ModelFormSet works directly from a Model, whereas FormSet works from a form. It would be helpful to give a more concrete example, including showing how to set which model fields are part of the form (ala Meta class). | brosner | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8324 | 2008-08-14 20:34:49 | 2011-09-28 16:12:16 | 2022-03-06 03:41:57.130434 | Accepted | closed | contrib.admin | dev | fixed | admin list display is broken | [8352] breaks simple list display. to reproduce, {{{ # models.py class Site(models.Model): name = models.CharField(max_length=255) def __unicode__(self): return self.name # admin.py from django.contrib import admin from visitdb import models as visitdb admin.site.register(visitdb.Site) }}} go to /admin, and click on Site. {{{ Environment: Request Method: GET Request URL: http://localhost:8000/django-admin/visitdb/site/ Django Version: 1.0-alpha_2-SVN-8352 Python Version: 2.5.2 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.humanize', 'visitdb', 'photologue'] Installed Middleware: ('visitdb.middleware.RequestAttributeSetup', 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'visitdb.middleware.StandardViewKwargsMiddleware') Template error: In template /home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/contrib/admin/templates/admin/change_list.html, error at line 34 Caught an exception while rendering: local variable 'attr' referenced before assignment 24 : {% if cl.has_filters %} 25 : <div id="changelist-filter"> 26 : <h2>{% trans 'Filter' %}</h2> 27 : {% for spec in cl.filter_specs %} 28 : {% admin_list_filter cl spec %} 29 : {% endfor %} 30 : </div> 31 : {% endif %} 32 : {% endblock %} 33 : 34 : {% block result_list %} {% result_list cl %} {% endblock %} 35 : {% block pagination %}{% pagination cl %}{% endblock %} 36 : </div> 37 : </div> 38 : {% endblock %} 39 : Traceback: File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/core/handlers/base.py" in get_response 86. response =… | brosner | tobias | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8317 | 2008-08-14 17:20:11 | 2012-02-05 07:51:37 | 2022-03-06 03:41:56.038335 | Accepted | closed | Core (Management commands) | Bug | Normal | dev | fixed | inspectdb does not set primary_key=True or unique=True on foreign keys | The inspectdb command will not set primary_key=True or unique=True on ForeignKey fields when the column is also a primary key. | dgouldin | bthomas | inspectdb | 0 | 1 | 0 | 1 | 0 | 0 |
| 8307 | 2008-08-14 07:05:43 | 2014-02-23 14:12:53 | 2022-03-06 03:41:54.279750 | Accepted | new | File uploads/storage | Cleanup/optimization | Normal | dev | ImageFile use of width_field and height_field is slow with remote storage backends | im attaching a patch that could make it work | jacob | sebastian.serrano@gmail.com | imagefile height width | 0 | 1 | 0 | 0 | 1 | 0 | |
| 8309 | 2008-08-14 13:46:52 | 2011-09-28 16:12:17 | 2022-03-06 03:41:54.629989 | Accepted | closed | Contrib apps | dev | fixed | GenericForeignKey fails when used in abstract base models | The following code will reproduce this bug: {{{ # aaa/models.py from django.contrib.contenttypes.models import ContentType from django.contrib.contenttypes import generic class MyModel(models.Model): field = models.IntegerField() class TaggedItemBase(models.Model): class Meta: abstract = True content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() class TaggedItem(TaggedItemBase): """A tag on an item.""" tag = models.SlugField() class Meta: ordering = ["tag"] def __unicode__(self): return self.tag # From command shell >>> from aaa.models import MyModel, TaggedItem >>> m = MyModel(field=1) >>> m.save() >>> t = TaggedItem(content_object=m, tag="my") Traceback (most recent call last): File "<console>", line 1, in ? File "/usr/lib/python2.4/site-packages/django/db/models/base.py", line 240, in __init__ raise TypeError, "'%s' is an invalid keyword argument for this function" % kwargs.keys()[0] TypeError: 'content_object' is an invalid keyword argument for this function }}} If we do not use model inheritance, the script works fine. | jacob | Wonlay | GenericForeignKey , model inheritance | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8310 | 2008-08-14 13:48:16 | 2011-09-28 16:12:16 | 2022-03-06 03:41:54.775524 | Unreviewed | closed | Uncategorized | dev | fixed | Fix usage of randint/randrange in [8340] | Usage of randint and randrange in [8340] is slightly muddled. | mtredinnick | mtredinnick | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8315 | 2008-08-14 16:51:16 | 2011-09-28 16:12:17 | 2022-03-06 03:41:55.537105 | Accepted | closed | Database layer (models, ORM) | dev | fixed | MySQL Commands out of sync on attempt to rollback | I have newest code as of this ticket. This only happens when I run django through a fastCGI on dreamhost. I have built my own python, and mysqlDB so its not dreamhosts stuff. Followed the directions in the django tutorial. Happened after a checkout so that is why I think this might be a bug, and not a support issue. Here is the Error dump. {{{ /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: Traceback (most recent call last): /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 558, in run /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: protocolStatus, appStatus = self.server.handler(self) /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "build/bdist.linux-i686/egg/flup/server/fcgi_base.py", line 1112, in handler /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: result = self.application(environ, start_response) /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "/home/varius_2/opt/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 216, in __call__ /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: response = self.get_response(request) /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "/home/varius_2/opt/lib/python2.5/site-packages/django/core/handlers/base.py", line 124, in get_response /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: receivers = signals.got_request_exception.send(sender=self.__class__, request=request) /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "/home/varius_2/opt/lib/python2.5/site-packages/django/dispatch/dispatcher.py", line 132, in send /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: response = receiver(signal=self, sender=sender, **named) /home/varius_2/loudfarm.tastestalkr.com/dispatch.fcgi" stderr: File "/home/varius_2/opt/lib/python2.5/site-packages/django/db/__init__.py", line … | mtredinnick | voidfiles@gmail.com | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8302 | 2008-08-14 03:26:19 | 2008-08-14 03:31:14 | 2022-03-06 03:41:53.539158 | Unreviewed | closed | Documentation | dev | duplicate | Documentation type-o in "Order of Middleware_Classes" | http://www.djangoproject.com/documentation/cache/#order-of-middleware-classes Look at the last word in this copy/paste: "Order of MIDDLEWARE_CLASSES If you use caching middlewaare, . . ." | nobody | defcube | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8303 | 2008-08-14 04:54:31 | 2008-08-14 04:55:19 | 2022-03-06 03:41:53.690474 | Unreviewed | closed | Uncategorized | dev | invalid | XuXBZJFrj | 2Mdu0u <a href="http://rshsbbnnfgzq.com/">rshsbbnnfgzq</a>, [url=http://qjvskwacavmt.com/]qjvskwacavmt[/url], [link=http://ryefuwskdkbq.com/]ryefuwskdkbq[/link], http://cnhoeuihcjhf.com/ | nobody | anonymous | tBNuDvuYvrMV | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8304 | 2008-08-14 04:54:34 | 2008-08-14 04:55:33 | 2022-03-06 03:41:53.851143 | Unreviewed | closed | Uncategorized | dev | invalid | XuXBZJFrj | 2Mdu0u <a href="http://rshsbbnnfgzq.com/">rshsbbnnfgzq</a>, [url=http://qjvskwacavmt.com/]qjvskwacavmt[/url], [link=http://ryefuwskdkbq.com/]ryefuwskdkbq[/link], http://cnhoeuihcjhf.com/ | nobody | anonymous | tBNuDvuYvrMV | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8305 | 2008-08-14 04:54:42 | 2008-08-14 04:55:48 | 2022-03-06 03:41:53.994640 | Unreviewed | closed | Uncategorized | dev | invalid | XuXBZJFrj | 2Mdu0u <a href="http://rshsbbnnfgzq.com/">rshsbbnnfgzq</a>, [url=http://qjvskwacavmt.com/]qjvskwacavmt[/url], [link=http://ryefuwskdkbq.com/]ryefuwskdkbq[/link], http://cnhoeuihcjhf.com/ | nobody | anonymous | tBNuDvuYvrMV | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8306 | 2008-08-14 05:43:30 | 2009-02-25 19:51:44 | 2022-03-06 03:41:54.128376 | Accepted | closed | contrib.admin | dev | fixed | BaseModelAdmin.formfield_for_dbfield() in desperate need of refactor | See attached patch, which moves all of the model-field-specific overrides out into a dictionary. This has the side effect of increasing customizability :) | nobody | ubernostrum | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8308 | 2008-08-14 07:32:58 | 2011-09-28 16:12:17 | 2022-03-06 03:41:54.460301 | Accepted | closed | Translations | dev | fixed | New Danish translation | Hi, here's a fresh Django translation for Danish. | nobody | finngruwier | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8311 | 2008-08-14 15:04:46 | 2011-09-28 16:12:17 | 2022-03-06 03:41:54.932361 | Accepted | closed | contrib.sessions | dev | fixed | Changeset 8342 makes test suite hang if memcached is not running | Up to changeset [8341] my project works okay. After upgrading to [8342], `manage.py test` hangs at 100% CPU, with the following Traceback after Ctrl+C: {{{ ............^CTraceback (most recent call last): ... (beginning of doctest stack trace omitted) ... File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 428, in __call__ return self.run(*args, **kwds) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 424, in run test(result) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 281, in __call__ return self.run(*args, **kwds) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/test/_doctest.py", line 2174, in runTest failures, tries = runner.run( File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/test/_doctest.py", line 1403, in run return self.__run(test, compileflags, out) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/test/_doctest.py", line 1267, in __run compileflags, 1) in test.globs File "<doctest django.contrib.sessions.tests[56]>", line 1, in ? File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/contrib/sessions/backends/base.py", line 233, in flush self.create() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/contrib/sessions/backends/cache.py", line 20, in create self.session_key = self._get_new_session_key() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/contrib/sessions/backends/base.py", line 137, in _get_new_session_key session_key = md5_construc… | nobody | jcrocholl | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8313 | 2008-08-14 15:19:13 | 2011-09-28 16:12:16 | 2022-03-06 03:41:55.238145 | Accepted | closed | Database layer (models, ORM) | dev | worksforme | rev 8340 crashes python on OS X Leopard | I'm using OS X Leopard (10.5.4) and Postgres 8.3 w/ psycopg2. After updating past revision 8340, psycopg2 causes my Python 2.5 to crash consistently. I tried flushing the database and loading my fixtures from scratch. It crashed no matter what I tried. I noticed there were several fixes related to sessions. I suspect the fact that I was still logged in had something to do with why _psycopg2.so was crashing python. I backed the changes out to 8339 and I was able to work again and I was prompted to log in. | nobody | jon.brisbin@gmail.com | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8314 | 2008-08-14 15:45:41 | 2011-09-28 16:12:16 | 2022-03-06 03:41:55.383519 | Accepted | closed | contrib.sessions | dev | fixed | rev 8340 breaks sessions while rev 8339 works | {{{ [Thu Aug 14 11:37:26 2008] [error] [client XXX] mod_wsgi (pid=22633): Exception occurred processing WSGI script '/var/www/html/XXX/XXX-trunk/XXX.XXX.com.wsgi.py'. [Thu Aug 14 11:37:26 2008] [error] [client XXX] Traceback (most recent call last): [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/core/handlers/wsgi.py", line 216, in __call__ [Thu Aug 14 11:37:26 2008] [error] [client XXX] response = self.get_response(request) [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/core/handlers/base.py", line 67, in get_response [Thu Aug 14 11:37:26 2008] [error] [client XXX] response = middleware_method(request) [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/XXX-trunk/XXX/site/middleware.py", line 81, in process_request [Thu Aug 14 11:37:26 2008] [error] [client XXX] request.session['foo'] = "bar" [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/contrib/sessions/backends/base.py", line 49, in __setitem__ [Thu Aug 14 11:37:26 2008] [error] [client XXX] self._session[key] = value [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/contrib/sessions/backends/base.py", line 161, in _get_session [Thu Aug 14 11:37:26 2008] [error] [client XXX] self._session_cache = self.load() [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/contrib/sessions/backends/db.py", line 19, in load [Thu Aug 14 11:37:26 2008] [error] [client XXX] self.create() [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/contrib/sessions/backends/db.py", line 35, in create [Thu Aug 14 11:37:26 2008] [error] [client XXX] self.save(must_create=True) [Thu Aug 14 11:37:26 2008] [error] [client XXX] File "/var/www/html/XXX/django-trunk/django/contrib/sessions/backends/db.py", line 52, in save [Thu Aug 14 11:37:26 2008] [error] [cli… | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8319 | 2008-08-14 17:53:54 | 2009-02-25 20:06:10 | 2022-03-06 03:41:56.355261 | Unreviewed | closed | contrib.admin | dev | wontfix | limit_choices_to does not limit choices on inlined fields with intermediate tables | Limiting the choices for a tabular inlined member with an intermediate class does not limit the choices. In the example below, the select elements in the admin interface include every story, not just stories which have a start date in the past. For inlined tables where there are thousands of records this can bloat admin page sizes beyond usability. In models.py: {{{ class PageContent(models.Model): stories = models.ManyToManyField('Story', limit_choices_to={'start_date__lte': datetime.now()}, through='PageContentStoryMembership') class PageContentStoryMembership(models.Model): page_content = models.ForeignKey(PageContent) story = models.ForeignKey('Story') weight = models.IntegerField(null=False, default=0) }}} In admin.py: {{{ class PageContentStoryMembershipInline(admin.TabularInline): model = PageContentStoryMembership class PageContentAdmin(admin.ModelAdmin): inlines = [PageContentStoryMembershipInline] }}} | nobody | TrevorFSmith | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8321 | 2008-08-14 18:44:04 | 2009-02-25 19:51:44 | 2022-03-06 03:41:56.673433 | Accepted | closed | contrib.auth | dev | fixed | Use Hashcompat in contrib.auth.user | nothing fancy, just simply use the new django.utils.hashcompat for the hashing in auth.user | nobody | magneto | hashcompat | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8322 | 2008-08-14 19:06:28 | 2008-08-14 20:34:47 | 2022-03-06 03:41:56.839239 | Unreviewed | closed | contrib.admin | invalid | Admin fails to add a slash between MEDIA_URL and upload_to | With MEDIA_URL="/media" and upload_to="somefolder" the admin, while uploading files properly, shows the link to the newly uploaded file as “/mediasomefolder/filename” without the slash. Expected: to add a slash. For consistency, the trailing slash should never be required on paths. | nobody | to.roma.from.djbug@qwertty.com | 0 | 0 | 0 | 0 | 0 | 0 | ||||
| 8323 | 2008-08-14 19:31:07 | 2011-01-18 23:20:32 | 2022-03-06 03:41:56.985519 | Design decision needed | closed | contrib.localflavor | dev | duplicate | British local flavor package named inconsistently | I just noticed that according to the [http://www.djangoproject.com/documentation/localflavor/ local flavor documentation], the packages are named using the [http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm ISO 3166 country codes]. However, at present, the British local flavor is within a package called "uk" (United Kingdom) rather than "gb" (Great Britain), which would seem to be the correct 2 letter code. This is a pretty minor issue as no other country has been assigned "uk" as a country code at this time. For consistency, we may want to rename the package to "gb". If so, this should probably be done prior to 1.0 to avoid compatibility issues in the future. If it is decided that the name should be left as is, then I think the documentation should at least be updated to mention this legacy naming anomaly. All the other local flavors appear to be using the correct ISO codes. | nobody | frasern | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8325 | 2008-08-14 20:45:36 | 2010-11-07 01:00:06 | 2022-03-06 03:41:57.291444 | Accepted | closed | Documentation | dev | fixed | User Authentication Tutorial has incorrect redirect_field_name value | http://www.djangoproject.com/documentation/authentication/ It would be nice to update the text "redirect_field_name='redirect_to'" to "redirect_field_name='next'" in describing the login_required decorator. Using 'redirect_to' instead of 'next' causes the login user to be redirected to accounts/profile, which is confusing to a newbie like me. Thanks! Robert | nobody | Robert Reeves <robert@phurnace.com> | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8327 | 2008-08-14 22:15:19 | 2008-08-14 22:36:51 | 2022-03-06 03:41:57.594944 | Unreviewed | closed | contrib.admin | dev | invalid | link to change password form on 'change user' page in admin interface is broken | Go into the admin interface, open a user, and try to change its password. {{{ Environment: Request Method: GET Request URL: http://localhost:8000/bradmin/auth/user/9/password/ Django Version: 1.0-alpha_2-SVN-8351 Python Version: 2.5.2 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.humanize', 'visitdb', 'photologue'] Installed Middleware: ('visitdb.middleware.RequestAttributeSetup', 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'visitdb.middleware.StandardViewKwargsMiddleware') Traceback: File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/core/handlers/base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/contrib/admin/sites.py" in root 172. return self.model_page(request, *url.split('/', 2)) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/contrib/admin/sites.py" in model_page 189. return admin_obj(request, rest_of_url) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/contrib/admin/options.py" in __call__ 275. return self.change_view(request, unquote(url)) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/db/transaction.py" in _commit_on_success 238. res = func(*args, **kw) File "/home/tobias/caktus/eclipse-workspace/blueridge_visit_database/django/contrib/admin/options.py" in change_view 616. ob… | nobody | tobias | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8312 | 2008-08-14 15:08:50 | 2011-09-28 16:12:17 | 2022-03-06 03:41:55.091077 | Accepted | closed | Translations | dev | fixed | Wrong capitalization in Italian translation | The Italian translation uses capitalized words for names of languages, months and weekdays. The standard is for all these names to be lower case. Check other systems for comparison (e.g. /usr/lib/locale on Unix). | tekNico | steadicat | 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
);