44 rows where "changetime" is on date 2010-01-10

View and edit SQL

Suggested facets: stage, component, version, resolution, owner, has_patch, needs_better_patch, needs_tests, created (date), last_pulled_from_trac (date)

changetime (date)

  • 2010-01-10 · 44
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
3237 2007-01-05 22:11:58 2010-01-10 00:42:21 2019-06-24 00:49:44.327116 Design decision needed closed Core (Other) enhancement normal   wontfix [patch] CIDR in INTERNAL_IPS It'd be nice if INTERNAL_IPS could support CIDR expressions: class CIDR_LIST(list): def __init__(self, cidrs): self.cidrs = [] try: #http://cheeseshop.python.org/pypi/IPv4_Utils/0.35 import ipv4 for cidr in cidrs: self.cidrs.append(ipv4.CIDR(cidr)) except ImportError: pass def __contains__(self, ip): import ipv4 try: for cidr in self.cidrs: if ipv4.CIDR(ip) in cidr: return True except: pass return False INTERNAL_IPS = CIDR_LIST([ '127.0.0.1', '10.0.0.0/24' ]) nobody Jeremy Dunck <jdunck@gmail.com> CIDR INTERNAL_IPS 0 0 0 0 0 0
3274 2007-01-10 11:41:47 2010-01-10 19:54:50 2019-06-24 00:50:07.855717 Accepted closed Generic views enhancement normal master fixed [patch] Provide date_list to template context in archive_month view As django.views.generic.date_based.archive_index (and django.views.generic.date_based.archive_year provide) provide a list of datetime.date to template context representing all years (and months) that have objects available according to queryset, it would be coerent that django.views.generic.date_based.archive_month provides a date_list containing datetime.date representing all days that have objects available according to queryset. nobody paolo <paolo@php3.it> archive_month date_list 0 1 0 1 0 0
6199 2007-12-13 04:18:58 2010-01-10 02:14:39 2019-06-24 01:21:37.546936 Accepted closed Core (Cache system)     master wontfix Avoid cache stampedes From the patch: {{{ + Avoids cache stampeding by missing on *one* request prior to actual + expiration. That single missed requestor then refills the cache prior to + real expiration. All other requestors still get hits. + + Adapted from MintCache from gfranxman: + http://www.djangosnippets.org/snippets/155/ }}} This is also similar to mnot's stale-while-revalidate: http://www.mnot.net/blog/2007/12/12/stale The cache wrapper works with any backend, but does have a 2% access overhead. Additionally, rather than storing exactly what is asked in the backend, additional bookkeeping data is stored in a tuple alongside the original object. nobody jdunck performance scalability cache 0 1 1 0 0 0
6955 2008-04-04 05:20:10 2010-01-10 02:52:47 2019-06-24 01:29:51.952584 Accepted closed Validators     master wontfix Unicode XML breaks RelaxNGCompact validator In Django, the RelaxNGCompact validator writes out the field data to a temp file, then shells out to jing to perform RNG validation on that XML. It's been broken for unicode data since the unicode branch landed. I guess not that many people use the RelaxNGCompact validator. ;-) The fix is trivial-- just call smart_str on field data on its way into the file. I'd provide tests, but I'm sort of overworked at the moment. :-/ jdunck jdunck unicode 0 1 0 1 0 0
7485 2008-06-17 20:03:05 2010-01-10 17:54:27 2019-06-24 01:35:35.525119 Design decision needed closed contrib.admin     0.96 invalid OtherField validators don't work with inline child objects If you have a child model that references a parent model as a foreign key, and edit them inline in the django admin UI, you can't use any of the *OtherField validators such as IsLessThanOtherField. The reason is that these validators expect the other_key parameter to be the exact name of the relevant form field; but with ForeignKey(edit_inline=...), the name is mangled. I tried this workaround - but see the inline comments for why it's wrong: {{{ class IsGreaterThanOtherField: """Django defines an IsLessThanOtherField validator, but it doesn't work on one-to-many children because the keys have some name-mangling going on. """ def __init__(self, other_field): self.other_field = other_field def __call__(self, field_data, all_data): # We have to iterate over them because we don't know the name of # our own field. for key, val in sorted(all_data.items()): if val == field_data: # Hope and pray there's no duplicate values. # If there are, this validator will only work for the first row. # The remaining rows will incorrectly compare against other_field from the first row. modelname, pkey, fieldname = key.split('.') myval = val break otherkey = '.'.join([modelname, pkey, self.other_field]) if myval <= all_data[otherkey]: raise validators.ValidationError( "Must be greater than the value of %s" % self.other_field) }}} I can't think of any way to work around this limitation, because the validator API doesn't provide any way that I see to know the actual name of the field we're validating. nobody slinkp@gmail.com   0 0 0 0 0 0
7486 2008-06-17 20:58:03 2010-01-10 17:54:51 2019-06-24 01:35:36.291189 Design decision needed closed contrib.admin     0.96 invalid IsLessThanOtherField's third argument is required, but documented as optional The documentation at http://www.djangoproject.com/documentation/0.96/forms/#validators says: "Each of the standard validators that take parameters have an optional final argument (error_message) that is the message returned when validation fails. If no message is passed in, a default message is used." But in django/core/validators.py, we can see that both IsLessThanOtherField and UniqueAmongstFieldsWithPrefix do not have default values for error_message. For consistency, I think we should say the docs are correct and the code should be fixed to match. nobody slinkp@gmail.com   0 0 0 0 0 0
8049 2008-07-30 23:38:21 2010-01-10 16:51:13 2019-06-24 01:41:43.120281 Accepted closed contrib.admin     1.0 fixed AdminSite login has_permission inconsistency This is mainly a suggestion for refactoring but it may have security implications. Within the new AdminSite class you have a has_permission method and a login method. has_permission checks for: {{{request.user.is_authenticated() and request.user.is_staff}}} while after authenticating login checks for: {{{if user.is_active and user.is_staff:}}} This results in a situation where a user may no longer be able to login but they still have permission to use the site, for example if a user were deactivated while logged in. Since the has_perm method of the user object checks if the user is active this doesn't seem to be too big of a problem under the current configuration, any attempt to access a specific object fails when the user.has_perm method is called. However this seems to be relying on a side effect, as the code evolves or for people subclassing the AdminSite real problems may result. Things could get ugly if someone were to override the has_permission method in a subclass and not the login method or vice versa. I perhaps may not have dug deeply enough and there is a good reason for having two sets of tests that can be different but in general this seems to violate the DRY principle and open the door for future problems. It appears the code would be more robust if there were a single set of tests that both login and has_permission checked during verification. At the very least it would seem to make sense to explicitly check for user.is_active within the has_permission method rather than waiting for the admin model object to implicitly check it during an add/change/delete has_perm test. Thank you, brosner nathan AdminSite login has_permission 0 1 0 0 0 0
9223 2008-09-27 12:10:11 2010-01-10 19:23:42 2019-06-24 01:55:18.313572 Ready for checkin closed Forms     1.0 fixed Declarative widgets for ModelForm Implementation of {{{widgets}}} attribute of inner {{{Meta}}} class of {{{ModelForm}}}. The whole (but short!) discussion is here: http://groups.google.com/group/django-developers/browse_frm/thread/f879f383870b92c1 nobody isagalaev   0 1 0 0 0 0
9770 2008-12-08 05:15:44 2010-01-10 21:54:09 2019-06-24 02:01:12.604926 Ready for checkin closed *.djangoproject.com       fixed extraneous slash in search link of "Welcome to the new documentation" message The `{{ home }}` already contains a trailing slash. The attached patch changes link to use `{{ search }}`, which is being passed to the template but not used. nobody gwilson   0 0 0 0 0 0
9940 2009-01-01 21:27:41 2010-01-10 15:37:13 2019-06-24 02:03:02.944703 Accepted closed Testing framework     master fixed Pass DATABASE_OPTIONS to regressiontests/admin_scripts tests The tests in `tests/regressiontests/admin_scripts` involve the creation of a number of settings files. Currently, only the values of the `DATABASE_ENGINE`, `DATABASE_NAME`, `DATABASE_USER`, `DATABASE_PASSWORD`, `DATABASE_HOST`, `DATABASE_PORT` and `ROOT_URLCONF` settings are copied from the user-provided settings. The DB backends included with Django don't need additional settings to be able to run such tests under a complete DB environment but for other (external) backends some additional information might be needed. In the case of `django-pyodbc`, historically `DATABASE_ODBC_DRIVER` and `DATABASE_ODBC_DSN` have been examples of such settings (they allow to configure some ODBC-related values). Providing default values for them in the backend isn't a always a complete solution and asking Django to preserve their values is out of question because it would be non-generic. What could be done instead is: a) ask for the `DATABASE_OPTIONS` setting to be preserved (that's what this ticket is all about) and b) in the backend side: Gradually migrate these settings to `DATABASE_OPTIONS`. ramiro ramiro regressiontests admin_scripts DATABASE_OPTIONS 0 1 0 0 0 0
10787 2009-04-10 23:34:42 2010-01-10 16:59:22 2019-06-24 02:12:15.333379 Accepted closed Generic views     master duplicate debug.py Templates: Request URLs Should Include django.root Hi, In a few place in [browser:django/trunk/django/views/debug.py] a string is built to show the request, like so: {{{ <th>Request URL:</th> <td>{{ request_protocol }}://{{ request.META.HTTP_HOST }}{{ request.path_info|escape }}</td> }}} However, {{{request.path_info}}} is only relative to root URL of which ever settings module is being used. To correct this, the script name (e.g., {{{django.root}}} for Apache and mod_python), should be added. {{{ <th>Request URL:</th> <td>{{ request_protocol }}://{{ request.META.HTTP_HOST }}{{ request.META.SCRIPT_NAME }}{{ request.path_info|escape }}</td> }}} One way to do this would be to modify {{{request.path_info}}}, but I don't think that would be correct. In particular, when listing a 404, the URLs shown should probably only be those be checked for matches, which are "below" the root URL. But, anywhere that lists the protocol, host, and path, should be corrected to match what's in the browser (or queried by a script, etc.). From what I can see, the following lines should be updated: * [browser:django/trunk/django/views/debug.py#L402 402] * [browser:django/trunk/django/views/debug.py#L532 532] * [browser:django/trunk/django/views/debug.py#L744 744] I'm hesitating on provding a patch, since I'm not sure if {{{request.META['SCRIPT_NAME']}}} is always set, and where the trailing slashes are. --Rick nobody rpwagner debug 0 0 0 0 0 0
10800 2009-04-12 09:51:52 2010-01-10 17:22:30 2019-06-24 02:12:23.855681 Ready for checkin closed Documentation     master fixed render_to_string and render_to_response use select_template In documentaztion: "The Django template language: For Python programmers" http://docs.djangoproject.com/en/dev/ref/templates/api/ accordind with: http://code.djangoproject.com/ticket/546 render_to_string and render_to_response can use select_template so: "The render_to_string shortcut takes one required argument -- template_name, which should be the name of the template to load and render -- and two optional arguments:" should be: "The render_to_string shortcut takes one required argument -- template_name, which should be a string with the name of the template to load and render or a list or tuple containing templates arguments for select_template -- and two optional arguments:" nobody p.patruno@iperbole.bologna.it   0 1 0 0 0 0
10862 2009-04-17 21:32:51 2010-01-10 17:24:00 2019-06-24 02:13:04.546441 Ready for checkin closed Documentation     master fixed Confusing image field text The page [http://docs.djangoproject.com/en/dev/ref/models/fields/#imagefield] has the documentation, "In addition to the special attributes that are available for FileField, an ImageField also has File.height and File.width attributes. See [http://docs.djangoproject.com/en/dev/topics/files/#topics-files Managing files]." However, clicking Managing files takes you to [http://docs.djangoproject.com/en/dev/topics/files/#topics-files] which does not mention width or height on the page. I can see how this would be confusing to people reading the docs. Would a link to [http://docs.djangoproject.com/en/dev/ref/files/file/#additional-imagefield-attributes] be clearer? Or perhaps mention the words width or height by the link, "The File Object" so users see that and follow through? nobody mw imagefield 0 1 0 0 0 0
10887 2009-04-22 08:38:30 2010-01-10 18:56:53 2019-06-24 02:13:20.647633 Ready for checkin closed contrib.admin     1.0 fixed admin.autodiscover In {{{django/contrib/admin/__init__.py}}}, I suggest to change the following code: {{{ try: app_path = import_module(app).__path__ except AttributeError: continue }}} into: {{{ mod = import_module(app) try: app_path = mod.__path__ except AttributeError: continue }}} Otherwise there is a probably not intended behaviour if one of my modules is buggy and raises itself an AttributeError. nobody lsaffre   0 0 0 0 0 0
10947 2009-04-28 12:06:18 2010-01-10 17:25:44 2019-06-24 02:14:02.836548 Ready for checkin closed Documentation     1.0 fixed Queryset "__in" documentation missing list() call http://docs.djangoproject.com/en/dev/ref/models/querysets/#in The part in "Performance considerations" does not work that way. It's missing a list() call to really get a list into the query. nobody julianb   0 1 0 0 0 0
10979 2009-05-02 17:55:17 2010-01-10 17:28:21 2019-06-24 02:14:23.274088 Ready for checkin closed Core (Other)     master fixed FixedOffset.__repr__ is misleading for negative offsets If you pass a negative offset to `FixedOffset`, the tzinfo representation is misleading: {{{ >>> from django.utils.tzinfo import FixedOffset >>> tz = FixedOffset(-510) >>> tz -0930 }}} The attached patch simply calculates the hours as a float, which yields the more correct representation. {{{ >>> from django.utils.tzinfo import FixedOffset >>> tz = FixedOffset(-510) >>> tz -0830 }}} gsong gsong tzinfo 0 1 0 0 0 0
11109 2009-05-13 21:58:09 2010-01-10 21:45:24 2019-06-24 02:15:46.868746 Ready for checkin closed *.djangoproject.com     1.0 fixed Changeset 8224 broken in Trac When trying to access http://code.djangoproject.com/changeset/8224, I get: "500 Internal Server Error (No changeset 8224 in the repository)". It looks like the Subversion repository is intact, so I suspect the Trac database may need to be resync'd... {{{ $ svn log -r 8224 http://code.djangoproject.com/svn/ ------------------------------------------------------------------------ r8224 | jbronn | 2008-08-06 22:40:00 +0100 (Wed, 06 Aug 2008) | 2 lines gis: The `verbose_name` positional keyword now works for `GeometryField`, thanks springmeyer; removed DOS line endings from Oracle & MySQL spatial backends, thanks cramm. ------------------------------------------------------------------------ }}} {{{ $ svn diff -r 8223:8224 http://code.djangoproject.com/svn/ | grep Index: Index: django/trunk/django/contrib/gis/db/models/fields/__init__.py Index: django/trunk/django/contrib/gis/db/backend/mysql/query.py Index: django/trunk/django/contrib/gis/db/backend/oracle/query.py }}} jacob frasern   0 0 0 0 0 0
11222 2009-05-27 22:37:38 2010-01-10 21:56:36 2019-06-24 02:16:58.549004 Ready for checkin closed Documentation     1.0 fixed tutorial docs only give the relative location of the templates In the tutorial docs, part 2, we have this text: "Now copy the template admin/base_site.html from within the default Django admin template directory (django/contrib/admin/templates) into an admin subdirectory of whichever directory you're using in TEMPLATE_DIRS." Since I just installed it I figured it might be in the source, and it seems to be there, but since it didn't get installed (using the instructions at the root of the tar file I downloaded) it would be hard to find if one were not the original installer. The suggestion is for the docs to mention that the template dirs are in the source distro, or to have the setup.py script install the templates and have the docs reference that installed location, or have an admin class that does it. But I'm having fun!! nobody cantorman   0 1 0 0 0 0
11232 2009-05-29 15:34:13 2010-01-10 21:48:55 2019-06-24 02:17:04.910401 Ready for checkin closed *.djangoproject.com       fixed Using Django link on the django home page points to Reference. The link in the Documentation section points to the Documentation reference section rather than the link http://docs.djangoproject.com/en/dev/topics which it should be. Hopefully I'm saying this in the right place in the right way. nobody wyleu   0 1 0 0 0 0
11409 2009-06-30 20:43:09 2010-01-10 21:58:02 2019-06-24 02:18:58.385352 Ready for checkin closed contrib.admin     master fixed Reorder permissions booleans in user admin The boolean permissions should be in a more logical order. It makes sense to list the three permissions booleans in order of ascending power, i.e. the user can: 1. log into the site, 2. log into the site and admin, 3. log into the site and admin, and alter anything. This change will make the learning curve a little smoother for new users. It may catch a few current users off guard, but the sensible nature of the change will take quickly. nobody benspaulding auth user admin 0 1 0 0 0 0
11501 2009-07-18 19:17:09 2010-01-10 18:55:05 2019-06-24 02:19:58.027744 Ready for checkin closed Documentation     1.0 fixed Punctuation error Tutorial Page 2: The Django admin is powered by Django itself, and its interfaces use Django's own template system. (How meta!) Should be: The Django admin is powered by Django itself, and its interfaces use Django's own template system—how meta! The em dash (—), or m dash, m-rule, etc., often demarcates a parenthetical thought—like this one—or some similar interpolation. Parentheses can be used, however it would be rare. If parentheses are applied correctly to the offending statement, it should look like this; The Django admin is powered by Django itself, and its interfaces use Django's own template system (how meta!) nobody pzero punctuation 0 1 0 0 0 0
11693 2009-08-11 14:38:05 2010-01-10 18:53:12 2019-06-24 02:22:00.066022 Ready for checkin closed Documentation     1.1 fixed Sitemap framework docs contain a regular expression error in the URLconf examples The [http://docs.djangoproject.com/en/dev/ref/contrib/sitemaps/ documentation page] for the sitemap framework contains a small regular expression error in the URLconf examples. Several times the page uses the following regular expression: {{{ r'^sitemap.xml$' }}} when it should be using the following regular expression: {{{ r'^sitemap\.xml$' }}} as the dot is a metacharacter which should be escaped. nobody anonymous   0 1 0 0 0 0
11783 2009-08-25 17:24:18 2010-01-10 21:37:21 2019-06-24 02:22:59.666953 Ready for checkin closed Contrib apps     1.1 fixed django.contrib.humanize.templatetags.ordinal throws TypeError for NoneType The short summary probably covered everything. ordinal(value) catches ValueError but not TypeError. Error Message: "Exception Value: int() argument must be a string or a number, not 'NoneType'" nobody realpolitik contrib, humanize, ordinal, ValueError 0 1 0 0 0 0
11842 2009-09-07 03:52:24 2010-01-10 21:36:13 2019-06-24 02:23:37.699855 Ready for checkin closed Core (Management commands)     master fixed django-admin.py should display help output when no arguments are given Ticket #378 mentions having `django-admin.py` honor Unix traditions -- and yet if you invoke it with no arguments, you get a profoundly unfriendly and non-Unix-like message: {{{ $ django-admin.py Type 'django-admin.py help' for usage. }}} Compare to, say, `apt-get`: {{{ $ apt-get apt 0.7.9ubuntu17.2 for i386 compiled on Apr 17 2009 16:29:24 Usage: apt-get [options] command apt-get [options] install|remove pkg1 [pkg2 ...] apt-get [options] source pkg1 [pkg2 ...] [...] }}} or git: {{{ $ git usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS] [...] }}} I'm sure I didn't need to give examples, but I felt like being thorough :) The code related to this has not changed significantly since the 1.0.X branch -- i.e. the (tiny) patch applies cleanly to the latest 1.0.X branch checkout, as well as the latest SVN. I'm not seeing any tests that apply to django-admin.py at all, so not including one -- please point me to the right spot if I've missed something. nobody bitprophet   0 1 0 0 0 0
11880 2009-09-15 01:44:16 2010-01-10 18:01:22 2019-06-24 02:24:06.968574 Ready for checkin closed Documentation     1.1 fixed Admin site URL Conf docs missing raw string notation as explained in this paragraph http://www.djangobook.com/en/2.0/chapter03/#cn123 http://docs.djangoproject.com/en/dev/ref/contrib/admin/#hooking-adminsite-instances-into-your-urlconf[[BR]] is missing the '''r'''"regex" notation in various examples. this is a trivial oversight, but should probably be changed just for consistency. nobody jb0t typo 0 1 0 0 0 0
11884 2009-09-15 21:57:33 2010-01-10 18:07:47 2019-06-24 02:24:09.513578 Ready for checkin closed Documentation     1.1 fixed Clarify in documentation how to enable built-in reference in admin. Setting up [http://docs.djangoproject.com/en/dev/topics/templates/#using-the-built-in-reference built-in reference in admin] is not described anywhere in the docs - it requires adding {{{django.contrib.admindocs.urls}}} to {{{INSTALLED_APPS}}}, adding {{{(r'^admin/doc/', include('django.contrib.admindocs.urls'))}}} to {{{urlpatterns}}} and installing docutils if they are not present. Finding this out for me was untrivial and required googling, so I would add description of these steps to the corresponding section of documentation (see the patch). nobody DmitryRisenberg admin reference setup 0 1 0 0 0 0
11904 2009-09-18 06:51:11 2010-01-10 18:09:27 2019-06-24 02:24:22.359680 Ready for checkin closed Documentation     1.1 fixed Error on docs page for conditional view processing On http://docs.djangoproject.com/en/dev/topics/conditional-view-processing/ it says "If there is no match with the ETag, or if the resource has not been modified, a 304 status code can be sent back, instead of a full response, telling the client that nothing has changed." The first "no" must be deleted if I understood the whole thing correctly. nobody bronger   0 1 0 0 0 0
11952 2009-09-27 19:10:07 2010-01-10 18:49:05 2019-06-24 02:24:53.448936 Ready for checkin closed Documentation     1.1 fixed HttpResponse Attribute docs refer to "status" when should be "status_code" Docs here: http://docs.djangoproject.com/en/dev/ref/request-response/#id2 HttpResponse Attribute docs refer to "status" attribute when should be "status_code" I tested this as of REV # 11594 Peter nobody pjs   0 1 0 0 0 0
11976 2009-10-03 19:44:18 2010-01-10 21:51:15 2019-06-24 02:25:08.736309 Ready for checkin closed Documentation     1.1 fixed typo in docs/ref/contrib/comments/forms.txt This class contains the name, email, url, and the comment field itself, along with the associated valdation logic. valdation > validation nobody anonymous typo 0 1 0 0 0 0
12047 2009-10-16 20:54:18 2010-01-10 17:42:54 2019-06-24 02:25:54.034947 Ready for checkin closed Documentation     1.1 fixed Copy/paste error in documentation http://docs.djangoproject.com/en/dev/ref/generic-views/#django-views-generic-date-based-archive-day In the template context portion of the documentation for the date_based.archive_day generic view, "previous_day" is incorrectly documented: "previous_day: A datetime.date object representing the given day. [...]" I believe this is just a copy/paste error from "day": "day: A datetime.date object representing the given day." The correct documentation should be: "previous_day: A datetime.date object representing the previous day." nobody schickler typo 0 0 0 0 0 0
12084 2009-10-26 09:15:56 2010-01-10 18:36:46 2019-06-24 02:26:18.605466 Ready for checkin closed Documentation     1.1 fixed Document the return type of QuerySet.update() [http://docs.djangoproject.com/en/dev/topics/db/queries/#updating-multiple-objects-at-once From the documentation]: "The update() method is applied instantly and doesn't return anything […]" This is not true. `QuerySet.update()` returns the number of rows affected by the `UPDATE` query, which is quite useful. The [http://code.djangoproject.com/browser/django/trunk/tests/modeltests/update/models.py update tests] rely on this feature. Make it part of the public API. nobody anonymous   0 1 0 0 0 0
12092 2009-10-26 21:59:51 2010-01-10 17:47:54 2019-06-24 02:26:23.759014 Ready for checkin closed Documentation     1.1 fixed grammatical error on http://docs.djangoproject.com/en/dev/intro/install/ The warning box near the end of the page starts with "If do either of the first two steps," I think this should be "If '''you''' do either…" (bold marks added word). I'm adding a shot of the relevant section: [http://emberapp.com/abizern/images/safari] nobody Abizern typo 0 1 0 0 0 0
12113 2009-10-29 17:29:58 2010-01-10 19:05:39 2019-06-24 02:26:37.071366 Ready for checkin closed Documentation     1.1 fixed contrib.auth documentation is misleading re: whether User.is_active matters for login The documentation at source:/django//trunk/docs/topics/auth.txt says {{{ .. attribute:: models.User.is_active Boolean. Designates whether this user account should be considered active. Set this flag to ``False`` instead of deleting accounts. This doesn't control whether or not the user can log in. Nothing in the authentication path checks the ``is_active`` flag, so if you want to reject a login based on ``is_active`` being ``False``, it is up to you to check that in your own login view. However, permission checking using the methods like :meth:`~models.User.has_perm` does check this flag and will always return ``False`` for inactive users. }}} "This doesn't control whether or not the user can log in." This is technically true, but misleading, because the default `AuthenticationForm` in django.contrib.auth *does* reject inactive users. This behavior is undocumented. nobody ejucovy   0 1 0 0 0 0
12161 2009-11-04 19:31:41 2010-01-10 21:52:20 2019-06-24 02:27:07.826001 Ready for checkin closed Documentation     1.1 fixed Error in code example - Generic views (regular expression) (at this page: http://docs.djangoproject.com/en/dev/topics/generic-views/) This code example is nonfuctional: {{{ from django.conf.urls.defaults import * from django.views.generic.simple import direct_to_template from mysite.books.views import about_pages urlpatterns = patterns('', ('^about/$', direct_to_template, { 'template': 'about.html' }), ('^about/(w+)/$', about_pages), ) }}} It should be like this: {{{ from django.conf.urls.defaults import * from django.views.generic.simple import direct_to_template from mysite.books.views import about_pages urlpatterns = patterns('', ('^about/$', direct_to_template, { 'template': 'about.html' }), ('^about/(\w+)/$', about_pages), ) }}} In short: the token (w+) should be replaced for (\w+) in order to have de desired functionality nobody infopams regular-expression documentation generic-views 0 1 0 0 0 0
12195 2009-11-10 16:11:33 2010-01-10 18:40:25 2019-06-24 02:27:29.476899 Ready for checkin closed Documentation     1.1 fixed cache set method - timeout - documentation http://docs.djangoproject.com/en/1.0/topics/cache/#the-low-level-cache-api Docs say that the timeout parameter is called "timeout_seconds", but in fact it's called just "timeout". At least, that's what it's called in my Django 1.0, so the 1.0 docs should reflect that. nobody galund   0 1 0 0 0 0
12216 2009-11-15 05:51:31 2010-01-10 16:45:32 2019-06-24 02:27:42.832991 Ready for checkin closed Documentation     master fixed typo in flatpages docs There's a "not" in the flatpages docs where it doesn't belong: {{{ Also make sure you’ve correctly set SITE_ID to the ID of the site the settings file represents. This will usually be 1 (i.e. SITE_ID = 1, but if you’re not using the sites framework to manage multiple sites, it could be the ID of a different site. }}} It's if you _are_ using the sites framework to manage multiple sites that it could be the ID of a different site. nobody carljm   0 1 0 0 0 0
12228 2009-11-16 20:38:13 2010-01-10 17:58:41 2019-06-24 02:27:50.508620 Ready for checkin closed Documentation     1.1 fixed Outdated example in flatpages documentation. The first flatpages example (http://www.chicagocrime.org/about/) is now a redirect to http://chicago.everyblock.com/crime/ which, besides being a different site from the link, doesn't seem very flat. The page is: http://docs.djangoproject.com/en/dev/ref/contrib/flatpages/#module-django.contrib.flatpages nobody johnthedebs   0 1 0 0 0 0
12271 2009-11-27 19:45:19 2010-01-10 18:42:30 2019-06-24 02:28:19.053293 Ready for checkin closed Documentation     1.1 fixed Documentation typo in URLFields section of Model Field Reference The second sentence in this paragraph reads "serverd" instead of "served": http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.URLField.verify_exists nobody adam@andyet.net typo 0 1 0 0 0 0
12297 2009-12-01 21:52:20 2010-01-10 21:28:38 2019-06-24 02:28:35.424891 Ready for checkin closed Documentation     1.1 fixed Faulty example in DB query documentation (Making queries) In "Making queries", section "Caching and QuerySets"; The second example looks like: {{{ >>> queryset = Poll.objects.all() >>> print [p.headline for p in queryset] # Evaluate the query set. >>> print [p.pub_date for p in queryset] # Re-use the cache from the evaluation. }}} The first line should look like: {{{ >>> queryset = Entry.objects.all() }}} nobody bertil typo 0 1 0 0 0 0
12300 2009-12-02 08:38:50 2010-01-10 02:19:38 2019-06-24 02:28:37.298303 Unreviewed closed Uncategorized     master duplicate Catching exceptions and printing messages without file name and line number Hello! Lately I had a typo in app name in INSTALLED_APPS. What I get from django when trying to run manage.py shell, test etc. was: {{{ $ python manage.py shell Error: No module named name_with_typo }}} Like you see this message just suggest, that importing were wrong, because module is not accessible. If my module name was really "name_with_typo" I would find it very fast, but my name was "model", so browsing sources to find the reason was a bit exhausting. I start debugger and find that exception was catched here: {{{ # django/core/management/base.py:205 """ # Switch to English, because django-admin.py creates database content # like permissions, and those shouldn't contain any translations. # But only do this if we can assume we have a working settings file, # because django.utils.translation requires settings. if self.can_import_settings: try: from django.utils import translation translation.activate('en-us') except ImportError, e: # If settings should be available, but aren't, # raise the error and quit. sys.stderr.write(self.style.ERROR(str('Error: %s\n' % e))) sys.exit(1) }}} Exception was raised during {{{ translation.activate('en-us') }}} As you see it's not much intuitive... Why not to make error message more verbose? It would save our time. PS. Such "error handling" is used in many places of Django. Cheers! nobody zimnyx ImportError 0 0 0 0 0 0
12326 2009-12-06 19:50:22 2010-01-10 17:54:34 2019-06-24 02:28:53.793642 Ready for checkin closed Documentation     1.1 fixed Spelling, /en/dev/intro/tutorial04 Page <http://docs.djangoproject.com/en/dev/intro/tutorial04/>: "Delete some the old" should be "Delete some of the old" nobody mortense typo 0 1 0 0 0 0
12345 2009-12-09 07:41:12 2010-01-10 18:50:29 2019-06-24 02:29:06.791922 Ready for checkin closed Documentation     master fixed incorrect invoking in the example of Multi-table inheritance section Refs http://code.djangoproject.com/browser/django/trunk/docs/topics/db/models.txt?rev=10818#L926 . {{{ p = Place.objects.filter(name="Bob's Cafe") # If Bob's Cafe is a Restaurant object, this will give the child class: >>> p.restaurant <Restaurant: ...> }}} p is a !QuerySet here and p.restaurant has no sense. following maybe better. {{{ p = Place.objects.get(name="Bob's Cafe") }}} nobody anonymous typo 0 1 0 0 0 0
12350 2009-12-10 19:35:15 2010-01-10 17:55:47 2019-06-24 02:29:10.289919 Ready for checkin closed Documentation     1.1 fixed Typo on /en/dev/intro/tutorial04 On page <http://docs.djangoproject.com/en/dev/intro/tutorial04>: "comes with very easy-to-use system" should probably be "comes with a very easy-to-use system". nobody mortense Typo 0 1 0 0 0 0
12537 2010-01-07 18:15:04 2010-01-10 17:56:53 2019-06-24 02:31:10.716758 Ready for checkin closed Database layer (models, ORM)     master fixed Mistake in db/models/base.py (dict.set_default instead of setdefault) Mistake causes AttributeError in latest (rev 12117) SVN nobody gauss   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
    );