I often found this handy too. Here's my implementation on bitbucket[1].
There are tests[2] and documentation[3]. It's something I wanted propose to
Django core as well but never found time to do so. :)
In my implementation I chose to assign numeric values explicitly:
SetField(choices=((1,"pizza")
As an alternative to creating AppConfig class, what about registering app
names, just like we register ModelAdmin instances:
admin.site.register_app_label("myapp", _("My awesome web app"))
- Sergiy
On Thu, Dec 6, 2012 at 11:57 PM, Pedro J. Aramburu
wrote:
> As I explained on the Django users f
I'm not sure that invalidating session based on last password change is the
right thing to do. If the password has been compromised, this effectively
enables an active attacker to deny access to the legitimate user. In case
of Django admin site this can be quite disruptive as there is no password
r
On Mon, Jul 11, 2011 at 7:02 AM, stan wrote:
>
>
> On Jul 11, 11:36 am, Lachlan Musicman wrote:
> > On Mon, Jul 11, 2011 at 18:58, stan wrote:
> > > Hi,
> >
> > > Maybe I missed something, but I didn't found any explanation in the
> > > doc about how to localize a date or a number in the python
IMO, obscuring the reason for admin site access denial only confuses
the user. If the attacker has user credentials (and knows admin URL!)
the big job has already been done and verifying whether that account
is admin or not is trivial enough. There is no added security in
displaying wrong error mes
This list is for discussing the development of Django itself. Please
post this type of question to django-users. That error is from the
application you are trying to run and has nothing to do with Django
itself.
cheers
On Thu, Feb 3, 2011 at 12:35 PM, b...@live.se wrote:
> Hi all , I install dio
What you are proposing is too idiosyncratic to be part of the Django
framework. As already suggested by others it should be trivial enough
to create your own middleware to address your needs:
if language preference not specified explicitly by the user:
set it to the language of your choice
Put
pply query set filters. Does this make sense?
On Fri, Jan 28, 2011 at 11:12 AM, Sergiy Kuzmenko wrote:
> Thanks for you input Russ. Yes, Count("*") does look cleaner but
> (based on a quick glance on the code) may require some serious
> rewiring. I'll give some
eers
Sergiy
On Fri, Jan 28, 2011 at 10:36 AM, Russell Keith-Magee
wrote:
> On Fri, Jan 28, 2011 at 11:05 PM, Sergiy Kuzmenko
> wrote:
>> A couple of points regarding this:
>> http://code.djangoproject.com/ticket/15183#comment:1.
>>
>> If nulls should not be c
A couple of points regarding this:
http://code.djangoproject.com/ticket/15183#comment:1.
If nulls should not be counted then then they should be excluded from
results but they are not. You always get an entry for nulls (if they
are present) with zero count which if you need them is a problem and
i
27;ll go ahead and will file a
bug in track.
Cheers
On Wed, Jan 26, 2011 at 10:03 AM, Sergiy Kuzmenko wrote:
> I want to be able to count how many times each value (including nulls)
> is present. I think that exactly what count is for. -:)
>
> Upon a closer look the problem is not l
ing something, but if you count all the defined
> foreign keys AND all the null values, won't you just end up with a
> count of the parent model? Or are you saying that you explicitly want
> to count how many values are null *instead of* defined?
>
> On Jan 25, 2:39 pm, Se
Hi there!
Annotating a nullable foreign field with Count seems to always return
the count of null values as zero (at least in MySQL environment). A
quick look into this problem reveals that the corresponding SQL clause
is generated as `count()` [1]. This causes to exclude null
values from annotati
It sounds like the concern here are repetitive and untidy lines with
lots of "verbose_name" so use of positional arguments may prettify a
bit field definitions. It is not obvious from documentation (all
fields are listed alphabetically) but for all except relationship
fields verbose_name is the fir
Sorry if I'm being impatient here but I don't want to start raising
this question when it's too close to complete feature freeze. Is it
possible to include ticket #14570[1] into 1.3 release? It is a rather
trivial change which will help generate correct long date display in
certain locales.
[1] -
... just to clarify:
> There appears to be some confusion here. The pluralize filter *already
> exists*. It has existed since Django was open sourced. if you have
> complex pluralization rules to support, it wont work, but in those
> cases, you can use {% blocktrans %} in templates, or calls to
> u
sh or Chinese.
On Wed, Mar 24, 2010 at 8:49 PM, Russell Keith-Magee
wrote:
> On Thu, Mar 25, 2010 at 8:32 AM, Sergiy Kuzmenko wrote:
>>> If you have any suggestions for how we could expose ungettext better
>>> in templates, I'm all ears. However, given the complexit
> If you have any suggestions for how we could expose ungettext better
> in templates, I'm all ears. However, given the complexity of
> pluralization rules and pluralization usage in the general case, it's
> not a simple task. Suggestions welcome.
My suggestion is to make pluralization compatible
Few weeks ago I made a proposal for an alternative month representation
format as may be required by some locales (most Slavic languages and Greek,
maybe others): http://code.djangoproject.com/ticket/12309
This would allow to generate grammatically correct full text date
representations such as "J
I wonder if there is a particular reason why last_login field of is not
defined as "null=True"? It makes sense to me to have it as null which would
mean that the user never logged in. Could there be any dependencies relying
on this field not being null?
Thanks
Sergiy
--
You received this messag
20 matches
Mail list logo
