On Monday, June 15, 2015 at 11:03:07 PM UTC+2, Shai Berger wrote: > > (I received the message I'm replying to here with an empty subject, and > detached from the thread. Google Groups being funny?) >
Guess so, I didn't get an email from your reply either... that's why I responded this slowly. On Monday 15 June 2015 22:52:09 Rick van Hattem wrote: > > On 15 June 2015 at 21:34, Florian Apolloner <[email protected] > <javascript:>> wrote: > > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph) > > > > > > wrote: > > >> Would anyone oppose a pull request like this? > > > > > > Yes, it is highly backwards incompatible for not much gain, I am also > > > usually just fine with one/two fields for list_display. You could just > > > use your own admin subclass for that. > > > > Can you clarify on that? I don't see the backwards incompatibility here. > > > > It could quite easily cause breakage for specific client-side code, > although I > wouldn't consider that "highly" incompatible. > > However, it could also easily lead to inappropriate data exposure -- where > people who are supposed to get an "opaque" view of some objects will, upon > upgrade, be able to see all their details. I consider that risk to weigh > much > more than the potential gains. > Ah, yes... you are right, I didn't take that into consideration. That is a very valid argument, you have persuaded me that it shouldn't change the behaviour in all cases. > > > > The discussion here shouldn't be whether you can or cannot fix it > yourself > > (obviously, you can, that's not the issue), it's what a good/sane > default > > would be. For brand new Django users, would it be more convenient to > have 1 > > column or just all local columns and make it slightly more usable? > > > Beside "convenient", you should also consider "safe", and besides brand > new > users, there are also established users with significant codebases. Now, > arguably, if we were starting the Django project today, we could use the > default you propose, people would be aware of it, and if they wanted to > limit > access, they would. One could still argue that "whitelisting" is better > than > "blacklisting", and we could have a whole discussion about this. But > having a > Django upgrade just expose more data by default, even in the Admin, would > be a > serious breach of our users' trust IMO. > Generally I'm a great proponent of whitelisting versus blacklisting, with the admin, I'm not because by default all of the fields are already visible when editing. So right now it's just inconsistent between the two. Although I'm not a fan of magic, if the fields and/or fieldset are not set within the admin, they're already visible so in that case it might still be a good default. Conditional defaults are less than optimal of course... what are your thoughts about a solution like that? Or as Marc suggests, supporting __all__ would help a lot too. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/edd1cfeb-04ec-4fe4-a2c1-d6d26fb4261b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
