Hello,
Il 10/02/2016 00:25, Tim Graham ha scritto:
The introduction to the admin in the docs [0] reads:
"One of the most powerful parts of Django is the automatic admin interface.
It reads metadata in your model to provide a powerful and production-ready
interface that content produ
On Tue, 9 Feb 2016 at 23:25 Tim Graham wrote:
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin
>> interface. It reads metadata in your model to provide a powerful and
>> production-ready interface that content producers ca
I can't help but feel that the "admin is very rudimentary and hard to
customize" is perpetually overplayed by many in the community. Maybe I'm
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
I find it the quickest and most efficient way to provide an admin interface
for s
Just to follow up - I think the biggest improvements I've yearned for are
fairly simple and unlikely to break backwards compatibility:
1. Break up the remaining monolithic methods to allow easier overriding
(this is much better nowadays but a few beasts remain)
2. More blocks in the templates or
On Tuesday 09 February 2016 23:33:50 charettes wrote:
> Hi everyone,
>
> The chosen fix[1] unfortunately introduced a new regression[2].
>
> It looks like the behavior described in the previous ticket was possible
> with
> Django 1.8 under certain circumstances[3] where the abstract models define
I should have mentioned that this behavior is reproducible since at least
Django 1.6 and has not been introduced by Django 1.8. I wouldn't be
surprised
if it has always been working before the fix was introduced.
Still, as you mentionned the conditions required to achieve this were really
convolu
Is salted SHA1 sufficiently insecure to remove it from the default
PASSWORD_HASHERS or should we leave it for now? Any project created before
pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1
hashes unless all their users have logged in since. I've written
instructions
Hi there,
I'd love to see some (most?) of the features from django-polymorphic on
django itself. I'm very much be willing to work on this myself. Of
course, there's several details that need to be discussed too, HOWEVER,
but before I even start, I'd like to know if they'd even be acceptable
in dja
I'm not sure. Did you find this past discussion:
https://groups.google.com/d/topic/django-developers/tSLuqu0UFrY/discussion
? The idea was also mentioned a month ago with no replies:
https://groups.google.com/d/topic/django-developers/Ov91x7AXwmM/discussion
Are you a maintainer of django-polymo
How's the performance of django-polymorphic compared to using
select_related of childs of interest and then handle them manually in the
code with hasattr ? Does it resolve to multiple joins as the select_related
option, or does it perform multiple queries? Inheritance using multiple
tables is a
On 11/02/16 09:22, 'Hugo Osvaldo Barrera' via Django developers
(Contributions to Django itself) wrote:
Hi there,
I'd love to see some (most?) of the features from django-polymorphic on
django itself. I'm very much be willing to work on this myself. Of
course, there's several details that nee
On Wed, 10 Feb 2016 at 13:55 Andy Baker wrote:
> I can't help but feel that the "admin is very rudimentary and hard to
> customize" is perpetually overplayed by many in the community. Maybe I'm
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
>
> I find it the quickest and
On 11/02/16 00:55, Andy Baker wrote:
I can't help but feel that the "admin is very rudimentary and hard to
customize" is perpetually overplayed by many in the community. Maybe I'm
suffering Stockholm Syndrome but I'd like to raise a dissenting voice.
I must admit I'm a large proponent of warn
It looks like we agree that this depending on import order is not on, so we
have no choice but to break behaviour in some cases.
Option 1 (don't allow relative references) removes support for relative
references in abstract models for everyone.
Option 2 (resolve references relative to the first
Hi all,
On Wed, Feb 10, 2016, at 19:38, Tim Graham wrote:
> I'm not sure. Did you find this past discussion:
> https://groups.google.com/d/topic/django-developers/tSLuqu0UFrY/discussion
> ? The idea was also mentioned a month ago with no replies:
> https://groups.google.com/d/topic/django-develope
On 11/02/16 15:05, 'Hugo Osvaldo Barrera' via Django developers
(Contributions to Django itself) wrote:
> There was some research by Sebastian Vetter on "single-child
> auto-resolve" solutions for MTI and how they scaled (from memory,
> model-utils' InheritanceManager, polymorphic, and gene
16 matches
Mail list logo