Re: use semantic versioning after 2.0?

On Monday, July 14, 2014 9:50:53 PM UTC+2, Aymeric Augustin wrote: > [snip] +1, please leave it there -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Documentation enhancement for class based GenericView

Hi Wayne, On Wednesday, July 16, 2014 3:48:34 PM UTC+2, Wayne Ye wrote: > > >- When GET a resource, I want to do a counting job to record total hit >on this specific resource > > Override dispatch or get, count and delegate to the parent. > >- When a posted form is invalid, I

Re: [New feature request] Prefer:Safe request header

Hi, On Wednesday, July 23, 2014 1:58:26 PM UTC+2, S4mmael wrote: > > It would be really nice to have some mechanism intended to work with this > header in Django. A kind of miidleware or a decorator maybe. > What's wrong with "if request.META.get('prefer') == 'safe'"? Cheers, Florian -- You

Re: Updating the organization of the Django Project

+1 On Wednesday, July 23, 2014 3:30:13 PM UTC+2, Aymeric Augustin wrote: > > Hello, > > I’ve been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with our current > organization. There’s no short version

Re: Django and BREACH (remember that?)

Hi, On Monday, August 4, 2014 3:15:15 AM UTC+2, Adam Brenecki wrote: > > So, a while ago, BREACH happened, and Django's CSRF implementation was > vulnerable, as was Rails'. The paper that discussed it described a > mitigation (and a Rails patch had already been made), so I implemented that >

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 11:01:14 AM UTC+2, Adam Brenecki wrote: > > What is wrong with xor+base64? Not that Vigenère cipher is complex, but we >> have a pretty hard stance against implementing "crypto" on our own. >> > > Nothing, really; that's probably what I would have used had FunkyBob not

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 4:21:43 PM UTC+2, Michael Mior wrote: > > This looks good, although it seems like there should be a config setting > as I could imagine some use cases where the application expects the token > not to change in this way. I'm not sure how common this and whether or not >

Re: Proposal: Password Validity Layer

On Tuesday, August 5, 2014 8:45:05 PM UTC+2, Collin Anderson wrote: > > Could we handle it with model validation on a custom user model? Maybe add > a validate_password() method on the user model? I don't think so, using a custom user just for password validation is way to much work given that

Re: Proposal new Django Admin css style

On Tuesday, August 12, 2014 12:26:45 PM UTC+2, Thiago Avelino wrote: > > Not a Django core part of the topic, as it was? > But still a valid point. That said, I find the current style way nicer than the proposed one. Cheers, Florian -- You received this message because you are subscribed to

Re: Support HTML5 syntax

That is not just XHTML but perfectly valid HTML5. Cheers, Florian On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote: > > Could Django provides a way to render forms in HTML5 syntax? It now render > forms in XHTML syntax as > > Or could it in the settings provides an option as

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

I am not so convinced, what would you put in as the upper limit? While preventing n+1, it still requires you to know what n in this testcase is and changing n can lead to funny errors. Currently we are documenting (hopefully) how those query counts come together, so it's clear what's happening

Re: Support HTML5 syntax

On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote: > > It might cause issues when templates are using HTML5 syntax but forms are > using XHTML syntax? > The forms are not using XHTML syntax per se, they are valid HTML5 and valid XHTML! -- You received this message because you are

Re: Proposal: Password Validity Layer

Validation errors are only caught inside form validation. Forms set the password usually in save, not in clean, so I don't think that patch covers it (or at least the relevant forms have to call validate_password in clean too) On Monday, August 18, 2014 5:31:05 PM UTC+2, Keith Hackbarth wrote:

Re: 1.7 release?

On Tuesday, August 19, 2014 10:01:22 AM UTC+2, Stephen Burrows wrote: > What's the status? Good so far, release will be there soon (tm). Is there anything that community members can do? > Yes, test it heavily -- especially migrations :) -- You received this message because you are

Re: 1.7 release?

On Tuesday, August 19, 2014 10:01:22 AM UTC+2, Stephen Burrows wrote: > > Is there anything that community members can do? > Oh, and reviewing unreviewed tickets, so we can make sure there are no new release blockers. Cheers, Florian -- You received this message because you are subscribed

Re: integrating django-secure

On Thursday, August 28, 2014 2:44:08 PM UTC+2, Tim Graham wrote: > > Regarding settings, would it be preferable to move them into a single > dictionary setting called something like SECURITY_MIDDLEWARE_CONFIG? > Definitely. -- You received this message because you are subscribed to the

Re: integrating django-secure

On Saturday, August 30, 2014 12:58:18 PM UTC+2, Aymeric Augustin wrote: > > If it weren’t for backwards compatibility, we could recursively merge > dicts from user settings into defaults settings. For example > https://github.com/django/django/pull/3138 achieves that in > override_settings.

Re: integrating django-secure

On Saturday, August 30, 2014 1:58:07 PM UTC+2, Aymeric Augustin wrote: > > On 30 août 2014, at 13:39, Florian Apolloner <f.apo...@gmail.com > > wrote: > > > And what would that give us? if I want override FOO['BAR'] where from > would I override FOO with tha

Re: integrating django-secure

On Saturday, August 30, 2014 2:48:10 PM UTC+2, Tim Graham wrote: > > If base.py adds CONTENT_TYPE_NOSNIFF and prod.py wants to add > HSTS_SECONDS, it would look like this: > Oh, that makes sense, I was so focused on "extending" that I didn't see that base.py could define a minimal dict

Re: Please don't kill the ecosystem

Hi Pkl, On Monday, September 1, 2014 10:45:30 PM UTC+2, Pkl wrote: > > In random order, I stumbled upon: > - removal of django.conf.urls.defaults > - removal of markup contrib lib (adios built-in RST support) > - removal of request.raw_post_data (thus breaking about all existing > webservice

Re: [RFC] Python 3 and MySQL

On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote: > > Failed to install index for admin_views.PrePopulatedPostLargeSlug > model: (1071, 'Specified key was too long; max key length is 767 bytes') > Welcome to the wonderful world to mysql, afaik this is a warning and not an

Re: [RFC] Python 3 and MySQL

http://djangoci.com/ disagrees with you :) Would have to check the specific mysqldb version. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [RFC] Python 3 and MySQL

; > $ python -V > Python 2.7.8 > (mysql2)[inada-n@MBA:~] > $ pip list > MySQL-python (1.2.5) > pip (1.5.6) > setuptools (3.6) > wsgiref (0.1.2) > > On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner <f.apo...@gmail.com > > wrote: > > On Tu

Re: Proposal: add a get_for_template method to ContextList

On Monday, September 15, 2014 3:24:19 PM UTC+2, germano guerrini wrote: > > I'd like to bump this. While there might be better solutions, I think the > issue is not so wacky after all. > To be honest, I don't see an issue here at all. What the view returns should end up in the template. If

Re: mod_security SQL injection rules and Django cookies

Hi Nikolai, On Friday, September 19, 2014 1:50:33 PM UTC+2, Nikolai Prokoschenko wrote: > > 1. Has there been some security audit in the past which confirmed that > session ID handling inside Django is not vulnerable to SQL injection > attacks? > Nothing public that I am aware of, no. 2. Can

Re: Django 1.7: inconsistent behaviour of the fail_silently option when using SMTP backend

Hi Marcin, can you please open a ticket for this? If you are up to it, a patch with tests would be superb! Thanks, Florian On Sunday, September 28, 2014 1:26:42 PM UTC+2, Marcin Nowak wrote: > > Hello, > > After sereral minutes while using new Django (1.7) in DEBUG mode, I've got > enigmatic

Re: Storage engine aliases?

Hi Jeremy, To be honest I don't really see the gains (yet). How are those FILE_STORES supposed to handle the *_URL bits of those settings? Instances in settings are imo not going to fly, we should stay with strings to classes/instances there for now. So how would the 'static' or 'dynamic'

Re: Transaction management and atomic

On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote: > > Django does allow to continue the transaction if you explicitly choose > to do so. After handling the error, you must use set_rollback[1]. This > is useful for those rare cases where you want to continue after error in

Re: 1.8 release planning

On Saturday, October 18, 2014 1:17:58 AM UTC+2, Josh Smeaton wrote: > > I was thinking along the lines of a one page common upgrade issues that > summarised the back-compat changes from the previous releases, separated > under each release header. > We already have on page per release for

Re: Google Analytics API

Hi, this mailinglist is about the development of Django itself, you should write to django-users. Cheers, Florian On Wednesday, October 22, 2014 8:33:30 AM UTC+2, Muhammed Tüfekyapan wrote: > > Hi Everyone, > > > > I want to make an app. User come on site, they signed in and give access > to

Re: Suggestion for @cache_page compatiblity with jQuery JSONP

Uhm, I don't think you can ignore the callback, isn't the callback what's included in the response? As such for proper function the callback can't be ignored. Cheers, Florian On Wednesday, October 22, 2014 7:16:48 AM UTC+2, Luke Dupin wrote: > > Anyone that has used @cache_page with jquery's

Re: Websockets... again

On Tuesday, October 28, 2014 11:37:15 PM UTC+1, mpaolini wrote: > > What if we do it with asyncio? > It is 3.4 only, WSGI still has no support for Websockets and the API would change drastically… -- You received this message because you are subscribed to the Google Groups "Django

Re: Django Content Negotiation implement

Whenever it is done, I am not aware of anyone working on it. On Saturday, November 8, 2014 10:01:28 AM UTC+1, Asif Saifuddin wrote: > > Hi, > when > https://github.com/django/deps/blob/master/drafts/content-negotiation.rst > this dep is to be implemented in django? 1.8? > > Regards > > Asif >

Re: Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

Hi, this mailing list is about the development of Django itself -- you are better off in django-users. Cheers, Florian On Tuesday, November 11, 2014 6:54:34 AM UTC+1, Suren Sth wrote: > > I recently came across Swampdragon ( Visit official site > ). I am curious can

Re: Explicit relative imports

Parent imports inside the sub-framework could make sense, otherwise the mixture of imports might look odd. As long as it stops at ".." and doesn't include more it's relatively fine imo. Cheers, Florian On Tuesday, November 11, 2014 10:51:19 PM UTC+1, Aymeric Augustin wrote: > > Hello, > >

Re: Request for removal: Mysql warnings get promoted to Exceptions in debug mode

On Monday, November 17, 2014 11:40:15 AM UTC+1, Aymeric Augustin wrote: > > 2014-11-17 10:45 GMT+01:00 Florian Apolloner <f.apo...@gmail.com > >: > >> Imo we should make those exceptions instead! Data truncation should never >> be just a warning ;) >>

Re: How to stop testserver from within a test case?

Hi Arun, usage questions should go to django-users. This mailing list is about the development of Django itself. Cheers, Florian On Tuesday, November 18, 2014 4:51:27 PM UTC+1, Arun Marathe wrote: > > > > > We have Django 1.6. > > For a somewhat obscure reason, I need to stop the testserver

Re: Configurable safety options for high performance Django systems

Hi Rick, On Sunday, November 23, 2014 1:11:13 PM UTC+1, Rick van Hattem wrote: > If/when an *unsliced* queryset were to reach a certain limit (say, > 10,000, but configurable) the system would raise an error. > Django can't know if that would be the case without issuing an extra query -- and

Re: Configurable safety options for high performance Django systems

On Monday, November 24, 2014 10:05:47 PM UTC+1, Rick van Hattem wrote: > > My goal was simply to move the Django project forward but it seems the > problems I've encountered in the field are too uncommon for most other > developers to care or understand. > Oh, I can assure you that we care

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On Thursday, November 27, 2014 9:44:28 PM UTC+1, Shai Berger wrote: > > 1) Using the migration name in the index isn't really "predictable", and > isn't > even completely stable (the name changes when migrations are squashed), > unless > I'm missing something. > I think squashing isn't an

Re: Internationalise GET parameters?

On Friday, November 28, 2014 11:17:15 AM UTC+1, Jorge C. Leitão wrote: > > IMO, this lies on the assumption that the Form's field names are never > shown to the user. When the form is POST, this assumption is valid. > However, in a GET, the field names are presented in the URL, and the >

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

Hi, this mailing list is about the development of Django itself. Usage questions should go to django-users. On Thursday, December 4, 2014 1:16:13 AM UTC+1, inoyon artlover KLANGRAUSCH wrote: > > I am very beginner in the programming world, so please forgive my lack of > understanding... > >

Re: uuid field short websafe representation

+1 to everything you said, if someone wants a "websafe" representation, they can always just manually call safe_uuid on the UUID instance. On Saturday, December 6, 2014 6:00:58 PM UTC+1, Michael Manfre wrote: > > A non-standard, compressed unique value is not a UUID. Also, this forces >

Re: uuid field short websafe representation

Hi Radekm On Monday, December 8, 2014 10:41:41 AM UTC+1, Radek Svarz wrote: > > ad 1) I just react to the current implementation, where in the case of > other DBMS than PostgreSQL the hex value in 32 chars is stored. In such > cases I propose to store it in a smaller amount of 21 characters. (

Re: intended security model for templates

On Thursday, December 25, 2014 5:24:05 AM UTC+1, Curtis Maloney wrote: > > Whilst I can understand the appeal of allowing namespacing of template > libs, I think exposing full python paths is the wrong approach. Perhaps > allowing a "app_label:libname" approach to being more specific? > +1,

Re: Multiple template engines for Django - week 13

On Sunday, January 4, 2015 2:44:52 AM UTC+1, jdunck wrote: > > If getting proper support for other template backends would only delay the > 1.8 release timeline by a couple weeks, I think that is preferable to a > generalized 1.8 backend which only include DTL until 1.9. > Define proper

Re: Ticket #24601 - some questions about migrations

Hi, there is no need to send a mail to django-developers after leaving a comment on trac. We are notified about new comments via https://groups.google.com/forum/#!forum/django-updates already. Cheers, Florian On Monday, January 5, 2015 12:00:58 PM UTC+1, soka...@yandex.ru wrote: > > I have

Re: Settings: lists or tuples?

On Monday, January 19, 2015 at 12:35:10 PM UTC+1, Andreas Kahnert wrote: > > I'm strongly against lists. Lists are mutable objects, their components > can be changed in place. The settings are initialized at server start and > after that changes on them arn't reflected. Therefore all settings

Re: Settings: lists or tuples?

On Monday, January 19, 2015 at 3:45:18 PM UTC+1, Andreas Kahnert wrote: > > I'm not talking about modifications inside the settings.py but in other > place. With lists, unexperienced devs might do things like: from > django.conf import settings; settings.TEMPLATE_DIRS[3] = '/my_tpls'; and >

Re: Can't login after upgrading to 1.7.3, and workaround

I can reproduce the issue: Log a user into the admin Change iteration count Use a new browser (or private window) and log the same user into the admin Refresh the admin page of the first user -> login window Cheers, Florian On Thursday, January 15, 2015 at 2:31:55 AM UTC+1, Tim Graham wrote: >

Re: Middleware+Transactions:

On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote: > > Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be > accepted? > Most likely not since one of the reasons why @atomic isn't applied via a middleware (which would then include the middlewares after it) is

Re: Psycopg2 version support

Core could stay at 2.4.5 and contrib.postgresql could require a newer version :) On Saturday, February 14, 2015 at 9:53:43 PM UTC+1, Marc Tamlyn wrote: > > Hi all, > > Related ticket - https://code.djangoproject.com/ticket/24335 > > Django 1.8 will necessarily be the first version with a true

Re: Psycopg2 version support

Not exactly, cause installing psycopg2 via the OS package manager should __not__ require dev packages at all. On Monday, February 16, 2015 at 11:57:01 AM UTC+1, Thomas Stephenson wrote: > > > Installing psycopg2 does require development tools, while Django does not > > Installing psycopg2 2.0.0

Re: JsonResponse and list values

On Tuesday, February 17, 2015 at 12:30:25 AM UTC+1, Curtis Maloney wrote: > > Ran into this bug this morning... what's the rationale behind JsonResponse > only accepting dict types unless you set safe=False to allow _any_ type? > Cause dict maps to object which is somewhat safe. > Surely

Re: GSOC 2015 project ideas suggestion

Hi Aisf, while it theoretically would be possible to replace all of Django's request/response handling with Werkzeug, there is not much gain in it currently -- especially when considering backwards compatibility etc… Cheers, Florian On Saturday, February 21, 2015 at 9:14:27 PM UTC+1, Asif

Re: django admin: open popups as modals instead of windows

On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote: > > I'm no UI/UX expert but modals are more or less the standard today, > windows looks like a relic from the 2000s. > That argument is based on what? I'd personally argue that windows are superior cause I can

Re: Django Admin New Look

First off, great work Alex! On Thursday, March 12, 2015 at 11:31:32 AM UTC+1, elky wrote: > > Yes, I tested this theme on real project which is big and complex. But I'm > not 100% sure that I saw all cases. I think we need more user's feedback on > it. > You could create a project with a few

Re: csrf middleware token from request body

I am pretty sure you can configure angular to send the token in the header. Either way, we are not going to try and load json, just we can't find a token otherwise… Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions

Re: Adding flash objects

I am not really sure what exactly you are proposing here, but Flash is on its way to die and that is good. I really don't see why Django should add any support for Flash, that said you are obviously free to write your own template tags to get rid of some boilerplate code. Cheers, Florian On

Re: [GSoC] Security Dashboard

On Sunday, March 22, 2015 at 8:22:10 PM UTC+1, Tim Graham wrote: > > I'm not sure about the background of that idea, but it might be somewhat > obsolete. In Django 1.8, we integrated django-secure and its security > checks. These run as part of the system check framework: >

Re: improving debug logging in development

On Monday, March 23, 2015 at 9:45:12 PM UTC+1, Wim Feijen wrote: > > This may sound stupid, but I actually use Logbook for logging because I > find it easy to use. > Why would this sound stupid? Logbook is a nice library and actually worth thinking about if we start using dependencies in

Re: django-admin.py shebang

On Wednesday, April 1, 2015 at 5:34:55 PM UTC+2, James Bennett wrote: > > This right here is the giveaway that what you're looking at is Debian's > version of Django (they modify the name from 'django-admin.py' to > 'django-admin' to suit their policies for file naming). > Newer Django

Re: Possible security issue using request.read()

Technically we'd set the sockettimeout already in the __init__ of LimitedStream, but in the end I think this is better fixed at the loadbalancer/webserver level as with any other attack similar/equal to "slowloris". There speaks nothing against docs though… Cheers, Florian -- You received

Re: help needed?

Hi, take your pick: https://github.com/django/djangoproject.com/issues :) Cheers, Florian On Monday, April 6, 2015 at 9:38:28 PM UTC+2, Bernhard Ja wrote: > > Hello together, > i'm the author of https://github.com/ierror/django-js-reverse - i'd like > to contribute sth. to django. > Is there

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

As long as it doesn't hurt we can keep em there -- remove as soon as they cause a problem ;) On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote: > > I just discontinued the 1.3 docs on docs.djangoproject.com, they are > still available on django.readthedocs.org. Do you think we

Re: Why deprecate the ability to reverse using the Python path?

Hi Thomas, On Thursday, April 16, 2015 at 10:21:04 AM UTC+2, guettli wrote: > > I talked about this in our team. The pace is to fast. > FWIW, every feature changed/deprecated goes through the same (fast) cycle. If you need slower changes, please stay with LTS versions. Granted, you still have

Re: django site framework bug, site name swaps back and forth each request

Hi, this is certainly a bug in your code or deployment via mod_wsgi (eg the two projects are in the same python process). Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: django site framework bug, site name swaps back and forth each request

On Sunday, April 19, 2015 at 10:32:47 PM UTC+2, Joe wrote: > > @Florian What do you mean the projects are in the same python process? > Let me phrase it differently, does it also happen if you run every project manually using runserver? If no, then this is a configuration bug, please see

Re: django deployment

Hi, this mailing list is about the development of django itself, please post to django-users instead. Also apache 2.6.4 does not exist, so… Cheers, Florian On Tuesday, April 21, 2015 at 11:00:53 AM UTC+2, Det S. Pillner wrote: > > Hi all, > > I develop a small django app. To service windows

Re: virtual fields and the migration framework

On Thursday, April 23, 2015 at 6:59:58 PM UTC+2, Federico Capoano wrote: > > cls._meta.add_field(self, virtual=True) > > gives: > > File "/var/www/django-hstore/django_hstore/virtual.py", line 29, in > contribute_to_class > cls._meta.add_field(self, virtual=True) > TypeError: Error when

Re: Potentially inconsistent behavior between test client and normal WSGI requests

On Friday, April 24, 2015 at 10:51:12 PM UTC+2, Matt Hooks wrote: > > (The behavior of the development server is similar to the test client, > although I haven't investigated for what exact reason.) > To be honest, even on my production machines I have this behavior -- so the question is

Re: Potentially inconsistent behavior between test client and normal WSGI requests

On Saturday, April 25, 2015 at 8:46:58 AM UTC+2, Matt Hooks wrote: > > I'm not really familiar with the design ideals of the Django devs or the > WSGI spec. From what I can tell, the spec doesn't specify whether the url > should be unquoted before passing it to the application. > I think the

Re: Guessable entry points

On Friday, May 1, 2015 at 3:51:50 PM UTC+2, Enrique Paredes wrote: > > So along this line of thought, `django-admin` is a good command name? > Does not really matter imo, that is what we have now and we should not change this without a really good reason. Cheers, Florian -- You received

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

On Monday, April 20, 2015 at 6:38:55 AM UTC+2, Gavin Wahl wrote: > > > Though it could still ajax-in the token from a page that does have it, >> right? >> > > Exactly right. > How so? You cannot just ajax-fetch stuff from different domains. The usual security policies will forbid that. If you

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

On a second thought I think I missread what you wrote and you ment all of this within the scope of one domain and not from the perspective of an attacker. On Monday, May 4, 2015 at 1:58:19 PM UTC+2, Florian Apolloner wrote: > > On Monday, April 20, 2015 at 6:38:55 AM UTC+2, Gavin Wahl

Re: SSL support for Django-admin runserver‏

On Monday, May 11, 2015 at 10:13:03 PM UTC+2, Steven Berry wrote: > > With all that said I'm in favor of what you suggest -- rely on gunicorn > where possible. However I don't think what I'm suggesting (and have already > implemented) fundamentally interferes with #21978. As far as I can tell

Re: SSL support for Django-admin runserver‏

Hi, On Tuesday, May 12, 2015 at 4:43:41 AM UTC+2, Steven Berry wrote: > > On Monday, May 11, 2015 at 6:30:39 PM UTC-4, Florian Apolloner wrote: > >> >> On Monday, May 11, 2015 at 10:13:03 PM UTC+2, Steven Berry wrote: >>> >>> With all that said I'm in favor

Re: Feature: Support Server-Sent Events

Hi Emil, while supporting server-sent events (or even websockets for that matter) would be great, this is basically a problem which has to be tackled in WSGI first in my opinion. That said, when you talk about a separate process, how would it look like (aside from using asycio), ie how would

Re: Feature: Support Server-Sent Events

On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote: > > Client A clicks a button on the site, that sends an normal ajax request to > Django. In the view a message is passed from Django to the SSE process. > How, you still need some kind of interprocess communication So the

Re: Making management forms for formsets optional

What about instead of trying to guess the forms from the input, just fix the one condition which causes the error and return 0 as totalformcount + an error marker to reraise the error in clean of the modelform? On Friday, June 5, 2015 at 11:29:21 AM UTC+1, Patryk Zawadzki wrote: > > Hi folks,

Re: Using `SECRET_KEY` in password hashers

FWIW the idea is relatively old and I think mozilla has a 3rd party app which just adds that functionality to the hashers. As far as I remember it even allows having multiple secrets and as such migrate to a new key. On Tuesday, June 9, 2015 at 7:16:02 AM UTC+2, Ram Rachum wrote: > > Hi, > >

Re: Django Admin - list_display default value

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

Re: And again about permission to view

On Tuesday, July 7, 2015 at 1:30:26 PM UTC+2, Григорий Крамаренко wrote: > > In fact, in versions 1.8 and 1.9 it is enough to simply add this > functionality without prejudice to existing and new projects. Simple patch >

Re: And again about permission to view

On Tuesday, July 7, 2015 at 5:25:38 PM UTC+2, Григорий Крамаренко wrote: > > So, as I said at the beginning - this change does not affect the admin > panel. > It absolutely does, cause if you assign the "view" permission to a user he should be able to see the changelist, which wouldn't be the

Re: And again about permission to view

On Wednesday, July 8, 2015 at 6:37:39 AM UTC+2, Григорий Крамаренко wrote: > > "view" absolutly not affect to the admin panel, just as do not affect to > it other custom permissions. > Yes it does and you are completely ignoring the link I sent -- this would be the first one where not having

Re: [ANNOUNCE] Django security releases issued (1.4.21, 1.7.9, and 1.8.3)

In [1]: int(' 5 ') Out[1]: 5 Cheers, Florian On Friday, July 10, 2015 at 12:00:20 PM UTC+2, tomv wrote: > > Out of interest what's wrong with casting to int and checking for > exceptions? > > This is the removed code: > > try: > int(value) > except (ValueError,

Re: Why Django is making migrations for external apps?

On Friday, July 17, 2015 at 6:31:20 PM UTC+2, Andrew Godwin wrote: > > > > On Fri, Jul 17, 2015 at 11:19 AM, James Bennett > wrote: > >> One option for declaring an app "unmanaged" could be via AppConfig. >> That's fairly clean, mirrors the way you can already set a model

Re: Support for UNLOGGED tables in PostgreSQL

The doc building process includes a linkchecker, if the link ceases to exist we will get notified (so the worst thing could be that the content changes to something completely different). On Tuesday, July 21, 2015 at 8:46:29 AM UTC+2, Christian Schmitt wrote: > > I mean I made the proposal, but

Re: Dynamic inlines for Django ModelAdmin

Doesn't get_inline_instances (https://github.com/django/django/blob/master/django/contrib/admin/options.py#L520) do exactly that? Cheers, Florian On Monday, July 27, 2015 at 7:33:58 AM UTC+2, Gert Steyn wrote: > > Hi All > > I've been using Django since before newforms-admin and have seen >

Re: Dynamic inlines for Django ModelAdmin

day 27 July 2015 10:57:41 Florian Apolloner wrote: > > Doesn't get_inline_instances > > ( > https://github.com/django/django/blob/master/django/contrib/admin/options. > > > py#L520) do exactly that? > > > > The request, as far as i understand, is to have the

Re: How to disable system check framework?

On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote: > > > I must try to do replacement or bring old behaviour of commit_manually() > with my custom wrapper. I'm trying to change code as less as possible. > To be honest the "issues" you outlined here seem to suggest a bigger

Re: Future of the development server's auto-reloading

On Saturday, August 8, 2015 at 11:53:32 PM UTC+2, Aymeric Augustin wrote: > > - It doesn’t survive a syntax error in the settings module. I have reasons > to believe that this would be extremely messy to fix. > - If a module reads a configuration file on disk at startup and caches it, > the

Re: how to get selectd checkboxes values in django from html?

This mailing list is for the development of Django itself, please write to django-users On Sunday, August 9, 2015 at 2:54:06 AM UTC+2, ghanshyam dudhatra wrote: > > > > > HOBBIES > > > Drawing >

Re: How to disable system check framework?

On Tuesday, August 25, 2015 at 6:19:44 PM UTC+2, Marcin Nowak wrote: > > Thanks, Carl. This specific error can solved by changing > 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in > INSTALLED_APPS. > This disables admin autodiscovery though, I doubt that is what you

Re: How to disable system check framework?

I think the fix for you currently is to put __your__ app before the admin app, this way your ready() will patch the user first and then the admin checks run. On Wednesday, August 26, 2015 at 9:06:07 AM UTC+2, Florian Apolloner wrote: > > > > On Tuesday, August 25, 2015 at 6:19

Re: How to disable system check framework?

Ups, not enough coffee yet, the admin.ready() just registers the checks, it does not execute them, so order should not matter -- I shall close my browser now and get some coffee :D On Wednesday, August 26, 2015 at 9:07:15 AM UTC+2, Florian Apolloner wrote: > > I think the fix for you cur

Re: Add DoNotTrack (DNT) middleware?

On Saturday, August 29, 2015 at 7:32:44 PM UTC+2, Alex_Gaynor wrote: > > I would say no: this does _so_ little, and it's completely implementable > outside of Django. Moreover, adding the middleware doesn't change any > behavior, you still have to do a bunch of work in your app to actually >

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

On Saturday, August 29, 2015 at 7:08:45 PM UTC+2, Tim Graham wrote: > > I can't think of a reason not to make the suggested change. It seems like > an odd requirement if a site *requires* allowing new usernames to be > case-sensitive. > Which is? Following the ticket I do not see any clear

Re: Adding more __repr__() methods

On Saturday, August 29, 2015 at 7:05:37 PM UTC+2, Tim Graham wrote: > > On the pull request, Fábio has raised the argument, "the __repr__ method > should be unambiguous and eval(repr(obj)) == obj" > While the python docs (?!) recommend that, I hardly ever see any object where you could eval

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote: > > The suggested change is to not allow a new user if there's a > username__iexact match. > Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is

<    1   2   3   4   5   6   7   8   9   >