tickets_full

29,846 rows sorted by reporter

View and edit SQL

Suggested facets: stage, status, type, severity, resolution, easy, has_patch, needs_better_patch, needs_tests, ui_ux

These facets timed out: 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
2834 2006-09-27 16:17:05 2006-10-14 13:00:00 2019-06-24 00:45:22.653521 Unreviewed closed Core (Other) defect minor master wontfix Indents in base.py comments breaks epydoc doc generation. Running the [http://epydoc.sourceforge.net/ Epydoc] document generator on a model returns the following error message: {{{ File: c:\dev\python-2.4.2\lib\site-packages\django\db\models\base.py, line 243, in django.db.models.base.Model._collect_sub_objects Lines 246, 247: Improper paragraph indentation }}} Looking at those lines, we find: {{{ def _collect_sub_objects(self, seen_objs): """ Recursively populates seen_objs with all objects related to this object. When done, seen_objs will be in the format: {model_class: {pk_val: obj, pk_val: obj, ...}, model_class: {pk_val: obj, pk_val: obj, ...}, ...} """ }}} The problem appears to be with the extra tabs in the last two lines of that comment. I've fixed it in my local version, but someone may want to fix the version in the repository so it doesn't break for others. adrian     0 0 0 0 0 0
7308 2008-05-26 15:00:03 2008-05-26 20:06:15 2019-06-24 01:33:41.143852 Unreviewed closed Core (Serialization)     master invalid (spam) (spam) nobody     0 1 0 0 0 0
9808 2008-12-11 23:36:41 2008-12-11 23:52:58 2019-06-24 02:01:37.102941 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9809 2008-12-11 23:49:16 2009-02-25 19:51:44 2019-06-24 02:01:37.705694 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9812 2008-12-12 05:41:56 2008-12-12 05:44:51 2019-06-24 02:01:39.639920 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9813 2008-12-12 05:41:57 2008-12-12 05:45:07 2019-06-24 02:01:40.284560 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9820 2008-12-12 15:19:20 2009-02-25 19:51:44 2019-06-24 02:01:44.809094 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9821 2008-12-12 15:19:22 2009-02-25 19:51:44 2019-06-24 02:01:45.464584 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9823 2008-12-12 20:02:32 2009-02-25 19:51:44 2019-06-24 02:01:46.727304 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9842 2008-12-14 07:45:08 2009-02-25 19:51:44 2019-06-24 02:01:59.077819 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9843 2008-12-14 07:45:13 2008-12-14 07:51:44 2019-06-24 02:01:59.737493 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9851 2008-12-14 23:28:18 2009-02-25 19:51:44 2019-06-24 02:02:04.959482 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9852 2008-12-14 23:28:18 2009-02-25 19:51:44 2019-06-24 02:02:05.599649 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9856 2008-12-15 06:49:43 2008-12-15 07:08:54 2019-06-24 02:02:08.214745 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9879 2008-12-18 00:18:37 2009-02-25 19:51:44 2019-06-24 02:02:23.059286 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9907 2008-12-23 19:26:44 2009-02-25 19:51:44 2019-06-24 02:02:41.566077 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9909 2008-12-24 22:07:08 2009-02-25 19:51:44 2019-06-24 02:02:42.888847 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
9922 2008-12-28 20:25:26 2009-02-25 19:51:44 2019-06-24 02:02:51.411232 Unreviewed closed Uncategorized     1.0 invalid spam spam nobody     0 0 0 0 0 0
13373 2010-04-18 04:34:08 2011-09-28 16:12:23 2019-06-24 02:40:23.465983 Accepted closed Template system     1.2-beta fixed IF tag no longer short-circuits It looks like {% if %} with OR or AND no longer short circuits under 1.2-beta-1. class Page(models.Model): ... def beTrue(self): print "BEING TRUE" return True def beFalse(self): print "BEING FALSE" return False {% if page.beTrue or page.beFalse %} HELLO {% endif %} Under 1.1.1, using manage.py runserver, I will only see "BEING TRUE" printed for the above snippet. Under 1.2-beta-1, I see both BEING TRUE and BEING FALSE. Similarly, {% if page.beFalse and page.beTrue %} HELLO {% endif %} will produce only "BEING FALSE" under 1.1.1, but both BEING FALSE and BEING TRUE under 1.2-beta-1. nobody     0 0 0 0 0 0
3437 2007-02-06 00:11:36 2007-02-10 03:56:21 2019-06-24 00:51:50.982744 Unreviewed closed Core (Other)     master fixed djang.http.HttpResponse logic for _is_string is invalid code currently does effectively thus- {{{ #!python if hasattr(content, '__iter__'): self._is_string = False self._container = content else: self._is_string = True self._container = [content] }}} Problem is that string objects support iteration. Fix for it's simple; just do {{{ #!python if not isinstance(content, basestring) and hasattr(content, '__iter__'): }}} (yes y'all prefer seperate patches, but it's a one liner ;) adrian (removed)   0 0 0 0 0 0
3438 2007-02-06 00:38:40 2007-02-26 06:16:19 2019-06-24 00:51:51.605826 Unreviewed closed Core (Other)     master fixed django.db.models.base.__init__ refactoring Short version; for iteration over records, there model's __init__ is rather unfriendly to the way the args are passed in. At least for sqlite, the sql row is passed in as args- issue is that __init__ shoots through self._model.fields playing with kwargs prior, doing rather costly exception catching, pulling default values, etc, then *finally* does args processing. If you're dealing in one or two records, this doesn't show up much, but if you're dealing in 53k records (my usage is slightly weird admittedly), it's a pretty heavy slow down. attached is a patch to refactor __init__, knocking around a third off the __init__ cost via refactoring the args/kwargs processing, essentially reversing the actual flow while maintaining the same behaviour as before. Have been using it for a few days, and passes tests; comments welcome, mainly since I need to get this integrated for my uses. adrian (removed)   0 1 0 0 0 0
3439 2007-02-06 01:07:33 2007-02-26 03:42:25 2019-06-24 00:51:52.271342 Accepted closed Core (Other)     master fixed django.dispatch.* is grossly slow Attached is a refactoring chopping off a good chunk of dispatch's overhead; hard to test it standalone, so testing was done for simple iteration over records and isolating the diff in the profiling for the refactoring. Short version, attached patch shows 5x boost in dispatch speed; for iteration (just that, no rendering) over 53k records, time drops from ~15.5s to ~11.6s just by cleaning up dispatch.* The internal data structs dispatch is using are still fairly innefficient- scaling will be an issue the more receivers there are for dispatched signals. So... can clean that up further, but there isn't any documentation re: the expectations of dispatcher. For example- order of connection to a signal, must the order be maintained for notifications at a specific sender/signal level? If I connect (in this order) func f1, func f2, both to object("foo") signal Any, must they be notified in order f1,f2? I realize pydispatcher is a seperate project- that said, they've already moved onto 2.0, and there are several 1.0.x's for pydispatcher released already- djangos' bundled copy is still at 1.0.0. Whats the intention? Intending on keeping it in sync, or is it just a fork point? Either way, the attached refactoring is not covered by tests at the moment- mainly since there are no tests in django for dispatcher. Would like to get feedback on the expectations of dispatcher (f1/f2 from above for example) prior to writing those tests, since the implementation (and google for that matter) lack any material on it. Finally, due to the massive number of calls to send (thus to getAllReceivers and friends), normal seperation (getAllReceivers using getReceivers for example) was intentionally broken down a bit- in other words, inlined a few functions. The codes invoked enough that the overheads seperation really isn't worth it, especially if you're not actually using signals for the most part (thus dispatcher is pretty much pure time waste). adrian (removed)   0 1 0 0 0 0
3441 2007-02-06 01:52:28 2007-02-06 14:01:13 2019-06-24 00:51:53.524305 Design decision needed closed Template system     master fixed django.template.VariableDoesNotExist.__init__ prototype forces work to be done up front that is typically thrown away Kind of a cornercase, but VariableDoesNotExist derives from Exception, overriding nothing- meaning the str/repr for it must be done up front. Thus django.template.resolve_variable raises it via {{{ raise VariableDoesNotExist, "Failed lookup for key [%s] in %r" % (bits[0], current) }}} So... it's effectively raising VariableDoesNotExist(msg). Problem here is that a rather large amount of code just catches the exception, and substitutes a different value, TEMPLATE_STRING_IF_INVALID for example- in other words, they don't even *care* about the msg, the exception is just a passing mechanism. Thus the msg creation is pure overhead to most codeblocks I've found in django. Said overhead can add up; a context level lookup ( {{ foo }} for example), raising VariableDoesNotExist results in repr(context), repr'ing all mappings in context- if say your base template is just checking for a var, if so, outputing a queryset, else not outputting it, the current code forces a repr on context, in other words forcing the query to be executed. Which is fairly daft, if pretty much all code just throws out the exception, substituting a different value in. Attached is a patch changing VariableDoesNotExist's __init__ to (self, msg, params=()); via that, can delay the actual msg creation until it's required, making catching the exception just to substitute a different value far cheaper. Within the code, only resolve_variable throws the exception- google code search, nobody else is throwing it, thus it looks pretty safe to change the __init__ to delay the cost. Alternative, just derive NewStyleVariableDoesNotExist from VariableDoesNotExist, and have resolve_variable throw that; either way, it's work being done that isn't needed so should be tweaked. adrian (removed)   0 1 0 1 0 0
3449 2007-02-07 04:46:36 2007-02-09 22:09:08 2019-06-24 00:51:58.538418 Ready for checkin closed Testing framework     master fixed rev 4460 test failures rev 4460 changed ChoiceField exception msg, but tests weren't updated... adrian (removed)   0 1 0 0 0 0
3453 2007-02-07 23:03:50 2007-09-21 04:00:33 2019-06-24 00:52:01.011170 Accepted closed Template system     master fixed resolve_variable usage leads to redundant work Yet more refactoring ;) resolve_variable does a chunk of setup work for each invocation, checking for if the variable is a number, checking if its quoted (thus exempted from lookup rules), and finally splitting of the variable into it's component parts. The issue is that this work is utterly redundant the second time an attempt is made to resolve the variable- for loops for example. This patch splits out a Variable class which does the common setup work up once in init, with a resolve method to do the actual resolution against a context. The actual resolve is still a good chunk of time, but for my particular usage scenario (3 level deep for loop being the main cost), this shaves just shy of 25% of the runtime off via killing the redundant work. From a backwards compatibility standpoint, there isn't any issue- resolve_variable just becomes {{{ def resolve_variable(arg, context): return Variable(arg).resolve(context) }}} which admittedly will be slightly slower then whats in place now for simple lookups- this is offset by the greater efficiency of Variable usage within default tags/templates, and via killing off a quadratic op in resolve_variable- currently, it splits the arg, then does poplefts on the list. Problem there is that python lists are literal arrays; you delete the first item, every item after has to be moved one to the left, thus quad in execution. Fortunately var depth isn't usually deep enough for it to rear its head. jacob (removed) performance 0 1 0 0 0 0
3454 2007-02-08 03:36:26 2011-10-09 12:44:57 2019-06-24 00:52:01.644598 Accepted closed Database layer (models, ORM)     master fixed sqlite backend is using row_factory when it should be using text_factory currently, sqlite has {{{ def utf8rowFactory(cursor, row): def utf8(s): if type(s) == unicode: return s.encode("utf-8") return s return [utf8(r) for r in row] }}} for row_factory; problem here is that it's rebuilding each record regardless of whether or not the utf8 conversion is required. doing {{{ Database.text_factory = lambda s:s.decode("utf-8") }}} limits the conversion to just TEXT objects. This is a bit faster; that said, I'm wondering why the forced conversion- sqlite stores data in utf8, if {{{ Database.text_factory = str }}} ware set, the whole decoding/encoding would be bypassed, and the native encoding (utf8) would be passed back. In terms of performance, using {{{ Database.text_factory = lambda s:s.decode("utf-8") }}} gains are dependant upon the column types; greater # of non-text fields, greater the gain. Real gain is via turning off the encode/decode and using str directly (underlying utf8); same gain in terms of avoiding extra inspection, but avoids all the extra work. Only downside to either change I can see is that raw sql queries would return str instead of sqlites unicode. Not really sure if this is an actual issue however (don't see any other such limitation in the backends). Patch is attached for the encode/decode variant; unless there are good reasons, would just bypass the encoding/decoding entirely. adrian (removed) unicode-branch 0 1 1 0 0 0
4441 2007-05-31 06:06:13 2007-05-31 15:32:37 2019-06-24 01:02:24.794427 Ready for checkin closed Template system     master fixed minor regroup optimization For template tag such as {{{ {% regroup records by category as categories %} }}} the internal lookup/rendering is implemented as a var resolve of 'var.category', with the calling context dropped; in other words, code is forcing an uneeded lookup for every iteration of regroup; following patch cuts out the uneeded 'var.' lookup. adrian (removed)   0 1 0 0 0 0
4460 2007-06-02 04:37:32 2007-08-07 13:43:50 2019-06-24 01:02:37.158525 Accepted closed Testing framework     master fixed runtests.py can't easily control which tests to run Right now, runtests.py accepts only model names to test- this isn't grand if you're specifically after running a regressiontest however, or even django.contrib.*. One can use trial, but that requires setting up a few extra envvars- it's not hard to do, it's just a fair bit of a hit to the workflow (at least it is for me). Attached is a patch mangling runtests.py so that it takes modeltests.model1, regressiontests.regresion1 args instead of just model names- additionally, can take modeltests.* or regressiontests.* to enable all tests for that namespace (basically). So for example- {{{ python tests/runtests.py --settings=settings -v 1 basic }}} becomes {{{ python tests/runtests.py --settings=settings -v 1 modeltests.basic }}} Upshot of that slightly larger invocation, is that regressiontests, django.contrib, any namespace can be specified now- {{{ python tests/runtests.py --settings=settings -v 1 regressiontests.bug639 python tests/runtests.py --settings=settings -v 1 django.contrib.sessions }}} adrian (removed)   0 0 0 0 0 0
4461 2007-06-02 12:20:15 2007-06-02 12:29:27 2019-06-24 01:02:37.784457 Unreviewed closed Template system     master duplicate minor ForNode.render reversed optimization short version, nestled snuggly in django.template.defaulttags.ForNode.render is a homebrewed native reverse implementation; aside from it using range when it should be using xrange, this is fine for <py2.4; for >=py2.4 however, the builtin reversed should be used (fair bit faster among other things). So... attached is a patch doing just that. adrian (removed)   0 1 0 0 0 0
4462 2007-06-02 12:23:51 2007-06-10 03:11:11 2019-06-24 01:02:38.411166 Ready for checkin closed Template system     master fixed minor ForNode.render reversed optimization short version, nestled snuggly in django.template.defaulttags.ForNode.render is a homebrewed native reverse implementation; aside from it using range when it should be using xrange, this is fine for <py2.4; for >=py2.4 however, the builtin reversed should be used (fair bit faster among other things). So... attached is a patch doing just that; for folks using >=2.4, it's a linear 10x boost (mass index lookups kill kittens when in combination with native py vs cpy speeds), so... worth adding. adrian (removed)   0 1 0 0 0 0
4506 2007-06-08 08:36:31 2007-06-24 12:38:11 2019-06-24 01:03:06.638437 Accepted closed Template system     master fixed regroup should rely on __eq__ instead of repr Tucked away in django.template.defaulttags.RegroupNode.render is this lil gem- {{{ for obj in obj_list: grouper = self.expression.resolve(obj, True) # TODO: Is this a sensible way to determine equality? if output and repr(output[-1]['grouper']) == repr(grouper): output[-1]['list'].append(obj) else: output.append({'grouper': grouper, 'list': [obj]}) }}} re: the TODO... the answer is 'no'. Aside from the fact it's forcing 2(n-1) repr when n repr would suffice, equality protocol exists exactly for usage in cases like this. The repr abusage there covers up a few things- 1) bad object implementations that have taken the time to flesh out repr, but not __eq__ which isn't really covering up. Tough cookies frankly (__eq__/__ne__ are simple methods to implement, and are needed elsewhere- hashing for example). 2) Objects that repr to the same, but have an __eq__ that says they differ. If __eq__ says it differs, it differs- using an alt equality method is dodging whatever reason the original author had for having __eq__ compare differently (exempting if they just didn't implement __eq__, which is scenario #1). Either way, the extra repr calls aren't needed- more importantly, repr should *not* be used there. So... counter args? adrian (removed)   0 1 1 0 0 0
4521 2007-06-10 12:51:46 2007-06-15 00:05:36 2019-06-24 01:03:16.679841 Ready for checkin closed Core (Other)     master wontfix signals should have __(str|repr)__ for debugging/maintenance. django.dispatch.dispatcher.An(y|onymous) singletons derive from a 'Parameter' class, basically providing a default __repr__, docstring. Useful for those signals, but should be generalized so that it's usable for other custom signals for any poor folks trying to yet again optimize dispatch :) Attached is a patch adding a custom _signal class; it's not required for creation of a specific signal to connect to, merely advisable- adds in __str__/__repr__ automatically (and docstring if supplied) making things a bit simpler for folks debugging. adrian (removed)   0 1 0 0 0 0
4523 2007-06-10 14:20:10 2007-06-17 01:31:12 2019-06-24 01:03:17.903321 Design decision needed closed Template system     master duplicate NodeList.render cleanup Tucked away in !NodeList.render is a fun little isinstance check, basically {{{ if isinstance(node, Node): bits.append(self.render_node(node, context)) else: bits.append(node) }}} With the render method being a hook method for derivative classes to intercept exceptions, and add some debugging info in; two limiting points to scaling there[[BR]] 1) Because !ForNode uses it to store strings, the isinstance is required- no other code uses it for this functionality, making me think !ForNode shouldn't be forcing !NodeList to do something odd, should do the job itself[[BR]] 2) Because !DebugNodeList overrides render_node, instead of render, an extra func call is involved for every node; again, single usage slows down the common usage. So... question is, why should !ForNode use it? Have yet to find any comments/explanation code wise, only thing I can *guess* is that someone was trying to extend !DebugNodeList.render_node behaviour down through a for; as said, this hurts the common case. Realize the first reaction is likely going to be another "micro-optimization is evil" comment; thing is, while it's not a huge gain like say removing dispatch.send invocations from Models.*, it's a constant waste occuring in any !NodeList.render (which are common enough). Usual usage scenario I'm abusing for testing pegs it as a constant 1.4s hit against trunk 64s (26s if using my misc patches sitting in tickets); might not seem like much, but it's yet another spot where it's spinning it's wheels without reason. So... why is !ForNode abusing !NodeList here? Oversight? Worth preserving? adrian (removed) performance 0 1 0 0 0 0
4561 2007-06-14 14:39:28 2008-08-06 15:32:46 2019-06-24 01:03:42.220750 Ready for checkin closed Core (Other)     master duplicate dispatch refactoring Original ml discussion is [http://groups.google.com/group/django-developers/browse_thread/thread/1491d45d193ed111 here]. Short version; dispatch is a slow beast- basic design flaws follow * signals are sent regardless of whether or not something is listening * every emit/send requires searching for any matching sender, and matching signal receiver- additionally, requires looking up Any. The listeners change only when a new connection is added/goes out of scope, doing it every time at send is inefficient * signals, while singleton instances, aren't used for anything more then effectively a constant; meaning all of the logic is shoved into dispatcher; due to this, there is no easy place to define the set of args sent to listeners, it's completely dependant on each send invocation using an adhoc agreed to standard. Due to a signal being just a constant, there is no easy space to make signals faster via calculating up front the receivers to notify (it could be implemented in dispatcher.*, but that code is already ugly/messy, and feels a bit fragile). Attached is a patch adding the basic intelligence to signals; this folds in ticket #4521 (basic signal class with __str__/__repr__). Roughly, adds the following logic: * for 'smart signals' (signals that are more then just constants), adds (enable|disable)_sender(sender) methods. In dispatcher.connect, if the signal is 'smart', signal.enable_sender(sender) is invoked- basically notifies the signal that something is actually listening, and what specifically is listening. In disconnect, a amtching disable_sender(sender) is added- same thing (notify that a receiver is going away). * Tracking of all known 'smart signals'; this is used by Any, to multiplex enable_sender calls down into each individual signal * a pre/post signal class, and func to generate the paired signals. This one is a bit more complex, and is the initial gain (aside from cleanup )from this refactoring. Basically, it modifies the sender on the fly, injecting pre/post dispatch… nobody (removed) performance 0 1 0 0 0 0
4563 2007-06-14 16:27:47 2007-12-02 23:57:23 2019-06-24 01:03:43.465033 Ready for checkin closed Template system     master fixed Context should expose removed/added scope objects (dicts) Originally suggested it [http://groups.google.com/group/django-developers/msg/987347b0da607839 in the 'ForNode multiple args' thread], but opening a ticket for it now since it's generally useful. Basically, proposing that Context.(push|update) return the newly added scope, and that Context.pop() returns the removed scope (for reasons of API symmetry mainly). The main reasoning behind this is that it's useful to bypass Context when doing more then setting a key or two- Context's api isn't as full featured as dicts (nor necessarily should it be). Right now, can do similar tricks via passing in the new scope to update, but that's not particularly friendly/obvious- alternative being reaching into the Context internal stack, which again, isn't very friendly (screws encapsulation anyways). Bypassing context for doing scope updates is actually fairly useful- very least, access to .clear() is a nice way to avoid continual pop/push on the stack per iteration. nobody (removed)   0 1 0 0 0 0
4565 2007-06-14 19:00:15 2007-07-14 09:45:53 2019-06-24 01:03:44.744057 Design decision needed closed Template system     master fixed template rendering should yield items, not concat strings at each level Given following template- {{{ {% for x in blah %} {% for y in x %} {% bunch o nodes %{ {% endfor %} {% endfor %} }}} The way the template rendering subsystem works, each 'bunch o nodes' is added onto a list w/in 'for y', then collapsed into a string, and returned to 'for x'; which builds up a list, collapses it down into into a string, and returns it. Problems follow: * wind up continually generating larger and larger strings as data is added on, percolating it's way up to the actual template.render. This isn't totally friendly to performance (specifically has a knack for forcing the alloc pool to expand repeatedly). * Data is already ready to be sent, but it's locked away in the template- basically, template rendering tries to build a final string of all contents- until that's finished nothing is sent * Said "final string of all content" means that django winds up being more memory hungry, pretty much without any reason. A backwards compatible solution is the introduction of an iter_render method to Node, that yields finalized chunks as they're available- this doesn't mean yielding each char as it's available, means (for a ForNode for example), yielding each chunk of data for iteration; via this approach, Template.iter_render has chunks of data percolate up as they're available, instead of just one big ass string at the end. Attached is a patch implementing iter_render, and converting existing tags/templates/involved codepaths over to iteration where sane; some node rendering still collapse internally (filter expressions primarily, although will be targeting those later). This patch includes the patch from ticket #4523 (isinstance usage there gets ugly when a lot of items are passing through it). Final other change worth noting- changes the base http so that it's no longer flushing after every single write during content dumping. Reason behind this should be fairly obvious- fine if you're writing a single item, sucks if you're writing a few hundred. One point of potent… adrian (removed) performance 0 0 0 0 0 0
4625 2007-06-19 19:53:16 2007-06-22 08:39:51 2019-06-24 01:04:23.496073 Unreviewed closed Template system     master fixed NodeBase metaclass check logic is faulty As hinted at on the ml, the NodeBase.__new__ code is a bit faulty- {{{ def __new__(cls, name, bases, attrs): """ Ensures that either a 'render' or 'render_iter' method is defined on any Node sub-class. This avoids potential infinite loops at runtime. """ if not (isinstance(attrs.get('render'), types.FunctionType) or isinstance(attrs.get('iter_render'), types.FunctionType)): raise TypeError('Unable to create Node subclass without either "render" or "iter_render" method.') return type.__new__(cls, name, bases, attrs) }}} Failings: 1) for code that has already broken the iter_render/render cycle, each derivative *still* has to assign a render/iter_render else it'll invalidly explode 2) no way to disable it (intermediate direct descendants from Node, say, adding helper functionality- they expect render/iter_render to be overriden, but the rules don't apply to them). Attached is a patch that converts the check over to verifying the resultant (as in, full MRO) render/iter_render, and adds an option to specifically disable the verification where needed. adrian (removed)   0 1 0 0 0 0
4779 2007-07-06 00:13:49 2011-10-09 12:44:57 2019-06-24 01:06:02.426832 Unreviewed closed Testing framework     master fixed typo in tests Willing to bet the commiter of this didn't win the spelling bee as a kid ;) Attached is a simple 3 line correction; basically tests are asserting Response == Reponse, simple typo. adrian (removed)   0 1 0 0 0 0
5106 2007-08-06 23:10:56 2007-08-20 03:40:18 2019-06-24 01:09:34.033858 Design decision needed closed Database layer (models, ORM)     master fixed django.db.backend.*.base refactoring Splitting connection pooling up into two patches; this particular ticket holds refactoring of django.db.backend.*.base.DatabaseWrapper classes to remove redundancy, and give an easier spot to control connection pooling. Very least, the misc backend implementation are a bit redundant- deriving from a common base class is a bit saner in this case for debugging and extension reasons. mtredinnick (removed)   0 1 0 0 0 0
9989 2009-01-08 09:57:31 2011-09-28 16:12:21 2019-06-24 02:03:34.499025 Accepted closed Core (Other)     1.0 fixed removal flaw in django.dispatch.Signal.disconnect Eyeballing cleanup in signals, spotted a bit of whackyness trying to cleanse a list via enumerate usage; presume the author tried removing from the list directory (which blows up since that invalidates the listiter) and came up w/ this instead. Flaw with it is that enumerate continues to increase the index even if you change the list under it's feet- in other words, you skip the item immediately following a deletion. One reason list comps are usually better in this case (although dependant on # of items and deletions of course). So... that should be using list.remove and catching ValueError where it doesn't exist. Quite a bit faster due to shifting comparison to cpy, and stopping the search after the first find. Clarifying the latter, a quick read of Signal.connect shows it disallows redundant connections to the same 'key'; meaning that the enumerate code in place right now is daft for continuing it's search for more to wipe- essentially a mismatch between connect/disconnect (guessing it crept in when someone tweaking signal.connect to disallow redundant registrations). basically convert {{{ for idx, (r_key, _) in self.receivers: if r_key == lookup_key: del self.receives[idx] }}} into {{{ try: self.receivers.remove(lookup_key) except ValueError: pass }}} 'nuff said. nobody (removed)   0 0 0 0 0 0
16763 2011-09-08 00:25:25 2011-12-02 16:41:11 2019-06-24 03:17:10.234472 Accepted closed *.djangoproject.com Bug Normal   fixed code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc) As the summary says, I've long since moved on from django; this includes de-cc'ing myself basically every where I could find. That said, code.djangoproject.com persists in emailing me. Examples being #17, #3544, #4102, #3529. Basically anywhere I've commented- I get notification. If I uploaded a patch, I get notification. If I cc'd myself, than de-cc'd myself, I get mail. Further kicker is the stupid thing is bound to my email address rather than my user account (hell if I know why), so it's not even picking up my account's email being set to noreply@djangoproject.com (yep, that's rude, but it's been pissing me off for a while now). I'd be significantly less annoyed if it were just emailing me for tickets I've filed (bugzilla behaviour), but this is /not/ the behaviour I've observed; as said, check the tickets, none of them have me cc'd, couple of them the only thing I ever did was cc myself, than remove it later on. Still I get mail. Kindly sort it or point out exactly how I'm being stupid and could suppress this myself (procmail wiping it on my side does not fly- I'd sooner set a forward than go that route). nobody (removed)   0 0 0 0 0 0
28407 2017-07-18 07:22:42 2018-03-12 18:13:02 2019-06-24 05:40:39.306247 Accepted closed Database layer (models, ORM) New feature Normal 1.11 duplicate Allow inspectdb to introspect db column comments when use inspectdb make model from db. the db column is created by dba, not developer . so db column comments set to models Field is helpful for developer. like {{{ field = models.IntegerField(blank=True, null=True) #comments in db }}} [https://github.com/django/django/pull/8770] nobody 007gzs db comment 0 1 0 1 0 0
10003 2009-01-09 22:59:23 2009-01-09 23:31:34 2019-06-24 02:03:43.379278 Unreviewed closed Template system     1.0 invalid if and extends in template {{{ {% if mobile %} {% extends 'base_mobile.html' %} {% else %} {% extends 'base_normal.html' %} {% endif %} }}} Throws following exception: {{{ Exception Type: TemplateSyntaxError Exception Value: Invalid block tag: 'else' Exception Location: /home/dsduser/django-synble/django/template/__init__.py in invalid_block_tag, line 333 }}} I think this should be supported. Second option is to write include correctly so that include does not broke inheritance. E.g.: basbase.html: has block base.html: include "basebase.html" logic.html: extends "base.html", inheritance of basbase.html block does not work here anymore. nobody 0ptr   0 0 0 0 0 0
29751 2018-09-12 05:51:23 2018-09-12 16:54:12 2019-06-24 05:55:19.569638 Unreviewed closed Migrations Bug Normal 1.11 duplicate Saving deserialized objects in custom migration fails in certain cases Saving deserialised objects in custom migration fails in certain cases (model has new fields added since) because `_get_model` used [[https://github.com/django/django/blob/b9cf764be62e77b4777b3a75ec256f6209a57671/django/core/serializers/python.py#L91|here]] uses the latest version of the model (rather than the migration-specific model, which is derived using `apps.get_model` where `apps` is the first argument passed to a custom migration function - which is passed to `migrations.RunPython`) Fix here would be to pass the `apps` received as first argument in a custom migration via the `**options` in `deserialize()` 0xKD 0xKD serialize,deserialize,migration 0 0 0 0 0 0
13180 2010-03-23 03:07:13 2010-03-23 11:15:00 2019-06-24 02:38:18.721113 Unreviewed closed Template system     1.1 worksforme html template links broken the problem isn't with the python code, it's with the html templates. I have a site that checks if someone is logged in and if not provides the following link: "/accounts/login". Everything is works until I press the login link. nothing happens. The url at the top of the screen changes and even if you try to refresh after the url has changed nothing happens. The source is fine: I checked it. I would think this problem was my fault, but when you type in "/accounts/login" yourself it works fine. Because of this I assume he problem is rooted in the HTML and template system. nobody 114fc69b8e6e93c0447be8de link href html broken 0 0 0 0 0 0
20106 2013-03-21 12:17:37 2013-03-21 12:53:45 2019-06-24 03:53:14.446113 Unreviewed closed Python 3 Cleanup/optimization Normal 1.5 invalid A little optimazon--"0 errors found" When I ran "python manage.py validate", it gave me "0 errors found". I think it should be "0 error found". Thanks. nobody 1458409827@qq.com   1 0 0 0 0 1
20259 2013-04-14 13:36:21 2013-04-15 12:08:09 2019-06-24 03:54:52.936865 Unreviewed closed Documentation Cleanup/optimization Normal 1.5 invalid Syntax Error in the Document I found a mistake in the document(http://media.readthedocs.org/pdf/django/1.5.x/django.pdf), on page 486: "but in views written by hand you’ll need to explicitly use RequestContext To see how that works, and to read more details, check out Subclassing Context: RequestContext.", I think there should be a dot after "use RequestContext". Thanks. nobody 1458409827@qq.com   1 0 0 0 0 1
28165 2017-05-03 10:10:23 2017-06-07 21:09:08 2019-06-24 05:20:52.705116 Accepted closed File uploads/storage Bug Normal 1.11 fixed FileExtensionValidator's allowed_extensions must be given in lower case Using any uppercase character for an 'allowed_extension' prevents it from being matched. Because the input filename is being lowered before comparison to the extensions. Here is an example: {{{ #!python from django.core.validators import FileExtensionValidator from collections import namedtuple valid = FileExtensionValidator(['pdf', 'png']) File = namedtuple('File', ['name']) # valid: different case in file name named_file = File(name='myfile.PDF') valid(named_file) named_file = File(name='myfile.PdF') valid(named_file) # using uppercase in validator valid = FileExtensionValidator(['PDF', 'PNG']) # invalid: everything, because the case of the input is lowered named_file = File(name='myfile.PDF') valid(named_file) # ValidationError: ["File extension 'pdf' is not allowed. Allowed extensions are: 'PDF, PNG'."] named_file = File(name='myfile.pdf') valid(named_file) # ValidationError: ["File extension 'pdf' is not allowed. Allowed extensions are: 'PDF, PNG'."] }}} nobody 153957 validators filefield 0 1 0 0 0 0
27619 2016-12-21 09:01:28 2016-12-21 12:49:23 2019-06-24 05:14:59.911334 Unreviewed closed Database layer (models, ORM) Bug Normal 1.10 duplicate Queries where column name includes a '%' character break when using MySQL Sorry about this nonsense, but... I have a table in MySQL with a column name '%exp'. I know this is a poor choice for a column name. When calling the objects.all(), I was getting a rather frustrating error message from pyMySQL, "not enough arguments for format string." I couldn't figure out what was causing it until I printed result of calling QuerySet.Query.sql_with_params() on the resulting QuerySet. I saw that there were no params, but the string contained %e, which python interpreted as trying to format the string. nobody 16zzundel5   1 0 0 0 0 0
26943 2016-07-23 17:27:58 2016-07-25 00:32:14 2019-06-24 05:07:37.820931 Unreviewed closed Documentation Uncategorized Normal   invalid Link with BooleanField explanation not available I just an old project to updated to django 1.7 and happened to get this link: HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information. But this link is dead. Where can I find the information? nobody 1kastner   0 0 0 0 0 0
24467 2015-03-10 16:51:09 2015-03-12 00:19:12 2019-06-24 04:40:32.486295 Ready for checkin closed contrib.admin Bug Normal master fixed jQuery error in Django admin site when use "get_prepopulated_fields" I have Django ModelAdmin for Blog model. {{{ class BlogAdmin(BaseModelAdmin): fieldsets = [ (None, {'fields': ['name', 'description', 'slug']}), ('Date information', {'fields': ['date_create', 'date_change']}), ] # NOTE: this work well # prepopulated_fields = {"slug": ("name",)} def get_readonly_fields(self, requets, obj=None): """ Disable edit slug field for object. """ if obj: return self.readonly_fields + ('slug',) return self.readonly_fields def get_prepopulated_fields(self, requets, obj=None): """ Prepopulate slug field only for new object. In out case we always return value that I mentioned above for "prepopulated_fields". """ return {"slug": ("name",)} admin.site.register(Blog, BlogAdmin) }}} '''What do I do?''' I try to show prepopulate field ONLY on create new object page. When we edit this object - I disable option to edit slug field and show it as read-only. When I use "prepopulated_fields" all work as expected. When I switch to use custom method "get_prepopulated_fields" the jQuery error appear in web browser console: {{{ TypeError: undefined is not a function (evaluating '$(field.id).data('dependency_list', field['dependency_list']) .prepopulate(field['dependency_ids'], field.maxLength)') }}} As I found - the error appear because it's not defined "prepopulate" function: {{{ >>> django.jQuery("#id_slug").prepopulate undefined }}} Who knows how to fix this? nobody 1st   0 1 0 0 0 0
25198 2015-07-30 16:07:59 2015-08-07 11:04:50 2019-06-24 04:48:35.264028 Unreviewed closed Core (Serialization) Uncategorized Normal master needsinfo Django's model_to_dict should return ALL fields, including hidden Hello. I found that Django return only editable fields in call of `model_to_dict`. I wish to have an option `include_hidden=True` to get list of ALL fields including not editable ones. I will make this fix and tell you about fix. nobody 1st model serialization 0 0 0 0 0 0
20829 2013-07-30 14:57:34 2013-08-16 19:23:12 2019-06-24 04:01:01.287435 Accepted closed GIS Bug Normal 1.5 fixed Geodjango and PostGIS Exception Error I have connected an existing POSTGIS database and when I run inspectdb I get Exception: Could not find a geometry or geography column for "raster_columns"."extent" nobody 2059016j@student.gla.ac.uk   0 1 1 1 0 0
21531 2013-11-29 13:48:45 2013-12-31 11:38:15 2019-06-24 04:08:38.276153 Accepted closed Forms Bug Normal 1.6 invalid Django 1.6 forms.SlugField validation error Hi, I have a problem with SlugField. In my model I have this field: slug = models.SlugField(_(u'Slug'), blank=True, null=True) Adding an item through admin, django catches this error: Django Version: 1.6 Exception Type: AttributeError Exception Value: 'NoneType' object has no attribute 'strip' Exception Location: myvirtualenv/lib/python2.7/site-packages/django/forms/fields.py in clean, line 1142 Is this a bug or my fault? I tried the same code with django 1.5.5 and it works. Thanks nobody 20tab   0 0 0 0 0 0
2582 2006-08-21 21:23:03 2006-08-22 17:45:22 2019-06-24 00:42:42.950897 Unreviewed closed contrib.admin defect normal master fixed verbose_name can't contain quote (' ") symbols seems that ''/media/js/SelectFilter2.js'' contain some bug, that doesn't give us ability to use quotes in verbose_name. When we define verbose_name (in ManyToMany field) as {{{ verbose_name = ' "Read also" block ' }}} classic field view in admin pannel defined by {{{ filter_interface=models.HORIZONTAL }}} brokes just to one many-select HTML field. adrian 235 verbose_name 0 0 0 0 0 0
2583 2006-08-21 21:35:44 2009-11-06 16:39:03 2019-06-24 00:42:43.591128 Unreviewed closed contrib.admin defect normal master worksforme can't use ForeignKey in list view (class Admin: list_display) If we'll use next code: {{{ class Articles(models.Model): .... author = models.ForeignKey(Authors, blank=True, null=True, verbose_name='Автор статьи') #models.CharField('Автор статьи', maxlength=100, blank=True) .... class Admin: list_display = ('pub_date', ... 'author') }}} The list view of objects will be broken in header - there would be no header for this ForeignKey. In ''django/contrib/admin/templates/admin/change_list_result.html'' defined: {{{ <th{{ header.class_attrib }}> }}} and actualy it renders into (with ''TEMPLATE_STRING_IF_INVALID = "TEMPLATE_STRING_IF_INVALID"'' in settings.py): {{{ <thTEMPLATE_STRING_IF_INVALID> }}} ForeignKey field lacks this attribute nobody 235   0 0 0 0 0 0
2584 2006-08-21 21:49:40 2007-01-30 22:03:59 2019-06-24 00:42:44.221745 Unreviewed closed Database layer (models, ORM) defect normal master worksforme no MySQL codepage select Django works '''only''' with utf8 codepage in MySQL, it's great problem with using it in others codepages. In ''django/db/backends/mysql/base.py'' hardcode defined MySQL codepage. {{{ if self.connection.get_server_info() >= '4.1': cursor.execute("SET NAMES utf8") }}} There only one possibility to change it manualy. Other variant is to move this option out to ''settings.py'' as MYSQL_CODEPAGE or try to extract this data from DEFAULT_CHARSET, as it was recommended on local forum: {{{ from django.config import settings ... if self.connection.get_server_info() >= '4.1': cs = settings.DEFAULT_CHARSET.replace('-', '') cursor.execute("set character set %s" % cs) }}} adrian 235   0 0 0 0 0 0
11270 2009-06-06 08:30:14 2011-09-28 16:12:21 2019-06-24 02:17:28.803505 Accepted closed Core (Cache system)     master fixed Cache templatetag with memcached can't handle long tags similar to #10016 Memcached has a hard limit of 250 characters for cache keys. So we have to use md5 hash instead of the whole cached tag name with all vary variables. {{{ Traceback (most recent call last): File "/var/www/virtual/sumno.com/modules/django/core/handlers/base.py", line 86, in get_response response = callback(request, *callback_args, **callback_kwargs) File "/var/www/virtual/sumno.com/htdocs/sumnocom/apps/lib/decorators.py", line 56, in wrapper return func(request, *args, **kwargs) File "/var/www/virtual/sumno.com/htdocs/sumnocom/../sumnocom/apps/generic_content/views.py", line 370, in detail_view_content_entry context_instance=RequestContext(request)) File "/var/www/virtual/sumno.com/modules/django/shortcuts/__init__.py", line 18, in render_to_response return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "/var/www/virtual/sumno.com/modules/django/template/loader.py", line 107, in render_to_string return t.render(context_instance) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 768, in render bits.append(self.render_node(node, context)) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 781, in render_node return node.render(context) File "/var/www/virtual/sumno.com/modules/django/template/loader_tags.py", line 97, in render return compiled_parent.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 768, in render bits.append(self.render_node(node, context)) File "/var/www/virtual/sumno.com/modules/django/template/__init__.py", line 781, in render_node return node.render(context) File "/var/w… nobody 235   0 1 0 1 0 0
12425 2009-12-22 17:21:39 2011-09-28 16:12:23 2019-06-24 02:29:58.921775 Unreviewed closed Translations     1.1 fixed Typo in the Ukrainian translation really nasty typo in variable name in message translation: in django/conf/locale/uk/LC_MESSAGES/django.po 'min' variable in message was replaced by 'max' that that was causing server error 500: {{{ File "/var/www/virtual/sumno.com/modules/django/forms/fields.py", line 155, in clean    raise ValidationError(self.error_messages['min_length'] % {'min': self.min_length, 'length': value_length})  File "/var/www/virtual/sumno.com/modules/django/utils/functional.py", line 222, in __mod__    return unicode(self) % rhs KeyError: u'max' }}} jezdez 235   0 1 0 0 0 0
25252 2015-08-09 20:48:32 2015-08-31 05:15:58 2019-06-24 04:49:10.307951 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal 1.8 fixed Add a friendly error message when using Queryset.select_related() after values() Trying to use a queryset while using both methods 'values' and 'select_related' will throw an error when trying to use iter. models: {{{ class Poll(models.Model): name = models.CharField(max_length=50L) class Entry(models.Model): poll = models.ForeignKey(Poll) name = models.CharField(max_length=50L) }}} code: {{{ >>> iter(Entry.objects.values('name').select_related('poll')) }}} error: {{{ Traceback (most recent call last): File "<console>", line 1, in <module> File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 162, in __iter__ self._fetch_all() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 965, in _fetch_all self._result_cache = list(self.iterator()) File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/query.py", line 1085, in iterator for row in self.query.get_compiler(self.db).results_iter(): File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 794, in results_iter results = self.execute_sql(MULTI) File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 829, in execute_sql sql, params = self.as_sql() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 378, in as_sql extra_select, order_by, group_by = self.pre_sql_setup() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 48, in pre_sql_setup self.setup_query() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 39, in setup_query self.select, self.klass_info, self.annotation_col_map = self.get_select() File "/*path_to_project*/env/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 207, in get_select klass_info['related_klass_infos'] = related_klass_infos TypeErr… Y3K 2roy999 queryset values select_related 1 0 0 0 0 0
24911 2015-06-03 23:09:38 2015-06-30 17:54:11 2019-06-24 04:45:29.156214 Accepted closed Database layer (models, ORM) Bug Normal 1.8 fixed QuerySet is initiated with model=None as kwarg, but is called in BaseManager.get_queryset() as arg. QuerySet is initiated with {{{model=None}}} as named argument a.k.a. kwarg: {{{ class QuerySet(object): def __init__(self, model=None, query=None, using=None, hints=None): }}} But it is called in {{{get_queryset()}}} as positional argument a.k.a. arg: {{{ def get_queryset(self): return self._queryset_class(self.model, using=self._db, hints=self._hints) }}} This causes trouble when overriding {{{get_queryset}}} (which is the idea behind the method) and using {{{super(BlaBlaManager, self).get_queryset()}}} which returns a non-standard queryset-class, where model is not necessarily the first argument, which should have been okay as model is a named argument. Proposed solution: in db/models/manager.py {{{ def get_queryset(self): return self._queryset_class(model=self.model, using=self._db, hints=self._hints) }}} Github pull request: https://github.com/django/django/pull/4745 317070 317070   1 1 0 0 0 0
19193 2012-10-26 17:39:02 2015-10-08 23:41:31 2019-06-24 03:43:24.580876 Accepted closed Database layer (models, ORM) New feature Normal master duplicate Save only one field to database which refereced to FieldFile `django.db.models.fields.FieldFile`: {{{ def save(self, name, content, save=True): .... if save: self.instance.save(update_fields=[self.field.name]) .... }}} or: {{{ def save(self, name, content, save=True, **kwargs) .... if save: self.instance.save(**kwargs) .... }}} So, we get rid of re-saving fields when updating nobody 3dflex@gmail.com   0 0 0 0 0 0
11179 2009-05-22 12:53:56 2009-08-08 20:40:56 2019-06-24 02:16:31.195304 Unreviewed closed django-admin.py inspectdb     1.0 wontfix inspectdb should guess related_name on foreign keys It would be useful if inspectdb would guess related_name parameter on foreign keys using db_table, db_column and othermodel attributes. >> Accessor for field 'xxx' clashes with related field 'YYY.zzz_set'. Add a related_name argument to the definition for 'xxx'. >> Accessor for field 'aaa' clashes with related field 'YYY.zzz_set'. Add a related_name argument to the definition for 'aaa'. Thnx nobody 3gun related_name 0 0 0 0 0 0
12460 2009-12-29 14:18:11 2012-08-23 19:47:35 2019-06-24 02:30:21.397575 Accepted closed Core (Management commands) Bug Normal master fixed inspectdb and field names ending with underscores Hi, There is a field named 'type_' in mysql table. Inspectdb inspects it as 'type_' and model does not validate. I suggest removing underscores from model field name and specifying column_db argument in field constructor. < type_ = models.CharField(max_length=90, db_column='type_') > type = models.CharField(max_length=90, db_column='type_') Sorry for posting without login. I've forgot my password and didn't find restoring feature on this site. kgibula 3gun <mihail.lukin@googlemail.com> inspectdb underscore characters digits 0 1 0 0 0 0
13459 2010-05-02 11:53:36 2011-09-28 16:12:23 2019-06-24 02:41:19.012351 Accepted closed contrib.admin     master fixed nonzero extra inlines and "add another" create duplicate <tr> ids The first new row of an admin inline created by the "add another" button has the same id as the immediately preceding "extra" row. An admin model that contains an inline with the "extra" option set to a non zero value creates <tr>s with id suffixes starting from 1. When the !JavaScript "add another" function is called, it creates id suffixes assuming that the first row id was numbered 0. This may have been a side effect of fixing #13175. Using forloop.counter0 in the inline templates when generating the extra inlines solves the problem. nobody 3point2   0 1 0 0 0 0
13679 2010-06-01 23:29:29 2011-09-28 16:12:27 2019-06-24 02:43:40.282066 Accepted closed Forms     1.2 fixed ModelForms (and hence the admin) no longer honor the default value for a ForeignKey In Django 1.1, it was possible to use a callable to set the default value on a !ForeignKey field. This functionality was broken in r12721 and doesn't currently work in Django 1.2. Example: {{{ def get_default(): return SomeModel.objects.get(id=5) class Test(models.Model): foo = models.ForeignKey(SomeModel, default=get_default) }}} This model should display in the admin with the default !SomeModel already selected in the drop-down box. The !ModelForm code that does this seems to have been confused by the changes made in r12721. The code in the Field class in django/db/models/fields/!__init!__.py could also do with a cleanup: formfield() first checks has_default() before calling get_default(), which also checks has_default(). The patch in r12721 adds to this duplication of logic by checking if self.default is callable, which is also done by get_default(). nobody 3point2   0 0 0 0 0 0
13950 2010-07-16 02:32:14 2012-03-25 21:01:24 2019-06-24 02:46:42.778151 Unreviewed closed contrib.admin Uncategorized Normal 1.2 wontfix Add "post save" hook to ModelAdmin class If a model with a set of related objects is edited in the admin, there is currently no way to run any code once the admin site has saved the related objects. For example, consider an invoice: models.py: {{{ class Invoice(models.Model): # fields like customer_name, etc total = models.DecimalField(max_digits=11, decimal_places=2) def update_total(self): self.total = sum([x.cost for x in self.invoiceentry_set.all()] class InvoiceEntry(models.Model): invoice = models.ForeignKey(Invoice) item = models.CharField(max_length=100) cost = models.DecimalField(max_digits=11, decimal_places=2) # etc }}} When clicking "save" in the admin after editing or adding an invoice in the admin interface, there is no way to have the invoice update its total using the update_total method. Overriding the save() method on the Invoice model doesn't help, because it is called before the related !InvoiceEntries are created and saved. I supposes the functionality I want could be implemented by overriding the save() method for the !InvoiceEntry model and have it update the total of the parent instance, although this seems a little inelegant as the Invoice instance would then be updated and saved once for every invoice entry created or edited. I suggest adding a "post_save" option to the !ModelAdmin class, which will be called once all related objects have been saved. Please consider the attached patch. It allows the following: admin.py: {{{ class InvoiceAdmin(admin.ModelAdmin): def post_save(self, instance): instance.update_total() admin.site.register(Invoice, InvoiceAdmin) }}} With the patch, the post_save method above is called after the invoice and all its related entries have been created and saved. If this is considered for inclusion into Django, I'd be happy to modify the patch to include documentation. Vasili pandres 3point2   0 1 1 1 1 0
14038 2010-07-31 00:24:17 2011-01-25 15:44:42 2019-06-24 02:47:38.744090 Accepted closed Documentation     1.2 fixed 1.2 Release notes don't mention new template loader classes As of 1.2, template loaders like django.template.loaders.filesystem.load_template_source have been deprecated in favor of django.template.loaders.filesystem.Loader. This is not mentioned in the release notes, but other deprecated settings (like DATABASE_*) are. nobody 3point2   0 0 0 0 1 0
14172 2010-08-26 11:00:09 2010-08-26 11:10:46 2019-06-24 02:49:04.574091 Unreviewed closed Documentation     1.2 fixed small typo in admin action docs this is a little nit-picky i know, but 'explicitally' under "disabling a site-wide action' should be 'explicitly' (http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#django.contrib.admin.AdminSite.disable_action) nobody 3point2   0 0 0 0 0 0
15536 2011-03-03 00:18:00 2013-04-19 03:56:25 2019-06-24 03:03:47.790399 Accepted closed Forms Uncategorized Normal 1.4 invalid ModelForm validation regression in 1.2 when using TimeField with choices This is my test case models.py: {{{ from django.db import models from django import forms TIME_CHOICES = ( ("09:00:00", "9 AM"), ("17:00:00", "5 PM") ) class TestModel(models.Model): time = models.TimeField(choices=TIME_CHOICES) class TestForm(forms.ModelForm): class Meta: model = TestModel }}} This is what happens with Django 1.1.4: {{{ >>> f = TestForm({"time": "09:00:00"}) >>> f.errors {} }}} and this is what happens with Django 1.2.5: {{{ >>> f = TestForm({"time": "09:00:00"}) >>> f.errors {'time': [u'Value datetime.time(9, 0) is not a valid choice.']} }}} It looks like in 1.2 the supplied time is being converted into a datetime instance before being compared to the valid choices. It would be great to see this incompatible change from 1.1 fixed or documented. nobody 3point2 blocker, regression 0 0 0 0 0 0
17984 2012-03-26 15:08:24 2013-03-23 10:21:48 2019-06-24 03:30:23.868572 Design decision needed closed contrib.admin Bug Normal 1.4 wontfix admin list_filter security fix doesn't allow 'pk' lookups in query string Let's say I have a Payment model containing a received_by field that is a !ForeignKey to a Customer model. Now I add this to my Payment !ModelAdmin: {{{ list_filter = ["received_by"] }}} If I use a query string like "?received_by!__id!__exact=2" on the payment changelist view, there is no problem. This is the form that the admin itself uses for the filter. Using something more implicit like "?received_by!__id=2" works fine too. However, using "?received_by!__pk=2" raises !SuspiciousOperation. This was introduced by the security fix in r15031. The lookup_allowed method in admin/options.py explicitly makes an exception for "!__id" (or whatever the primary key attribute of the model is explicitly called), but it doesn't allow direct use of the 'pk' shortcut. The point of the security fix was to only allow lookups specified by list_filter. However, in its current form it also causes the query string syntax to diverge from the documented lookup syntax https://docs.djangoproject.com/en/1.4/topics/db/queries/#the-pk-lookup-shortcut . I suggest allowing use of the pk shortcut in the query string. I would be happy to write a patch for this if the developers agree it should be fixed. nobody 3point2   0 0 0 0 0 0
17985 2012-03-26 15:16:24 2017-09-02 18:10:06 2019-06-24 03:30:24.531588 Accepted closed Documentation New feature Normal 1.4 fixed Document ModelAdmin.lookup_allowed() Right now, as a result of the security fix introduced in r15031, the only way to allow querystring lookups across relationships in the admin is to whitelist them by including them in list_filter. However, in my application the lookup that needs to be whitelisted generates a huge filter widget as it contains thousands of instances. It would be helpful if I could whitelist the exact lookup I need to link to without having to generate the filter widget itself. Something like {{{ class MyModelAdmin(ModelAdmin): allow_lookup = ["fieldname__id__exact"] }}} would do. If the developers agree this is useful functionality, I could write a patch. DrMeers 3point2   0 1 0 0 0 0
23704 2014-10-22 19:54:31 2014-10-23 18:57:55 2019-06-24 04:32:14.712776 Unreviewed closed Uncategorized Bug Normal 1.7 invalid Error in manage.py runserver on Windows (7 / 8 / 8.1) I've added the 3 versions mentioned in the summary because while searching for a solution to this bug I've found that it occurred in those ones also. == Technical Specs == System: Windows 8.1 Python: 3.4 Django: 1.7 Virtual Enviroment: 2.7 == Explanation of the bug == After creating my project with "manage.py startproject" I tried to check if it was created correctly by running the local server. When I tried to do so with "manage.py runserver" a command feedback appeared reporting the next error: [[Image(http://s21.postimg.org/e362aaql3/traceback_error.png)]] In line 279, the code indicated that it was a problem with the encoding of a character. For what I know 'mbcs' codec is only used with Windows machines. I tried all suggestions in StackOverflow and the likes with no improvement. Then I started digging in the code and I found the file with the error "autoreload.py": [[Image(http://s21.postimg.org/5v44payon/autoreload_before.png)]] The problem occurred with the method "os.spawnve" that executes the program path in a new process. The real usage is beyond my knowledge. I decided to look up the arguments that were given to this function and printed each one of them to see what was happening. The arguments "sys.executable" & "args" didn't present any errors. It was a clean print. "new_environ", that's another story. It presented a new error indicating that a Unicode value (\u202a) couldn't be decoded by the function charmap. I searched this particular Unicode and it's used for indicating '''directional embedding''' (more of this at: [http://unicode.org/reports/tr9/#Directional_Formatting_Codes]). It appears that this particular Unicode character isn't supported in Windows, that includes the 3 versions indicated in the summary. It so strange to Windows environment that even if you try to search the code in a browser it can't recognized it: [[Image(http://s21.postimg.org/ucw8d7193/path_key.png)]] After that I tried to print each key with … nobody 3rdWorldCitizen Windows runserver 0 0 0 0 0 0
30104 2019-01-15 10:14:39 2019-01-15 15:51:09 2019-06-24 05:59:11.292188 Unreviewed closed Database layer (models, ORM) Uncategorized Normal 2.1 invalid Need filtering by Window expression I use Row_Number function with WIndow expression. And i need to filter only second rows. {{{ History.objects.annotate(row=Window(expression=RowNumber(), partition_by=[F('ad_id')], order_by=F('updated_at').desc())).filter(row=2) }}} But this exception raised: {{{ django.db.utils.NotSupportedError: Window is disallowed in the filter clause. }}} Why Window is disallowed in the filter clause? Is there other way to do this? nobody 3wade3 orm, window, row_number, filter 1 0 0 0 0 0
24250 2015-01-30 10:22:57 2015-02-03 14:10:30 2019-06-24 04:38:11.665535 Ready for checkin closed Documentation Bug Normal 1.7 fixed Class FormMixin does not provide "form" variable in centext. Class FormMixin does not provide "form" variable in centext. Documentation states that it should https://docs.djangoproject.com/en/1.7/ref/class-based-views/mixins-editing/#formmixin nobody 4544fa8d FormMixin form context 0 1 0 0 0 0
23715 2014-10-26 07:48:09 2014-10-31 12:07:44 2019-06-24 04:32:21.862967 Ready for checkin closed Template system Bug Normal 1.7 fixed Template tag urlize and exclamation mark The template tag `urlize` cannot create the urls correctly when an exclamation mark follows an url. text = "Check out www.djangoproject.com!" text|urlize results in: "Check out <a href="(...)!">www.djangoproject.com!</a>" MarkusH 57even   0 1 0 0 0 0
20217 2013-04-08 08:26:24 2013-04-08 22:56:01 2019-06-24 03:54:25.946079 Unreviewed closed Database layer (models, ORM) Bug Normal 1.3 invalid query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10 class User(models.Model): identifier=models.CharField(max_length=128, unique=True, db_index=True) .......... .......... class Token(models.Model): user = models.ForeignKey("User", related_name="Tokens") token_string = models.CharField(max_length=128, unique=True, db_index=True) while I already have a tk(<Token object>),I run this: user = User.objects.filter(id=tk.user_id) if user: user = user[0] it cause the ValueError: invalid literal for int() with base 10: File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 113, in __nonzero__ iter(self).next() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter self._fill_cache() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 772, in _fill_cache self._result_cache.append(self._iter.next()) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator for row in compiler.results_iter(): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter for rows in self.execute_sql(MULTI): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 86, in execute return self.cursor.execute(query, args) File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue ValueError: invalid literal for int() with base 10: '\xd9' but it disappeared when I restart my project, but a couple of days while running, it occured again How does it happened and any solutions? nobody 592280502@qq.com   0 0 0 0 0 0
20225 2013-04-09 01:47:11 2013-04-09 01:52:53 2019-06-24 03:54:31.076619 Unreviewed closed *.djangoproject.com Bug Normal 1.3 needsinfo query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10 class User(models.Model): identifier=models.CharField(max_length=128, unique=True, db_index=True) .......... .......... class Token(models.Model): user = models.ForeignKey("User", related_name="Tokens") token_string = models.CharField(max_length=128, unique=True, db_index=True) while I already have a tk(<Token object>),I run this: user = User.objects.filter(id=tk.user_id) if user: user = user[0] it cause the ValueError: invalid literal for int() with base 10: File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 113, in nonzero iter(self).next() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter self._fill_cache() File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 772, in _fill_cache self._result_cache.append(self._iter.next()) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator for row in compiler.results_iter(): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter for rows in self.execute_sql(MULTI): File "/usr/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 86, in execute return self.cursor.execute(query, args) File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute self.errorhandler(self, exc, value) File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue ValueError: invalid literal for int() with base 10: '\xd9' but it disappeared when I restart my project, but a couple of days while running, it occured again How does it happened and any solutions? nobody 592280502@qq.com ValueError 0 0 0 0 0 0
26414 2016-03-27 16:57:05 2016-03-27 17:12:02 2019-06-24 05:01:49.834771 Unreviewed closed contrib.postgres Bug Normal 1.9 duplicate postgres_test fail with psycopg2==2.4.5 {{{#!bash $ pip freeze |grep psycopg2 psycopg2==2.4.5 $ PYTHONPATH=..:$PYTHONPATH ./runtests.py postgres_tests Traceback (most recent call last): File "./runtests.py", line 458, in <module> options.debug_sql, options.parallel) File "./runtests.py", line 275, in django_tests extra_tests=extra_tests, File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 532, in run_tests old_config = self.setup_databases() File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 482, in setup_databases self.parallel, **kwargs File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/test/runner.py", line 726, in setup_databases serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE", True), File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 78, in create_test_db self.connection._test_serialized_contents = self.serialize_db_to_string() File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 122, in serialize_db_to_string serializers.serialize("json", get_objects(), indent=None, stream=out) File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/core/serializers/__init__.py", line 129, in serialize s.serialize(queryset, **options) File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/core/serializers/base.py", line 79, in serialize for count, obj in enumerate(queryset, start=1): File "/home/user/dev/env/django-1.9.3/local/lib/python2.7/site-packages/Django-1.9.3-py2.7.egg/django/db/backends/base/creation.py", line 118, in get_objects for obj in queryset.iterator(): File "/home/user/dev/env/django-1…   612d7368   0 1 0 0 0 0
21408 2013-11-08 21:22:05 2018-09-29 13:07:45 2019-06-24 04:07:19.521492 Ready for checkin closed Internationalization Bug Normal master fixed Fallback to timesince produces erroneous translations in naturaltime The [[https://docs.djangoproject.com/en/dev/ref/contrib/humanize/#naturaltime|naturaltime]] filter in `django.contrib.humanize` composes strings for days, weeks, months, and years from the words "ago" and "in" and the output of the built-in [[https://docs.djangoproject.com/en/dev/ref/templates/builtins/#timesince|timesince]] filter. See here, where `delta` is to be supplied by `timesince`: {{{ #: templatetags/humanize.py:190 #, python-format msgctxt "naturaltime" msgid "%(delta)s ago" msgstr "vor %(delta)s" }}} This produces erroneous translations in German (and probably other inflectional languages, too). "3 days, 12 hours ago" is translated by Django as {{{ vor 3 Tage, 12 Stunden }}} but the correct translation is (with dative inflection) {{{ vor 3 Tagen, 12 Stunden }}} "3 Tage" is correct for `timesince`, but for `naturaltime` it must become "3 Tagen". Unfortunately, the assumption that these translations can simply be pieced together from translated bits in timesince.py is mistaken. I apologise if this isn't the right channel. I'd be glad to help, but so far I haven't seen a good way to avoid duplicating translations. mxmerz 676c7473@gmail.com i18n l10n translation 0 1 0 0 0 0
21415 2013-11-09 18:15:52 2017-07-05 06:41:48 2019-06-24 04:07:24.123506 Accepted closed Translations Bug Release blocker 1.6 fixed Unicode escapes appear verbatim in translated naturaltime strings In Django 1.6, the Unicode escape `\u00a0` "non-breaking space" that was introduced in the translations is doubly-escaped and now appears verbatim in the output of `django.contrib.humanize.naturaltime`. What used to be {{{ vor 6 Sekunden }}} that is the German ("de") translation for "6 seconds ago", now appears as {{{ vor 6\u00a0Sekunden }}} in templates that use `naturaltime`. This affects all `django/contrib/humanize/locale/<language>/LC_MESSAGES/django.po` files. Not sure if this should be treated as a translation bug, and how? claudep 676c7473@gmail.com i18n l10n translation 0 1 0 0 0 0
17859 2012-03-09 03:02:55 2012-03-09 03:32:32 2019-06-24 03:29:03.362874 Unreviewed closed Uncategorized Uncategorized Normal 1.3 needsinfo Undefined variable from import: cursor 1def graph_templates(host_id): 2from django.db import connection 3 cursor=connection.cursor() It marked an error at line 3 :Undefined variable from import: cursor nobody 775725322@qq.com Undefined variable from import cursor 0 0 0 0 0 0
8838 2008-09-03 11:07:42 2011-09-28 16:12:17 2019-06-24 01:51:12.559114 Ready for checkin closed Documentation     master fixed typo in model fields docs http://docs.djangoproject.com/en/dev/ref/models/fields/#positivesmallintegerfield PositiveSmallIntegerField -class PositiveIntegerField([**options]) +class PositiveSmallIntegerField([**options]) nobody 7times9 typo model fields docs 0 1 0 0 0 0
8839 2008-09-03 11:13:06 2011-09-28 16:12:17 2019-06-24 01:51:13.182985 Unreviewed closed Documentation     master duplicate typo in model fields docs http://docs.djangoproject.com/en/dev/ref/models/fields/#imagefield -class ImageField(upload_to-None[, height_field=None, width_field=None, max_length=100, **options]) +class ImageField(upload_to=None[, height_field=None, width_field=None, max_length=100, **options]) ^ nobody 7times9 typo model fields docs 0 1 0 0 0 0
14188 2010-08-28 23:59:08 2010-08-29 00:29:54 2019-06-24 02:49:14.797485 Unreviewed closed Documentation     master duplicate permalink docs import mistake The first example has: {{{ from django.db import models @models.permalink def get_absolute_url(self): }}} which is fine. But {{{ from django.db.models import permalink @models.permalink def get_absolute_url(self): }}} won't work. Patch makes consistent with first example. nobody 7times9 import 0 1 0 0 0 0
14189 2010-08-29 00:07:24 2010-08-30 10:31:56 2019-06-24 02:49:15.420804 Ready for checkin closed Documentation     master fixed permalink docs import mistake The first example has: {{{ from django.db import models @models.permalink def get_absolute_url(self): }}} which is fine. But {{{ from django.db.models import permalink @models.permalink def get_absolute_url(self): }}} won't work. Patch makes consistent with first example. nobody 7times9 import 0 1 0 0 0 0
24778 2015-05-10 18:19:33 2018-09-27 18:18:34 2019-06-24 04:43:57.789814 Someday/Maybe assigned Migrations New feature Normal master   Data Migration from Fixture Providing data via fixtures has been deprecated. In the past, we used to execute the loaddata manually. After Django introduce migration, the recommended way to import data is to create an empty migration and use `RunPython` migration operations to load the data. This is a very common use case for data migration via fixture. We create the function just to call_command `loaddata`. http://stackoverflow.com/a/25981899/764592 In my opinion, instead of having to create the function, we can actually simplify this into a migration operation on its own. As follow: {{{ # Module: django.db.migrations.operations.base.special from django.core.management import call_command class LoadFixture(Operation): reduces_to_sql = False reversible = False def __init__(self, *fixtures): self.fixtures = fixtures def state_forwards(self, app_label, state): pass def database_forwards(self, app_label, schema_editor, from_state, to_state): for fixture in self.fixtures: call_command('loaddata', fixture, app_label=app_label) def database_backwards(self, app_label, schema_editor, from_state, to_state): pass … vccabral 9gix   0 1 1 1 1 0
26885 2016-07-10 04:29:02 2016-07-11 10:27:43 2019-06-24 05:06:59.694701 Unreviewed closed contrib.admin Bug Normal 1.9 invalid django admin jquery initial changed in 1.9+ Hi,all: Does somebody can explain why we change `jquery.init.js` file in admin module ? in current code, this style cause some scope issue. we can't get `jQuery`,`$` in global. {{{ /*global django:true, jQuery:false*/ /* Puts the included jQuery into our own namespace using noConflict and passing * it 'true'. This ensures that the included jQuery doesn't pollute the global * namespace (i.e. this preserves pre-existing values for both window.$ and * window.jQuery). */ var django = django || {}; django.jQuery = jQuery.noConflict(true); }}} in 1.8 release package . the code is {{{ var django = django || {}; django.jQuery = jQuery; var yl = yl || {}; yl.jQuery = django.jQuery; // this file also prevents django.jQuery.noConflict // there's got to be a better way ... }}} I don't think this is a better improve . we have so many plugins depend on global jQuery or $ ! we can't use them anymore,we have to add custom jQuery lib or change code to local scope. I submit a PR , if you agree with me, please confirm it. nobody 9nix00   0 0 0 0 0 0
6752 2008-03-11 08:55:08 2011-09-28 16:12:23 2019-06-24 01:27:38.930832 Ready for checkin closed Documentation     master fixed Documentation slightly unclear about "safe" strings in filters My objective here is to prevent somebody else from falling into the same trap as I. This is with regard to auto-escaping, the safe filter, and escapejs. I had auto-escaping on and tried the following: template_string|safe|escape I now now this is clearly wrong because in the docs it states. "This does /not/ make the string safe for use in HTML." But when I first read it, I thought this was perfect and that all I need to do is the above statement. I would use safe to clear the auto-escaping and the escape the string for javascript. But this is not how it works. Albeit, I might have over-thinked it but I figured that "safe" either set a bit in the template context so that auto-escaping would not happen at the end. I didn't realize that "This does /not/ make the string safe for use in HTML" meaning that auto-escaping would pick up on this fact and escape the string. The output of another filter might make the string unsafe again. So the logic is correct. I would like to see a change to the docs here are some ideas: 1. Update the documentation for Safe to be something like the following: "Marks a string as not requiring further HTML escaping prior to output. When this filter is not the last filter applied, subsequent filters might make string /not/ safe for HTML output and the string will be escaped if auto-escaping is on. When autoescaping is off, this filter has no effect." That's obviously too wordy but I think it brings across the point. 2. Update auto-escaping docs to mention that safe will turn off auto-escaping unless a filter that follows safe makes the string unsafe for HTML output. 3. Or maybe just a more technical explaination of how safe, escape, and auto-escape work under the covers. Thanks. Rupe <removed at reporter's request> safe, auto-escape, escapejs 0 1 0 0 0 0
23245 2014-08-06 16:17:27 2014-08-06 16:51:01 2019-06-24 04:27:11.325207 Unreviewed closed *.djangoproject.com Bug Normal   worksforme TypeError: 'set' object does not support indexing ==== How to Reproduce ==== While doing a GET operation on `/watchlist`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'action': u'watch', 'realm': u'wiki', 'resid': u'TitleIndex'} }}} User agent: `Mozilla/5.0 (PLAYSTATION 3 4.60) AppleWebKit/531.22.8 (KHTML, like Gecko)` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/home/trac/venv/lib/python2.6/site-packages/trac/web/main.py", line 497, in _dispatch_request dispatcher.dispatch(req) File "/home/trac/venv/lib/python2.6/site-packages/trac/web/main.py", line 214, in dispatch resp = chosen_handler.process_request(req) File "/home/trac/venv/lib/python2.6/site-packages/tracwatchlist/plugin.py", line 524, in process_request req.redirect(req.href(realm,new_res[0])) TypeError: 'set' object does not support indexing }}} SAMUEL BARFIELD III @BARFIELDIII   0 0 0 0 0 0
4760 2007-07-04 02:44:01 2008-02-28 05:42:12 2019-06-24 01:05:50.085592 Unreviewed closed Template system     master invalid BuiltinLibrary class for automatic and easy insertion of custom filters/tags All, Re the article here: [http://groups.google.com/group/django-users/browse_frm/thread/2f254591d5d84340/5ad372019ee0c3c6?lnk=gst&q=custom+filters&rnum=1#5ad372019ee0c3c6 ] (ignoring the digression about email subject lines!) I put forward the need for a simple way to have filters and tags that I define in my local script automatically available to DJango, without the need for a package import, or a specific 'template' package within my source tree. I have attached a page of 4 lines (+ documentation) that enables this with the class BuiltinLibrary. Using the class is as follows: {{{ def filter_rst_h1(value, arg='-'): "Write a single underline under the text" line=arg * len(value) return "%s\n%s" % (value, line) from django.template import ``BuiltinLibrary`` # <-- NEW! # set up extra library of routines for later use... library = BuiltinLibrary() library.filter('filter_rst_h1', filter_rst_h1) }}} The patch and a full, standalone demonstration program is attached. Thanks for considering this patch... A.J.E. nobody A. J. Ellerton <aj@ellerton.net> Builtin Automatic Library 0 1 0 0 0 0
4468 2007-06-03 14:41:19 2007-07-12 08:22:46 2019-06-24 01:02:42.248028 Unreviewed closed Validators     master wontfix More information in field length validation error (oldforms) If the length of the entered text is more than ''maxlength'', django says: {{{ Ensure your text is less than 3000 characters }}} It would be nice for the user to know how many characters in the text. Please see the patch attached below: {{{ Ensure your text is less than 3000 characters (it is 4221). }}} Best, adrian A. Murat Eren <meren@pardus.org.tr> oldforms, validation, maxlength 0 1 0 0 0 0
4469 2007-06-03 14:47:13 2011-10-09 12:44:57 2019-06-24 01:02:42.875948 Ready for checkin closed Forms     master fixed More information in field length validation error (newforms) If the length of the entered text is more than ''max_length'', django says: {{{ Ensure this value has at most 3000 characters. }}} It would be nice for the user to know how many characters in the text. Please see the patch attached below: {{{ Ensure this value has at most 3000 characters (it has 4112). }}} Best, adrian A. Murat Eren <meren@pardus.org.tr> newforms, max_length, min_length, validation 0 1 0 0 0 0
14142 2010-08-20 10:12:10 2010-09-10 19:04:35 2019-06-24 02:48:44.947882 Unreviewed closed Documentation     1.2 invalid Improvement (?) on tutorial part 3 In "'''Decoupling the URLconfs'''", where it says {{{ urlpatterns = patterns('mysite.polls.views', (r'^$', 'index'), (r'^(?P<poll_id>\d+)/$', 'detail'), (r'^(?P<poll_id>\d+)/results/$', 'results'), (r'^(?P<poll_id>\d+)/vote/$', 'vote'), ) }}} It should say (IMHO) {{{ from django.conf.urls.defaults import * # <--- this line urlpatterns = patterns('mysite.polls.views', (r'^$', 'index'), (r'^(?P<poll_id>\d+)/$', 'detail'), (r'^(?P<poll_id>\d+)/results/$', 'results'), (r'^(?P<poll_id>\d+)/vote/$', 'vote'), ) }}} That way, it should be clearer that its the whole decoupled file. I've not tested what happens if I let the admin stuff in both url.py files. My two cents. Thanks you all. nobody AMJ Tutorial part 3 0 0 0 0 0 0
7412 2008-06-10 18:32:15 2008-06-28 21:28:51 2019-06-24 01:34:47.917018 Unreviewed closed contrib.admin     master invalid i18n crash on non-ASCII (UTF-8 encoded) doctrings The Unicode decoding error occured in i18n.py when source file contains non-ASCII docstrings.[[BR]] Example:[[BR]] Navigate to yoursite/documentation/models using following model example (the source file is in utf-8 encoding) {{{ # -*- coding: utf-8 -*- # ... class TestModel(models.Model): """ Test description with non-ASCII symbols. АаБбВвГг """ }}} Workaround !#1: use u"""....""" format '''but not on TAGS''' - tag parser is different :([[BR]] Workaround/patch !#2: patch or change django/templatetags/i18n.py '''!TranslateNode.render''': from translation.ugettext(value) to translation.ugettext(smart_unicode(value)) nobody AV <av0000@mail.ru> i18n utf8 unicode 0 1 0 0 0 0
2668 2006-09-07 11:31:19 2006-09-11 14:50:52 2019-06-24 00:43:38.182221 Unreviewed closed Translations defect normal   fixed Russian translation update I've update Russian translations --- added more missing strings and fixed few mistranslated ones. hugo AYakovlev@rambler.ru   0 0 0 0 0 0
29802 2018-09-28 00:28:38 2018-09-28 00:32:37 2019-06-24 05:55:52.463526 Someday/Maybe new CSRF New feature Normal 2.1   Allow skipping CSRF check for Referer header Currently, Django's CSRF middleware will reject any 'non-safe' HTTPS request that lacks a Referer header: https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/csrf.py#L242 However, some users may prevent their browsers from sending the Referer header, due to privacy concerns. These users are unable to submit 'non-safe' requests (e.g. POST requests) on HTTPS-enabled Django-powered website that use CSRF protection. For some websites, checking the Referer header may provide no added security benefit. For example, an HSTS-preloaded website which controls all of its subdomains has nothing to gain from this check - there are no untrusted subdomains which can mount an attack, and HSTS prevents an HTTP MITM attack. To allow these websites to provide more flexibility to their users, Django should support disabling this CSRF Referer check. This could be done through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True' to avoid breaking existing sites). nobody Aaron1011 csrf,https,hsts,referer 0 0 0 0 0 0
28085 2017-04-17 13:30:00 2017-05-05 19:27:55 2019-06-24 05:19:59.986176 Accepted closed Internationalization Bug Normal 1.11 fixed EN django.po does not have default "Plural-Forms" to copy django/conf/locale/en/LC_MESSAGES/django.po does not have "Plural-Forms: nplurals=2; plural=(n != 1);\n" line. So if I'm "makemessage"ing the english language I have issue with plural form, because it is from *.pot file as "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n" claudep Abaks plural localization en 1 0 0 0 0 0
29726 2018-09-01 09:41:36 2018-09-03 06:16:30 2019-06-24 05:55:03.368891 Unreviewed closed Database layer (models, ORM) Bug Normal 2.1 invalid Setting the Shanghai time zone causes a query error I have a little website. It's settings.py like this {{{ LANGUAGE_CODE = 'en-us' TIME_ZONE = 'Asia/Shanghai' USE_I18N = True USE_L10N = True USE_TZ = True }}} And then, I had saved some data in SQLite3. But get a error {{{ >>> for each in Message.objects.all(): ... print(each.create_time.year, each.create_time.month) ... 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 2018 8 >>> for each in Message.objects.filter(create_time__year="2018", create_time__month="09"): ... print(each.create_time.year, each.create_time.month) ... 2018 8 2018 8 2018 8 >>> }}} These three messages were sent in the last eight hours of August 31, 2018 UTC. The result of querying through .all() is UTC time. But the result of querying through .filter() is Asia/Shanghai time. This brings me some trouble... nobody AberSheeran   0 0 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

Next page

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
    )
Powered by Datasette · Query took 3143.636ms