On Tue, 22 Feb 2011 13:22:30 +0200, Russell Keith-Magee
wrote:
On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip wrote:
One Trac feature that I suspect *might* help in this regard is one
that I've raised before -- allowing users to flag individual issues
that they have an interest in seeing sol
On the same note, the Reports [1] page in the wiki contains several links
under "Tickets by popularity", which attempt to do exactly this based on
the existing CC field. However none of these links work - can anyone
recall if they ever did?
[1] http://code.djangoproject.com/wiki/Reports
O
+1 on this. Messages should not give inaccurate information.
I think the current behavior is also eventually detrimental to security.
In a real life setting this leads to superfluous password resets and
helpdesk queries - all leading to worse password choices by the common
user, besides the
On Wed, 16 Mar 2011 07:49:17 +0200, Michal Petrucha
wrote:
On Tue, Mar 15, 2011 at 09:15:29PM -0500, Javier Guerra Giraldez wrote:
On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus
wrote:
> A concern here is that composite indexes, like unique, are
> sensitive to the ordering of the fiel
At the risk of bike-shedding this to death - if the current behavior
included the correct message (user can't access the admin) - would we
seriously consider a ticket asking to replace it with the current
"misleading/more secure" message, for security's sake?
On Wed, 16 Mar 2011 06:11:18 +0
Perhaps augment the new policy by stating that contributed backports for
bugs that are left out by this change will be favorably looked upon, and
committed to the branch unless there is a good reason no to commit them.
This still achieves the goal of making the routine bugfix commit cycle
fas
Without really suggesting a better alternative, I'd like to highlight two
problems I see with this approach:
First, the logic tied into the context manager does not match the
idiomatic use of context managers in Python. One expects a context manager
to "clean up" on exit, rather than *save*
Hi Carl,
On Fri, 29 Apr 2011 17:42:32 +0300, Carl Meyer wrote:
Hi Yishai,
On 04/29/2011 08:53 AM, Yishai Beeri wrote:
First, the logic tied into the context manager does not match the
idiomatic use of context managers in Python. One expects a context
manager to "clean up" on ex
On Tue, 03 May 2011 06:59:02 +0300, Phui Hock wrote:
Holy god, not to be rude, but given that this is completely unreadable
I'm
even more -1 than I ever would have been on the basis of the principle
of a
dumber template language.
Alex
My apologies. All that is doing is rendering the foll
+1 on both: combine to regex IGNORABLE_URLS, and on empty defaults with
commented-out suggestion in generated settings.py
As a bonus, the transition for someone who has placed non-default values
in IGNORABLE_(STARTS_ENDS) to regexes is near trivial.
On Tue, 03 May 2011 23:16:12 +0300, Aymeri
+1 on breaking backwards compatibility, defaulting the arg to None.
However, in [1] Julien suggests to also allow a callable - which I think
would be very useful, and provide all the flexibility one would need.
So IMHO:
- if arg is callable, call it with signature as suggested in [1]
- if a
Wouldn't it be possible to work around this, even for the time being, by
having auth.User read a SETTING to use as the default max_length
(defaulting of course to the old 75)?
Hardly the prettiest solution, but given the right name
(AUTH_EMAIL_MAXLEN_HACK, anyone?) and documentation it can b
+1 on removing it only as part of a larger admin improve/overhaul move.
Is there a place where plans and ideas for such a move are discussed /
aggregated? Is there any current work being done in that direction?
On Mon, 23 May 2011 21:45:23 +0300, Idan Gazit wrote:
I agree that it's redundan
On Sun, 29 May 2011 15:57:34 +0300, Fraser Nevett
wrote:
On May 29, 5:22 am, Julien Phalip wrote:
As a side thought, if this functionality does get implemented, would
it be feasible/desirable to have Django emit a warning to encourage
the developer to mark a view as sensitive if it detected
Hello Jorge,
On Thu, 30 May 2013 12:42:20 +0300, Jorge C. Leitão
wrote:
Hi Russell Keith-Magee.
Thanks for your criticisms. Let's see if I can answer some of them.
I'd turn this question back onto you -- why *should* the search start
locally? What collisions are you seeing between apps t
Is this not almost trivial to work around by creating a new module
'newapp', importing the original app code from it, and then using
'path.to.newapp' as a new "copy" of the app in INSTALLED_APPS?
Yishai
On Mon, 03 Jun 2013 12:24:38 +0300, Aymeric Augustin
wrote:
2013/6/3 Jorge C. Leitã
Kudos for making this happen!
Small discrepancy: the blog post states python 2.7 is required; the
release notes it links to state python 2.6.5 is still supported, and 2.7
will be required from Django 1.7 onwards.
Yishai
On Wed, 23 Oct 2013 06:08:33 +0300, James Bennett
wrote:
It's al
17 matches
Mail list logo
