tickets
26 rows where "created" is on date 2008-09-10 sorted by changetime
This data as json, CSV (advanced)
Suggested facets: version, resolution, owner, reporter, has_patch, needs_better_patch, ui_ux
changetime (date) 17 ✖
- 2008-09-10 6
- 2011-09-28 3
- 2008-09-11 2
- 2009-02-25 2
- 2008-09-15 1
- 2008-09-16 1
- 2008-09-17 1
- 2008-11-06 1
- 2009-02-26 1
- 2010-02-17 1
- 2010-12-23 1
- 2011-02-01 1
- 2011-02-17 1
- 2011-11-16 1
- 2011-12-17 1
- 2013-03-19 1
- 2020-06-06 1
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
9001 | 2008-09-10 00:14:21 | 2008-09-10 07:36:38 | 2022-03-06 03:43:44.629100 | Unreviewed | closed | Translations | 0.95 | wontfix | missing translation in 'es' translation | The string: "Please enter a correct username and password. Note that both fields are case-sensitive." is not translated in the spanish .po file, the translation should be "Por favor, ingrese un usuario y clave correctos. Note que ambos campos son sensitivos a mayusculas/minusculas." | nobody | xrm0 | spanish i18n es | 0 | 0 | 0 | 0 | 0 | 0 | ||
9013 | 2008-09-10 14:57:46 | 2008-09-10 14:59:46 | 2022-03-06 03:43:46.702507 | Unreviewed | closed | Uncategorized | 1.0 | duplicate | Filestorage and save=False/commit=False | In FieldFile.save(), the storage.save() is called regardless of the save argument. I need to be able edit the data uploaded to a FileField before the storage backend gets called to save the file, but this isn't possible. As it stands, to make this work, the files get saved with formset.save(commit=False) is called, and then I must manually call the storage.save() to save the updated data to the same on the backend. There is some discussion on the django-developers list about this. Follow at http://groups.google.com/group/django-developers/browse_thread/thread/e2057d165c3a0c12 | nobody | shadfc | 0 | 0 | 0 | 0 | 0 | 0 | |||
9010 | 2008-09-10 12:37:53 | 2008-09-10 15:09:53 | 2022-03-06 03:43:46.212064 | Unreviewed | closed | Documentation | 1.0 | fixed | Replace "you'all" with "you'll" in howto/custom-file-storage | The phrase "You'all also usually" should really say "You'll also usually". | nobody | rduffield | 0 | 1 | 0 | 0 | 0 | 0 | |||
9019 | 2008-09-10 19:14:15 | 2008-09-10 19:46:59 | 2022-03-06 03:43:47.695185 | Unreviewed | closed | Uncategorized | invalid | delete this ticket | [spam] | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | ||||
9020 | 2008-09-10 19:14:26 | 2008-09-10 19:48:53 | 2022-03-06 03:43:47.865577 | Unreviewed | closed | Uncategorized | invalid | also delete this ticket | [spam really removed this time] | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | ||||
9021 | 2008-09-10 19:27:28 | 2008-09-10 20:29:40 | 2022-03-06 03:43:48.037968 | Unreviewed | closed | Uncategorized | 1.0 | duplicate | manage.py startapp should create an "default" admin.py file | Please look at this ticket as a polite feature request. I have been using the SVN version for some time, but in all projects I started after the newformsadmin merge, I made the same mistake - I added a admin.site.register(SomeClassName) to the models.py, which cause issues with manage.py shell and so on. I personally appreciate the AlreadyRegistered exception. But as all Django users will use the automatic admin area, it would be a got practice to create a dummy admin.py file with the startapp command. I hope, this is understandable and might lower the learning curve for beginners and people like, whom are upgrading to 1.0. | nobody | oliverandrich | 0 | 0 | 0 | 0 | 0 | 0 | |||
9018 | 2008-09-10 19:12:01 | 2008-09-11 02:59:12 | 2022-03-06 03:43:47.529274 | Unreviewed | closed | Documentation | 1.0 | fixed | Duplicate instance of "of" in intro/tutorial01.txt | The phrase "Subversion checkout of of Django's development" should read "Subversion checkout of Django's development" | nobody | rduffield | 0 | 1 | 0 | 0 | 0 | 0 | |||
9024 | 2008-09-10 19:45:20 | 2008-09-11 02:59:53 | 2022-03-06 03:43:48.540834 | Unreviewed | closed | Documentation | 1.0 | wontfix | Change confusing wording in intro/tutorial02.txt | The phrase "so any modifications code will be seen" should read "so any code modifications will be seen". | nobody | rduffield | 0 | 1 | 0 | 0 | 0 | 0 | |||
9008 | 2008-09-10 06:45:04 | 2008-09-15 17:25:18 | 2022-03-06 03:43:45.834758 | Accepted | closed | GIS | 1.0 | fixed | 'lib_name' is not defined error on Windows when `GDAL_LIBRARY_PATH` is set | {{{ 43 if os.name == 'nt': 44 from ctypes import WinDLL 45 lwingdal = WinDLL(lib_name) 'lib_name' is not defined }}} | jbronn | kitlycol@gmail.com | lib_name GDAL_LIBRARY_PATH gdal gis | 0 | 0 | 0 | 0 | 0 | 0 | ||
9016 | 2008-09-10 17:29:21 | 2008-09-16 06:05:53 | 2022-03-06 03:43:47.199534 | Unreviewed | closed | Core (Other) | dev | fixed | update VERSION in trunk/django/__init__.py (currently trunk is claiming it is 1.0 final) | I have no idea what should be the new trunk VERSION. Currently it is: VERSION = (1, 0, 'final') | nobody | AmanKow | 0 | 0 | 0 | 0 | 0 | 0 | |||
9014 | 2008-09-10 15:55:34 | 2008-09-17 09:02:26 | 2022-03-06 03:43:46.869127 | Accepted | closed | Uncategorized | 1.0 | fixed | django admin MultiPartParserError in google chrome | Following exception gets thrown in google chrome when you either save and continue editing or save and add another for any item in the django admin. tested in Firefox 3 and IE 8 beta and i cannot replicate the error. Maybe its an issue with the way Chrome handles multipart form posts. {{{ Environment: Request Method: GET Request URL: http://.... Django Version: 1.0-final-SVN-unknown Python Version: 2.5.2 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.admindocs', 'django.contrib.flatpages', 'bbs.clients', 'bbs.channels', 'bbs.advertisers'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware') Traceback: File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in root 158. return self.model_page(request, *url.split('/', 2)) File "C:\Python25\lib\site-packages\django\views\decorators\cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in model_page 177. return admin_obj(request, rest_of_url) File "C:\Python25\Lib\site-packages\django\contrib\auth\admin.py" in __call__ 42. return super(UserAdmin, self).__call__(request, url) File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in __call__ 197. return self.change_view(request, unquote(url)) File "C:\Python25\Lib\site-packages\django\db\transaction.py" in _commit_on_success 238. res = func(*ar… | nobody | aliixx | 0 | 0 | 0 | 0 | 0 | 0 | |||
9011 | 2008-09-10 12:38:01 | 2008-11-06 11:27:36 | 2022-03-06 03:43:46.387128 | Unreviewed | closed | Core (Other) | 1.0 | fixed | "File format may be invalid" bug in management.commands.loaddata | If you try to load more than one fixture, one without any object, the output maybe wrong. Eg. account with zero object, and blog with any number of objects. {{{ >>> from django.core import management >>> management.call_command('loaddata', *['account', 'blog'], verbosity=0) No fixture data found for 'blog'. (File format may be invalid.) }}} | nobody | jlrivitti@gmail.com | 0 | 1 | 0 | 0 | 0 | 0 | |||
9003 | 2008-09-10 02:07:24 | 2009-02-25 19:51:44 | 2022-03-06 03:43:44.953298 | Unreviewed | closed | Documentation | dev | fixed | Minor Typo in the "MySQL comparisons" section of the QuerySet API Documentation | There are a few minor typos and awkward language in the "MySQL comparisons" sections of the QuerySet API documentation. Attached is a patch with improved language and fixed typos. | nobody | seanoc | 0 | 1 | 0 | 0 | 0 | 0 | |||
9017 | 2008-09-10 18:16:49 | 2009-02-25 19:51:44 | 2022-03-06 03:43:47.364366 | Unreviewed | closed | Translations | 1.0 | fixed | Translation update for Danish | Attached you'll find an update for the Danish translation of Django 1.0. Danish translation should now be complete. | nobody | finngruwier | 0 | 0 | 0 | 0 | 0 | 0 | |||
9006 | 2008-09-10 04:43:03 | 2009-02-26 02:29:10 | 2022-03-06 03:43:45.461549 | Unreviewed | closed | Core (Other) | 1.0 | wontfix | QuerySet indexing by __getitem__ gets wrong answer in edge cases | I've just spent a few hours in pdb tracking this down. I've got about as far as I'm able into the Django libraries looking for the culprit, but I've run out of ideas due to my limited knowledge of Django's inner workings. I need someone with a bit more experience to look at this one. I have a Membership model which relates Users to Groups. {{{ #!python # models.py class Membership (models.Model): user = models.ForeignKey(User) group = models.ForeignKey(Group) school_year = models.ForeignKey(SchoolYear, related_name='memberships') }}} This query turns up the following results: {{{ >>> Membership.objects.filter(user__username="jammons") [<Membership: Office of Technology Services (Jeff Ammons, 2008 - 2009)>, <Membership: UPS Fencing Club (Jeff Ammons, 2008 - 2009)>, <Membership: Adelphian Concert Choir (Jeff Ammons, 2008 - 2009)>] }}} These results are expected and good. However, indexing does the Wrong Thing. For some reason, {{{__getitem__}}} returns the same model for {{{[0]}}} and {{{[2]}}}: {{{ >>> qs[0] <Membership: Adelphian Concert Choir (Jeff Ammons, 2008 - 2009)> >>> qs[1] <Membership: UPS Fencing Club (Jeff Ammons, 2008 - 2009)> >>> qs[2] <Membership: Adelphian Concert Choir (Jeff Ammons, 2008 - 2009)> >>> }}} The result is that the real {{{qs[0]}}} is unreachable, and furthermore, inline formset validation is therefore broken when this occurs, because the wrong self.instance is set on the first form, causing it to .exclude() the wrong instance from its unique_check and resulting in the form believing that it is a duplicate. Engaging pdb and then entering "continue" (running the query in the debugger without actually inspecting the trace) returns the same answer. {{{ >>> def test(): ... print Membership.objects.filter(user__username="jammons")[0] ... >>> import pdb >>> pdb.runcall(test) > <console>(2)test() (Pdb) continue Adelphian Concert Choir (Jeff Ammons, 2008 - 2009) }}} __HOWEVER__: Running pdb and stepping through the code pro… | mtredinnick | smoluf | queryset index race | 0 | 0 | 0 | 0 | 0 | 0 | ||
9004 | 2008-09-10 04:18:44 | 2010-02-17 18:47:30 | 2022-03-06 03:43:45.124903 | Accepted | closed | Documentation | dev | wontfix | 1.0 porting guide lists non-existant database backend functions | See: http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/#database-backend-functions-have-been-renamed Some of these have been removed (e.g. in r8296). This ticket will need a proper patch, just noting these down here until I have a chance to put one together. I'm not that familiar with the code here, nor have I thoroughly investigated the code for each of these items so anyone feel free to correct me. {{{ ``backend.get_limit_offset_sql`` ``connection.ops.limit_offset_sql`` (removed?) ``backend.get_tablespace_sql`` ``connection.ops.sql_for_tablespace`` ``backend.get_query_set_class`` ``connection.ops.query_class`` ``backend.OPERATOR_MAPPING`` ``connection.operators`` (removed?) ``backend.allows_group_by_ordinal`` ``connection.features.allows_group_by_ordinal`` (removed) ``backend.allows_unique_and_pk`` ``connection.features.allows_unique_and_pk`` (removed) ``backend.autoindexes_primary_keys`` ``connection.features.autoindexes_primary_keys`` (removed) ``backend.needs_upper_for_iops`` ``connection.features.needs_upper_for_iops`` (removed) ``backend.supports_constraints`` ``connection.features.supports_constraints`` (removed) ``backend.supports_tablespaces`` ``connection.features.supports_tablespaces`` (removed) ``backend.uses_case_insensitive_names`` ``connection.features.uses_case_insensitive_names`` (removed) ``backend.uses_custom_queryset`` ``connection.features.uses_custom_query_class`` }}} | nobody | nicklane | 0 | 0 | 0 | 0 | 0 | 0 | |||
9022 | 2008-09-10 19:36:15 | 2010-12-23 02:56:31 | 2022-03-06 03:43:48.207243 | Design decision needed | closed | contrib.localflavor | 1.0 | fixed | Allow US armed forces state codes for USStateField | I'm not a Yank so I don't know how useful this is to you chaps over the pond. The official list of state codes supported by the US Postal Service was linked on thedailywtf.com and I checked to discover Django does not handle all of the codes: http://www.usps.com/ncsc/lookups/abbreviations.html#states Obviously this list runs contrary to #8425 but I thought this deserved a ticket in case you are discriminating against your boys in the Middle East, you UN-AMERICAN, COMMUNIST, CHEESE-EATING... er, wait. I think I'm getting my imported redneck epithets mixed up. | dougvanhorn | Daniel Pope <dan@mauveinternet.co.uk> | 0 | 1 | 0 | 0 | 0 | 0 | |||
9009 | 2008-09-10 08:43:38 | 2011-02-01 02:12:57 | 2022-03-06 03:43:46.018670 | Accepted | closed | *.djangoproject.com | 1.0 | worksforme | Trac should link to report views from tickets | Trac shows a table at the top of each ticket listing its component, keywords and so on. It would be really handy if those were links to reports that show all other tickets with the same keyword / component / milestone or whatever. Maybe there's a plugin for this? | nobody | simon | trac | 0 | 0 | 0 | 0 | 0 | 0 | ||
9007 | 2008-09-10 05:19:36 | 2011-02-17 23:45:03 | 2022-03-06 03:43:45.655262 | Accepted | closed | Documentation | 1.0 | fixed | Restore model examples in the new docs system | The "official repository of model examples" is still linked via the old docs domain at 4 occurrences in (1). Now that the old domain redirects to the new one, those model examples can't be accessed at all. So I guess those examples now need to be restored in the new docs domain. (1) http://docs.djangoproject.com/en/dev/topics/db/models/ | nobody | julien | 0 | 0 | 0 | 0 | 0 | 0 | |||
9005 | 2008-09-10 04:36:27 | 2011-09-28 16:12:21 | 2022-03-06 03:43:45.299209 | Ready for checkin | closed | Template system | dev | fixed | url templatetag incorrectly assumes settings.SETTINGS_MODULE is not set to None | When rolling your own config using conf.settings.configure() instead of the DJANGO_SETTINGS_MODULE environment variable, settings.SETTINGS_MODULE gets set to None. Any code which assumes that settings.SETTINGS_MODULE has been set to a string would be incorrect. I've attached a patch to fix an occurrence of this issue in the url templatetag which currently causes an {{{AttributeError: 'NoneType' object has no attribute 'split'.}}} | nobody | metzen | 0 | 1 | 0 | 0 | 0 | 0 | |||
9012 | 2008-09-10 14:40:30 | 2011-09-28 16:12:21 | 2022-03-06 03:43:46.539771 | Accepted | closed | Documentation | 1.0 | fixed | In docs, "Using models" is under "Writing models" which isn't logical | (It's like having the "Marriage" section under the "Getting laid" section) Anyway, I think the section should be titled "Writing and using models" because yesterday I couldn't find how to use models because I didn't even think of looking under "Writing models" (because I assumed it only contained information about how to write models, makes sense, huh?). | jacob | Erik Allik <eallik@gmail.com> | 0 | 0 | 0 | 0 | 0 | 0 | |||
9023 | 2008-09-10 19:40:41 | 2011-09-28 16:12:21 | 2022-03-06 03:43:48.367642 | Accepted | closed | Database layer (models, ORM) | dev | fixed | OneToOneField delete() problem | Accessing the automatic reverse relationship on an instance (w.sprocket in the following example) causes some type of caching to happen which results in my Sprocket getting caught up in a cascade delete() of a Widget erroneously. The following example works without the print statement, and my Sprocket s exists at the end. If I 'print w.sprocket' before clearing the relationship, my Sprocket gets deleted along with my Widget when it shouldn't. {{{ class Widget(models.Model): name = models.CharField(max_length=10) def __unicode__(self): return u'%s(%s)'%(self.name,self.pk) class Sprocket(models.Model): name = models.CharField(max_length=10) w = models.OneToOneField(Widget, null=True, blank=True) def __unicode__(self): return u'%s(%s)'%(self.name,self.pk) And the following sequence of operations: w=Widget(name="Some Widget") w.save() s=Sprocket(name="Some Sprocket") s.w=w s.save() assert Widget.objects.all().count()==1 assert Sprocket.objects.all().count()==1 #print w.sprocket s.w=None s.save() w.delete() assert Widget.objects.all().count()==0 assert Sprocket.objects.all().count()==1 }}} | nobody | TheShark | OneToOneField delete cascade | 0 | 1 | 1 | 0 | 0 | 0 | ||
9002 | 2008-09-10 00:40:42 | 2011-11-16 10:52:29 | 2022-03-06 03:43:44.781964 | Accepted | closed | Testing framework | Uncategorized | Normal | 1.0 | fixed | Easy way to create mock Request objects for testing views | The testing framework currently encourages hooking up a view function using a URLconf and then using the TestClient to run tests against the view. It would be nice if there was an easy way to bypass URLconf entirely in testing and just create a mock object representing a GET / POST / etc request, then pass that directly to the view function. See this thread: http://groups.google.com/group/django-developers/browse_thread/thread/db86050095ebe5db And this snippet: http://www.djangosnippets.org/snippets/963/ | kkubasik | simon | 0 | 0 | 0 | 0 | 0 | 0 | |
9015 | 2008-09-10 17:29:02 | 2011-12-17 12:06:48 | 2022-03-06 03:43:47.024915 | Design decision needed | closed | Core (Other) | New feature | Normal | dev | wontfix | Signal Connection Decorators | Usually, signal receivers are defined as functions and then connected to a specific signal via a function call to the signal instance's {{{connect}}} method. The problem is, this registration of the receiver is located outside the receiver's definition. This can cause clutter, it violates DRY, and it is not very Pythonic in style. Several examples of the current usage pattern are included in the [http://docs.djangoproject.com/en/dev/topics/signals/ signal docs], so I don't need to go into too much detail. I propose a change to the {{{connect}}} method on the {{{django.dispatch.dispatcher.Signal}}} class, which would allow you to decorate a signal receiver function and therefore skip the explicit call to the method. The usage of the new method would look something like this: {{{ #!python from django.db.models.signals import pre_save # Just an example of a signal. @pre_save.connect(sender=MyModel) # Other keyword arguments may be given. def receiver(sender, instance, *args, **kwargs): pass # Do something here. }}} ---- I've written a patch which does exactly this, preserving backwards compatibility also (although that's not the biggest issue right now; signals are a very recent addition). It works by moving the current {{{Signal.connect}}} method to {{{Signal._connect}}}, replacing it with a small wrapper around the original which, when called, does one of two things: * If called with positional arguments (and, optionally, keyword arguments), it behaves like the old {{{Signal.connect}}}, connecting the given receiver function to the signal. This allows it to be used as both a decorator and a registration function. * If called with keyword arguments but no positional arguments, it returns a wrapper function, allowing it to decorate the receiver function and include the given keyword arguments (thanks to Python's lexical scoping). This means it will work like so (with the effects easy to determine from the code): {{{ #!python from django.db.models.signals import pre_save # D… | brosner | zvoase | signals | 0 | 1 | 1 | 0 | 0 | 0 |
9026 | 2008-09-10 23:38:44 | 2013-03-19 09:03:28 | 2022-03-06 03:43:48.866099 | Design decision needed | closed | Core (Management commands) | Bug | Normal | 1.0 | wontfix | Scripts receive invalid keyboard input under Windows with JVM | In trunk and 1.0 on Windows, the createsuperuser command fails to recognize input as valid, because every line of input is terminated with '\r', which the command is not expecting. syncdb causes a similar problem when it presents the createsuperuser question loop, where the only way out is Ctrl-C. In a regular Python or IPython shell running on Windows, the result of raw_input() isn't terminated with whitespace at all. Are we doing something weird with stdin in the management commands? | nobody | ikelly | 0 | 0 | 0 | 0 | 0 | 0 | |
9025 | 2008-09-10 22:25:56 | 2020-06-06 22:40:54 | 2022-03-06 03:43:48.696064 | Accepted | new | contrib.admin | New feature | Normal | dev | Nested Inline Support in Admin | Currently, admin.TabularInline and admin.StackedInline do not support inlines themselves. This would allow nested inlines to happen. | pixelcort | 0 | 1 | 1 | 0 | 0 | 1 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE tickets ( id int primary key, created datetime, changetime datetime, last_pulled_from_trac datetime, stage text, status text, component text, type text, severity text, version text, resolution text, summary text, description text, owner text, reporter text, keywords text, easy boolean, has_patch boolean, needs_better_patch boolean, needs_tests boolean, needs_docs boolean, ui_ux boolean );