{"id": 8443, "created": "2008-08-20 09:43:06", "changetime": "2008-08-20 17:47:16", "last_pulled_from_trac": "2022-03-06 03:42:17.219816", "stage": "Unreviewed", "status": "closed", "component": "*.djangoproject.com", "type": null, "severity": null, "version": "0.96", "resolution": "wontfix", "summary": "Dead Link - v0.96", "description": "From the page http://www.djangoproject.com/documentation/0.96/url_dispatch/, there's a link to syndication at http://www.djangoproject.com/documentation/0.96/syndication/, which returns a 404.", "owner": "nobody", "reporter": "awatkins", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8458, "created": "2008-08-20 22:20:44", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.804987", "stage": "Accepted", "status": "closed", "component": "Core (Management commands)", "type": null, "severity": null, "version": "dev", "resolution": "worksforme", "summary": "adding own commands to manage.py not working correctly", "description": "I tried to add my own commands as described in http://www.djangoproject.com/documentation/django-admin/ but it did not find my commands.\r\n\r\nI did some research and found a problem.\r\n\r\nlets assume I have \r\n{{{\r\nINSTALLED_APPS = (\r\n 'proj.app'\r\n)\r\n}}}\r\nand call manage.py from the /var/www/proj folder it looks for the \"management\" class in /var/www/proj/proj/app/management\r\n\r\nI added {{{sys.path = ['..']+sys.path}}} to {{{\"django\\core\\management\\__init__.py\"}}} as a local fix and it worked after that.", "owner": "nobody", "reporter": "dafire", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8461, "created": "2008-08-20 23:14:11", "changetime": "2008-08-20 23:27:22", "last_pulled_from_trac": "2022-03-06 03:42:20.249001", "stage": "Someday/Maybe", "status": "closed", "component": "Core (Management commands)", "type": null, "severity": null, "version": "dev", "resolution": "wontfix", "summary": "manage.py reset crashes running initial SQL if there's a #comment on the same line as valid SQL", "description": "manage.py reset can run initial SQL. If this SQL has valid SQL at the start, followed by a # comment, then it will fail with \r\n{{{_mysql_exceptions.ProgrammingError: (2014, \"Commands out of sync; you can't run this command now\")}}}\r\n\r\nIt fails because the regex in sql.py doesn't check for '# comment' when parsing the SQL file. '# comment' is valid in (at least) MySQL.\r\n\r\n", "owner": "nobody", "reporter": "niccl", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8444, "created": "2008-08-20 09:58:45", "changetime": "2008-08-20 13:58:57", "last_pulled_from_trac": "2022-03-06 03:42:17.382796", "stage": "Unreviewed", "status": "closed", "component": "Core (Other)", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "Model inheritance - inherited model could use some fields cleanup", "description": "This is not important, just a little strange (IMHO). I have following scenario:\r\n{{{\r\nclass Question(models.Model):\r\n ...\r\n \r\nclass UserQuestion(Question):\r\n ...\r\n \r\nclass WebQuestion(Question):\r\n ...\r\n>>> q = Question.objects.all()[0]\r\n>>> dir(q)\r\n[... 'userquestion', ..., 'webquestion'] - OK\r\n\r\n}}}\r\n{{{\r\n>>> dir(q.userquestion)\r\n[...'userquestion', ..., 'question_ptr', 'question_ptr_id', ..., 'webquestion'] \r\n}}}\r\nTwo issues:\r\n - Why to have userquestion again?\r\n - this looks odd:\r\n {{{\r\n >>> q.userquestion.userquestion\r\n }}}\r\n - Is it possible to have model instance which has multiple inheritance (one question is userquestion and webquestion in the same time)?\r\n - if not why to have webquestion?\r\n\r\n", "owner": "nobody", "reporter": "trebor74hr", "keywords": "model inheritance", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8447, "created": "2008-08-20 14:19:05", "changetime": "2011-09-28 16:12:21", "last_pulled_from_trac": "2022-03-06 03:42:17.914089", "stage": "Ready for checkin", "status": "closed", "component": "Core (Other)", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "with change in behavior to MultiValueDict.iteritems, there should be a MultiValueDict.iterlists", "description": "Changeset [8399] changed the value of MultiValueDict's iteritems to return singular items instead of lists (closing #7331) and some people may depend on the ability to iterate over the lists.\r\n\r\nThere is already a lists() method that is the analog of items(), it seems reasonable that there should be an equivalent iterlists() method that simply does what iteritems() used to do. \r\n\r\n\r\nrelated django-developers discussion: http://groups.google.com/group/django-developers/browse_thread/thread/cb99e60e7ed86386", "owner": "jamesturk", "reporter": "jamesturk", "keywords": "multivaluedict", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8437, "created": "2008-08-20 05:36:43", "changetime": "2012-01-07 20:37:39", "last_pulled_from_trac": "2022-03-06 03:42:16.176245", "stage": "Design decision needed", "status": "closed", "component": "Database layer (models, ORM)", "type": "New feature", "severity": "Normal", "version": "dev", "resolution": "wontfix", "summary": "Feature Request: distinct_between('team_home', 'team_away') similar to unique_together", "description": "{{{\r\nclass Game(models.Model):\r\n team_home = models.ForeignKey(Team, related_name=\"games_home\")\r\n team_away = models.ForeignKey(Team, related_name=\"games_away\")\r\n\r\n class Meta:\r\n distinct_between = ('team_home', 'team_away')\r\n}}}\r\n\r\n\r\n\"distinct_between\" should add this constraint to the database:\r\n\r\n{{{ CHECK(team_home IS DISTINCT FROM team_away) }}}\r\n", "owner": "nobody", "reporter": "ritlim", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8439, "created": "2008-08-20 05:58:53", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:16.536345", "stage": "Accepted", "status": "closed", "component": "Database layer (models, ORM)", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Q objects still incorrectly choosing inner join over outer join", "description": "I am basically reopening #3592 with an example that is broken in the latest SVN. I am using SVN r8445.\r\n\r\n\r\n\r\nHere are my test models:\r\n\r\n{{{\r\nclass Enemy(models.Model):\r\n pass\r\n\r\nclass Troop(models.Model):\r\n pass\r\n\r\nclass Soldier(models.Model):\r\n troop = models.ForeignKey(Troop)\r\n\r\nclass TroopKill(models.Model):\r\n enemy = models.ForeignKey(Enemy)\r\n troop = models.ForeignKey(Troop)\r\n\r\nclass SoldierKill(models.Model):\r\n enemy = models.ForeignKey(Enemy)\r\n soldier = models.ForeignKey(Soldier)\r\n grenade = models.BooleanField()\r\n}}}\r\n\r\nI want to find all enemies that were killed either by my soldier, or by the troop my soldier is in. So I execute the following query:\r\n\r\n{{{\r\ndirect_kills = Q(soldierkill__soldier__pk=1)\r\ntroop_kills = Q(troopkill__troop__soldier__pk=1)\r\nall_kills = direct_kills | troop_kills\r\nprint Enemy.objects.filter(all_kills).all()\r\n}}}\r\n\r\nAnd I get the correct SQL:\r\n\r\n{{{\r\nSELECT \"enemy\".\"id\" FROM \"enemy\"\r\nLEFT OUTER JOIN \"soldierkill\" ON (\"enemy\".\"id\" = \"soldierkill\".\"enemy_id\")\r\nLEFT OUTER JOIN \"troopkill\" ON (\"enemy\".\"id\" = \"troopkill\".\"enemy_id\")\r\nLEFT OUTER JOIN \"troop\" ON (\"troopkill\".\"troop_id\" = \"troop\".\"id\")\r\nLEFT OUTER JOIN \"soldier\" T6 ON (\"troop\".\"id\" = T6.\"troop_id\")\r\nWHERE (\"soldierkill\".\"soldier_id\" = 1 OR T6.\"id\" = 1 )\r\n}}}\r\n\r\nBut when I try to add just one more condition (the direct kill had to have grenade=True):\r\n\r\n{{{\r\ndirect_kills = Q(soldierkill__soldier__pk=1,soldierkill__grenade=True)\r\ntroop_kills = Q(troopkill__troop__soldier__pk=1)\r\nall_kills = direct_kills | troop_kills\r\nprint Enemy.objects.filter(all_kills).all()\r\n}}}\r\n\r\nIt switches incorrectly to inner joins.\r\n\r\n{{{\r\nSELECT \"enemy\".\"id\" FROM \"enemy\"\r\nINNER JOIN \"soldierkill\" ON (\"enemy\".\"id\" = \"soldierkill\".\"enemy_id\")\r\nINNER JOIN \"troopkill\" ON (\"enemy\".\"id\" = \"troopkill\".\"enemy_id\")\r\nINNER JOIN \"troop\" ON (\"troopkill\".\"troop_id\" = \"troop\".\"id\")\r\nINNER JOIN \"soldier\" T6 ON (\"troop\".\"id\" = T6.\"troop_id\")\r\nWHERE ((\"soldierkill\".\"grenade\" = true AND \"soldierkill\".\"soldier_id\" = 1 ) OR T6.\"id\" = 1 )\r\n}}}\r\n\r\nAm I doing something wrong, or is this broken?\r\n\r\nThanks,\r\nMike", "owner": "mtredinnick", "reporter": "mikemintz", "keywords": "1.0-blocker", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8459, "created": "2008-08-20 22:34:19", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.951549", "stage": "Design decision needed", "status": "closed", "component": "Database layer (models, ORM)", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "get_or_create does not pay attention to the instance calling it", "description": "get_or_create can be confusing to use because it doesn't pay attention to the object that is actually calling it. For example when calling \n{{{forumpost.participant_set.get_or_create(user=person)}}}\n\nit would make sense that get_or_create is referencing participant_set that is calling it and therefore would create a new entry to that result set if it doesn't exist. However, this is not the case. get_or_create merely uses participant_set to determine the type of object it is dealing with.", "owner": "nobody", "reporter": "mymmaster", "keywords": "get_or_create aug22sprint", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8435, "created": "2008-08-20 01:45:18", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:15.830881", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "1.0-alpha-2", "resolution": "fixed", "summary": "Document formset's `prefix` argument.", "description": "''See Brian's comment; this is a doc issue. Original report follows -- JKM''\r\n\r\nAs of this moment one is able to utilize multiple formsets within a single view, as long as one does not use the same variable name for the fields in the respective forms. But this breaks down on the template level, specifically the management_form portion of formsets. The variables form-TOTAL_FORMS and form-INITIAL_FORMS are shared for all formsets when you include each formset's management_form in the template: {{ formset.management_form }}.\r\n\r\nThe problem isn't immediately apparent since the template will render correctly due to the fact that you call the management_form for each formset, thus in turn over-writing the variables form-TOTAL_FORMS and form-INITIAL_FORMS each time you do. The trouble begins when you start processing the request.POST data.\r\n\r\nLet's say you have 2 formsets displayed in a template, the first one you configure with 4 fields and the second with 2 fields. When you then process the POST data in the view by calling \"for form in formset1.forms\" it will only iterate 2 times oppose to the 4 times one would initially expect, all due to the fact that formset2's management_form has now over-written the form-TOTAL_FORMS variable; thus you lose whatever data was submitted in the remaining 2 fields in formset1.", "owner": "nobody", "reporter": "takkun", "keywords": "formsets", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8438, "created": "2008-08-20 05:45:44", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:16.368923", "stage": "Accepted", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "porting guide - 0.96 to 1.0", "description": "The porting guide needs to basically cover everything in\r\nBackwardsIncompatibleChanges, with before/after code samples for each\r\nitem and detailed upgrade info. The idea should be that someone can\r\nstart with an 0.96 site and read through the checklist in order,\r\nmaking changes, and finish with a 1.0 site.", "owner": "anonymous", "reporter": "daonb ", "keywords": "porting", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8460, "created": "2008-08-20 22:54:34", "changetime": "2008-08-23 01:10:47", "last_pulled_from_trac": "2022-03-06 03:42:20.105774", "stage": "Unreviewed", "status": "closed", "component": "Documentation", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "Broken image links in Tutorial part 2.", "description": "Some of images linked in tutorial part 2 didn't exist on the server:\r\n\r\nfile [http://code.djangoproject.com/browser/django/trunk/docs/tutorial02.txt tutorial02.txt]\r\n\r\nline 75 \t{{{ .. image:: http://media.djangoproject.com/img/doc/tutorial-trunk/admin01.png}}} [[BR]]\r\nline 86 \t{{{ :target: http://media.djangoproject.com/img/doc/tutorial-trunk/admin02.png}}} [[BR]]\r\nline 118 \t{{{ :target: http://media.djangoproject.com/img/doc/tutorial-trunk/admin03.png}}} [[BR]]\r\nline 126 and 312{{{ :target: http://media.djangoproject.com/img/doc/tutorial-trunk/admin04.png}}} [[BR]]\r\n\r\n\r\nI attach images that can be usefull.", "owner": "nobody", "reporter": "prmtl", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8454, "created": "2008-08-20 19:08:11", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.148943", "stage": "Accepted", "status": "closed", "component": "File uploads/storage", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "uploaded file permissions vary based on handler", "description": "As mentioned a few times in #2070, uploaded files large enough to be streamed to a temporary file get created with a mode of 0600, as per python's [http://docs.python.org/lib/module-tempfile.html tempfile.mkstemp]. This causes two problems:\r\n\r\n 1. Files uploaded into memory and saved to disk respect the umask, so uploads could have different permissions based on how big they are.\r\n 2. If the webserver user and django user do not match (such as when running an external FastCGI process), the webserver can no longer serve uploaded files.\r\n\r\nAttached is a patch that implements a `FILE_UPLOAD_PERMISSIONS` setting. Right now, it defaults to the current behavior (leaving the permissions alone).\r\n\r\nDiscussion (or lack thereof) here:\r\n\r\nhttp://groups.google.com/group/django-developers/browse_frm/thread/e7d7ca62b9f6d331\r\n\r\nThe inconsistency seems like a bug to me, so marking as 1.0.", "owner": "nobody", "reporter": "dcwatson", "keywords": "file upload permission mode", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8455, "created": "2008-08-20 19:34:26", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.319810", "stage": "Accepted", "status": "closed", "component": "File uploads/storage", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Lack of filesystem permissions to save uploaded file results in server hang", "description": "If the web server user does not have filesystem permissions to write to the \"upload_to\" directory of a FileField or ImageField, attempting to upload a file results in the server process hanging and eating 100% CPU. \r\n\r\nInstead, there should be a 500 error or debug page with a sensible error message.\r\n\r\nThis issue seems to exist ever since file-storage-refactor. I can replicate it on both the Django development server and Apache 2.2 on Debian Linux.\r\n\r\nI believe the problem is that django.core.file.storage.FileSystemStorage._save() makes unwarranted assumptions about the reason for an OSError, causing an infinite loop, as outlined by rajeshdhawan in [http://code.djangoproject.com/ticket/8203#comment:7 this comment] on #8203.", "owner": "nobody", "reporter": "carljm", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8436, "created": "2008-08-20 02:42:18", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:16.008553", "stage": "Accepted", "status": "closed", "component": "Forms", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "Silent crash in forms rendering", "description": "Given form as follows, as_table crashes\r\n\r\nI expect this has to do with collisions to properties of Form and variations of problems will probably happen with (errors, changed_data, media)\r\n{{{\r\n#!python\r\nclass TestForm(forms.ModelForm):\r\n errors = forms.CharField(widget=forms.HiddenInput)\r\n class Meta:\r\n model = MyModel\r\n}}}\r\nStack trace\r\n{{{\r\nc:\\django\\django\\forms\\forms.py in as_table(self)\r\n 175 def as_table(self):\r\n 176 \"Returns this form rendered as HTML s -- excluding the
.\"\r\n--> 177 return self._html_output(u'%(label)s%(errors)s%(field)s%(help_text)s', u'%s', '', u'
%s', False)\r\n 178\r\n 179 def as_ul(self):\r\n\r\nc:\\django\\django\\forms\\forms.py in _html_output(self, normal_row, error_row, row_ender, help_text_html, errors_on_separate_row)\r\n 131 def _html_output(self, normal_row, error_row, row_ender, help_text_html, errors_on_separate_row):\r\n 132 \"Helper function for outputting HTML. Used by as_table(), as_ul(), as_p().\"\r\n--> 133 top_errors = self.non_field_errors() # Errors that should be displayed above all fields.\r\n 134 output, hidden_fields = [], []\r\n 135 for name, field in self.fields.items():\r\n\r\nc:\\django\\django\\forms\\forms.py in non_field_errors(self)\r\n 191 are none.\r\n 192 \"\"\"\r\n--> 193 return self.errors.get(NON_FIELD_ERRORS, self.error_class())\r\n 194\r\n 195 def full_clean(self):\r\n\r\nAttributeError: 'CharField' object has no attribute 'get'\r\n}}}", "owner": "nobody", "reporter": "stilldodge", "keywords": "errors, Form", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8440, "created": "2008-08-20 07:19:26", "changetime": "2009-02-25 19:51:44", "last_pulled_from_trac": "2022-03-06 03:42:16.714183", "stage": "Unreviewed", "status": "closed", "component": "Forms", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "Change forms default auto_id='id-%s'", "description": "Hey all,\r\n\r\nI don't think that the default auto_id for form fields is compatible with CSS1, since it starts with \"id_\". A la http://www.w3.org/TR/REC-CSS1#appendix-b:\r\n\r\n{{{\r\nunicode\t\t\\\\[0-9a-f]{1,4}\r\nlatin1\t\t[\u00a1-\u00ff]\r\nescape\t\t{unicode}|\\\\[ -~\u00a1-\u00ff]\r\nstringchar\t{escape}|{latin1}|[ !#$%&(-~]\r\nnmstrt\t\t[a-z]|{latin1}|{escape}\r\nnmchar\t\t[-a-z0-9]|{latin1}|{escape}\r\nident\t\t{nmstrt}{nmchar}*\r\nname\t\t{nmchar}+\r\n}}}\r\n\r\nI believe it's a real simple patch (attached), but I haven't tested it rigorously.\r\n\r\nCheers,\r\n\r\nChris", "owner": "cdleary", "reporter": "cdleary@gmail.com", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8434, "created": "2008-08-20 00:45:41", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:15.670375", "stage": "Ready for checkin", "status": "closed", "component": "Internationalization", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "[8443] broke tests", "description": "Tested on r8445, Debian Etch, Python 2.4.4\r\n\r\n{{{\r\n======================================================================\r\nFAIL: Doctest: regressiontests.forms.tests.__test__.localflavor_nl_tests\r\n----------------------------------------------------------------------\r\nTraceback (most recent call last):\r\n File \"/usr/lib/python2.4/site-packages/django/test/_doctest.py\", line 2180, in runTest\r\n raise self.failureException(self.format_failure(new.getvalue()))\r\nAssertionError: Failed doctest test for regressiontests.forms.tests.__test__.localflavor_nl_tests\r\n File \"/srv/lib/django-trunk/tests/regressiontests/forms/tests.py\", line unknown line number, in localflavor_nl_tests\r\n\r\n----------------------------------------------------------------------\r\nFile \"/srv/lib/django-trunk/tests/regressiontests/forms/tests.py\", line ?, in regressiontests.forms.tests.__test__.localflavor_nl_tests\r\nFailed example:\r\n s.render('provinces', 'OV')\r\nExpected:\r\n u''\r\nGot:\r\n u''\r\n\r\n\r\n----------------------------------------------------------------------\r\nRan 444 tests in 291.684s\r\n\r\nFAILED (failures=1)\r\n}}}", "owner": "jarrow", "reporter": "jarrow", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8453, "created": "2008-08-20 17:13:10", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:18.988880", "stage": "Accepted", "status": "closed", "component": "Template system", "type": null, "severity": null, "version": "1.0-beta", "resolution": "duplicate", "summary": "Error in filter \"timesince\"", "description": "{{{\r\n#!python\r\ndef timesince(value, arg=None):\r\n \"\"\"Formats a date as the time since that date (i.e. \"4 days, 6 hours\").\"\"\"\r\n from django.utils.timesince import timesince\r\n if not value:\r\n return u''\r\n if arg:\r\n return timesince(arg, value) \r\n return timesince(value)\r\ntimesince.is_safe = False\r\n}}}\r\nIt should be \"return timesince(value, arg)\"", "owner": "jheasly", "reporter": "carlou", "keywords": "timesince", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 1, "needs_docs": 0, "ui_ux": 0} {"id": 8445, "created": "2008-08-20 11:00:53", "changetime": "2008-08-22 17:36:20", "last_pulled_from_trac": "2022-03-06 03:42:17.533052", "stage": "Ready for checkin", "status": "closed", "component": "Translations", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "czech translation update", "description": "This patch translates all new strings. Everything except django.contrib.humanize and django.contrib.localflavor should be translated.\r\n\r\nI also realize than I am three times between authors. This patch removes two of these three occurrences.", "owner": "mtredinnick", "reporter": "Petr Marhoun ", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8446, "created": "2008-08-20 13:49:26", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:17.707900", "stage": "Ready for checkin", "status": "closed", "component": "Translations", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Swapped French translations for 'AM' and 'PM'", "description": null, "owner": "nobody", "reporter": "steadicat", "keywords": "fr", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8456, "created": "2008-08-20 19:49:47", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.475061", "stage": "Unreviewed", "status": "closed", "component": "Translations", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "Update of Georgian translation (ka)", "description": "Some missing phrases translated and Localflavour \r\ntransliterated to Georgian", "owner": "nobody", "reporter": "avsd", "keywords": "ka georgian", "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8441, "created": "2008-08-20 09:19:54", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:16.872568", "stage": "Unreviewed", "status": "closed", "component": "Uncategorized", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "WCXGCbXP", "description": "\nwVZOrl cllbtjfdryii, [url=http://urmmpnhrgeii.com/]urmmpnhrgeii[/url], [link=http://shwkzlsmziby.com/]shwkzlsmziby[/link], http://nessrxgnjqjy.com/", "owner": "nobody", "reporter": "anonymous", "keywords": "spam", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8442, "created": "2008-08-20 09:19:57", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:17.056387", "stage": "Unreviewed", "status": "closed", "component": "Uncategorized", "type": null, "severity": null, "version": "dev", "resolution": "invalid", "summary": "WCXGCbXP", "description": "\nwVZOrl cllbtjfdryii, [url=http://urmmpnhrgeii.com/]urmmpnhrgeii[/url], [link=http://shwkzlsmziby.com/]shwkzlsmziby[/link], http://nessrxgnjqjy.com/", "owner": "nobody", "reporter": "anonymous", "keywords": "spam", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8457, "created": "2008-08-20 20:25:49", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:19.640586", "stage": "Unreviewed", "status": "closed", "component": "Uncategorized", "type": null, "severity": null, "version": "dev", "resolution": "fixed", "summary": "typo in sessions file backend can cause NameError", "description": "In django/contrib/sessions/backends/file.py, SessionStore.save() refers to \"errno.EEXIST\" when it means \"os.errno.EEXIST\". If using the file session backend and set SESSION_FILE_PATH to an unwritable directory (or if there is any other error condition on creating a new session file), this causes a NameError to be raised instead of the correct OSError. It also prevents the correct handling of the (rare) case of a duplicate session ID being generated. Attached patch fixes the typo.", "owner": "nobody", "reporter": "carljm", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8448, "created": "2008-08-20 14:22:25", "changetime": "2012-01-09 11:21:56", "last_pulled_from_trac": "2022-03-06 03:42:18.128844", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": "Uncategorized", "severity": "Normal", "version": "dev", "resolution": "duplicate", "summary": "Collapse Tabular Inline", "description": "Currently, to use the colapse feature in Tabular Inline, I customize the template tabular.html, but it would not be possible to add a parameter in the admin.TabularInline class to do this thing?", "owner": "nobody", "reporter": "mdpetry", "keywords": "inline", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8449, "created": "2008-08-20 15:39:48", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:18.324596", "stage": "Accepted", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "SlugField validator not working in new admin", "description": "The new admin app is allowing invalid characters in SlugFields. I tested with this model:\r\n{{{\r\n# models.py\r\nfrom django.db import models\r\n\r\nclass SlugModel(models.Model):\r\n slug = models.SlugField()\r\n}}}\r\n{{{ \r\n# admin.py \r\nfrom django.contrib import admin\r\nfrom models import SlugModel\r\n\r\nclass SlugModelAdmin(admin.ModelAdmin):\r\n pass\r\n\r\nadmin.site.register(SlugModel, SlugModelAdmin)\r\n}}}\r\n\r\nIn the admin, I tested the following:\r\n 1. hello world\r\n 2. slug%fest\r\n 3. pirate&bay\r\n \r\nEach one is saved successfully. A validation error does not appear.\r\n\r\nTested in SVN 8441.", "owner": "nobody", "reporter": "lingrlongr", "keywords": "slug", "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8450, "created": "2008-08-20 15:51:47", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:18.503808", "stage": "Unreviewed", "status": "closed", "component": "contrib.admin", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "Admin interface fills the harddrive on uploading files of roughly 2.5MBs in size", "description": "When using admin interface on a model that has FileField and trying to upload files of roughly 2.5MBs django gets into a loop (I've checked on Windows XP SP2 only for now), saving the file over and over again (adding underscore on every iteration), never stopping. I haven't been able to determine the exact file size though, but 2.5MBs seems to work in all cases. Unfortunately I don't know django well enough to determine if this problem exists outside of admin interface. I can't find where exactly it is looping like that either (if you can hint me of some way it would be greatly appreciated). :(\r\n\r\nI'm attaching a sample project that reproduces the problem. Inside you will find a bigfile.py that when executed creates a zero-filled bigfile.dat file. Run manage.py syncdb and manage.py runserver then navigate to http://localhost:8000/admin/main/myfile/add/ and try attaching bigfile.dat. On my machine it starts filling myfile subdirectory with multitudes of bigfile.dat copies. All of the files saved there are identical to bigfile.dat, so it must be saving it correctly, but then it aborts and tries saving it again. If the file is, for example, 1KB smaller then everything goes fine.\r\n\r\nI'm testing using trunk revision 8448.", "owner": "nobody", "reporter": "snaury", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8451, "created": "2008-08-20 15:52:48", "changetime": "2011-09-28 16:12:17", "last_pulled_from_trac": "2022-03-06 03:42:18.666168", "stage": "Unreviewed", "status": "closed", "component": "contrib.auth", "type": null, "severity": null, "version": "dev", "resolution": "duplicate", "summary": "Fix URL in e-mails sent out by password reset", "description": "The authentication framework as a built in view (django.contrib.auth.views.password_reset) and form (django.contrib.auth.forms.PasswordResetForm) which send a user an e-mail inviting them to reset their password.\r\n\r\nThe e-mail assumes that the view 'django.contrib.auth.views.password_reset_confirm' will be at \"{{ protocol }}://{{ domain }}/reset/{{ uid }}-{{ token }}/\", whereas in fact it might be anywhere.\r\n\r\nThis patch calls reverse() to generate the correct URL for the e-mail.", "owner": "nobody", "reporter": "Richard Davies ", "keywords": null, "easy": 0, "has_patch": 1, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0} {"id": 8452, "created": "2008-08-20 15:56:21", "changetime": "2008-08-20 16:36:42", "last_pulled_from_trac": "2022-03-06 03:42:18.826219", "stage": "Unreviewed", "status": "closed", "component": "contrib.sessions", "type": null, "severity": null, "version": "1.0-alpha-2", "resolution": "invalid", "summary": "expire time in session being updated frequently", "description": "We noticed that one of our user's session info in django_session has it's expire date moved into the future periodically. We are not calling set_expiry() on the session. My understanding was that the expire date was a constant for a given session key -- it is set when the session is created and never changes unless set_expiry() is called.\r\n\r\nWhile reading through the Django Sessions docs, though, I noticed this bit:\r\n\r\n{{{\r\nTo change this default behavior, set the SESSION_SAVE_EVERY_REQUEST setting to True. If SESSION_SAVE_EVERY_REQUEST is True, Django will save the session to the database on every single request.\r\n\r\nNote that the session cookie is only sent when a session has been created or modified. If SESSION_SAVE_EVERY_REQUEST is True, the session cookie will be sent on every request.\r\n\r\nSimilarly, the expires part of a session cookie is updated each time the session cookie is sent.\r\n}}}\r\n\r\nDoes this mean that the cookie is sent whenever the session data changes and that this triggers the expiration date to move forward? If so, why is that? It seems that's the wrong behavior since I would think the expiration of someone's remembered login etc would have nothing to do with when the session data was last updated.\r\n", "owner": "nobody", "reporter": "TP", "keywords": null, "easy": 0, "has_patch": 0, "needs_better_patch": 0, "needs_tests": 0, "needs_docs": 0, "ui_ux": 0}