Re: django.contrib.auth doesn't support template context processors?

[James Schneider]

The FBV's included in contrib.auth.views don't use RequestContext(), they
jump straight to TemplateResponse():

https://github.com/django/django/blob/master/django/contrib/auth/views.py#L192

IIRC, rendering a context via a RequestContext() is what triggers the
TEMPLATE_CONTEXT_PROCESSORS to run.

I could be wrong though, the docs are not really explicit as to what
triggers a call out to TEMPLATE_CONTEXT_PROCESSORS, and I haven't tested it.

Everything I do is in CBV's, so I always assume that RequestContext() is
used.

If it makes you feel better, I did try the same experiment using
auth.views.password_reset, and my TEMPLATE_CONTEXT_PROCESSORS didn't run
either, and work beautifully in my CBV's.

It's probably possible to wrap auth.views.auth.views.password_reset and
shoehorn in a RequestContext() or render call when it returns, but I
haven't needed/researched how to do so. That might also trigger rendering
of the template twice, which may be acceptable for performance for a low
usage page like a password reset form.

Better yet, you can wrap the view with your own FB view that simply calls
auth.views.auth.views.password_reset, passing in an extra_context={} as one of the view arguments. Probably
cleaner and keeps all the Django batteries intact. You might be able to do
it inside of your urls.py as well, although that might get a bit uglier.

https://docs.djangoproject.com/en/1.7/topics/auth/default/#django.contrib.auth.views.password_reset

I have no insight on future plans with anything in Django beyond the public
release notes.

-James

On Tue, Jan 20, 2015 at 6:50 AM, Mark Rogaski  wrote:

> And looking at the request using django-debug-toolbar, I confirmed that
> none of the context processors were applied to the templates.
>
>
> On Tuesday, January 20, 2015 at 8:26:22 AM UTC-5, Mark Rogaski wrote:
>>
>> Yes, I've appended it to the defaults.
>>
>> TEMPLATE_CONTEXT_PROCESSORS += (   'django.core.context_
>> processors.request',  )
>>
>> On Tuesday, January 20, 2015 at 7:43:54 AM UTC-5, Edgar Gabaldi wrote:
>>>
>>> did you register the context processor in settings?
>>>
>>> On Tue, Jan 20, 2015 at 3:32 AM, Mark Rogaski  wrote:
>>>
 Hello,

 I'm coming back to Django after working with 1.4/1.5.  Within a custom
 template for auth.views.password_reset, I'd like to access the request
 data using django.core.context_processors.request.  But it doesn't
 look like any template context processors are applied.

 It's not a big problem for me, but it seems that the contrib packages
 should support this ... it's really a lovely feature.  Has anyone else run
 into this or know if this is something that is slated to be added?

 Thanks,
 Mark

 --
 You received this message because you are subscribed to the Google
 Groups "Django users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-users...@googlegroups.com.
 To post to this group, send email to django...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-users.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%
 40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/bf857384-6699-49c7-a14f-3d6c6247eaa2%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciURZZjyswyWoed%3D-QumVmjS1VyPs1FUTC-Ap%3DiNHKpyFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Map Django Model to Legacy multi-join query

[James Schneider]

Not sure what you mean.

Are you looking to build the model definitions in your models.py files, or
are you trying to take the results of a query against MSSQL and pass them
to a constructor for a model that has already been defined?

Either way, eventually you'll end up with a copy of the 'model' in your
local DB assuming that you save the model, not sure if that is your
intention or not. And it likely will not be a fun process if the data sets
you are pulling do not have a similar structure to abstract into a unified
model (or couple of models), which sounds like it may be the case if you
have extensive data queries that both follow foreign keys or many-to-many
relationships.

-James



On Tue, Jan 20, 2015 at 8:02 AM, Fred  wrote:

> I've got a complex 1000+ table vendor read-only MS SqlServer database and
> only have SELECT privileges.  I can connect with pymssql no problem.
>
> Of all these tables, I probably care about 50 or less.
>
> I cannot create views unless I introduce another physical server and use
> the "Linked Server" option.  There are several administrative and
> performance hurdles to this.
>
> This DB is not clearly documented, so I have to explore and refine my
> SELECT statement for each query.  I'm typically ending up with 5...10 joins
> per query.
>
> Most relationships are Foreign Keys although a few are many-to-many.
>
> I've searched without success for a way to "encapsulate" a complex SELECT
> statement into a django model definition.
>
> Is there any way to do this within the django model framework?
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/8cc80725-083a-406e-a6cb-725ff6ac%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXBti6qnL1wiDcnfPyU8Z%2BcAm1dafL3j0Cjwju6ESMmaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help a newb with authentication and registration

[Ben Gorman]

@Collin Thanks a ton!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7ee4adea-b5ef-46db-83a3-3f0b647a1f7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Authentication when usernames are not unique

[James Schneider]

Wow, nice. You are probably right in not inheriting from PermissionMixin
and AbstractBaseUser and just re-implementing the needed functionality. I
ended up doing the same thing for my custom user and auth backend as well.
Not as convenient, but hey, it works right? ;-)

Bravo.

-James
On Jan 20, 2015 3:17 PM, "Erik Cederstrand" 
wrote:

> Ok, here's a stripped-down solution.
>
> I ended up creating a new SchoolUser user model with a OneToOne relation
> to my LegacyUser, to keep the LegacyUser model uncluttered. The SchoolUser
> implements all methods from AbstractBaseUser and PermissionsMixin but
> doesn't inherit from them, because I don't want the model fields that they
> contain.
>
> I also kept the SchoolUser independent from the standard Django User (i.e.
> no AUTH_USER_MODEL='SchoolUser' in settings.py), so I can still create
> superuser accounts for myself and my colleagues, that are not connected to
> a school user.
>
> Here's the code:
>
>
> settings.py:
> [...]
>
> AUTHENTICATION_BACKENDS = (
> 'django.contrib.auth.backends.ModelBackend',
> 'school_auth.backends.SchoolModelBackend',
> )
>
>
>
> school_auth/backend.py:
> from django.contrib.auth.backends import ModelBackend
> from .models import SchoolUser, LegacyUser
>
> class SchoolModelBackend(object):
> def authenticate(self, school_id=None, username=None, password=None, 
> **kwargs):
> if LegacyUser.validate(school=school_id, username=username, 
> password=password):
> # Password hash validation
> try:
> school_user = SchoolUser.objects.get(user__school=school_id, 
> user__name=username)
> except SchoolUser.DoesNotExist:
> school_user = 
> SchoolUser.objects.create_user(school_id=school_id, username=username)
> # Annotate the user object with the path of the backend.
> school_user.backend = "%s.%s" % (self.__class__.__module__, 
> self.__class__.__name__)
> return school_user
> #
> # if LDAP.validate(school=school_id, username=username, 
> password=password):
> # pass
> # if WAYF.validate(school=school_id, username=username, 
> password=password):
> # pass
> return None
>
> def get_group_permissions(self, user_obj, obj=None):
> raise NotImplementedError()
>
> def get_all_permissions(self, user_obj, obj=None):
> raise NotImplementedError()
>
> def has_perm(self, user_obj, perm, obj=None):
> if not user_obj.is_active:
> return False
> return perm in self.get_all_permissions(user_obj, obj)
>
> def has_module_perms(self, user_obj, app_label):
> if not user_obj.is_active:
> return False
> for perm in self.get_all_permissions(user_obj):
> if perm[:perm.index('.')] == app_label:
> return True
> return False
>
> def get_user(self, user_id):
> try:
> return SchoolUser.objects.get(pk=user_id)
> except SchoolUser.DoesNotExist:
> return None
>
>
>
> school_auth/forms.py:
> from django.contrib.auth.forms import AuthenticationForm,
> PasswordResetForm, PasswordChangeForm
> from django import forms
> from django.utils.translation import ugettext_lazy as _
> from django.utils.text import capfirst
> from .models import LegacyUser, School, SchoolUser
> from .backends import SchoolModelBackend
>
> class SchoolAuthenticationForm(AuthenticationForm):
> school = forms.ModelChoiceField(queryset=School.objects.active(), 
> empty_label=_('Please select a school'))
> username = forms.CharField(max_length=40)
> password = forms.CharField(label=_("Password"), 
> widget=forms.PasswordInput)
>
> class Meta:
> model = LegacyUser
>
> fields = ['school', 'name', 'password']
>
> def __init__(self, request=None, *args, **kwargs):
> """
> The 'request' parameter is set for custom auth use by subclasses.
> The form data comes in via the standard 'data' kwarg.
> """
> self.request = request
> self.user_cache = None
> super().__init__(*args, **kwargs)
>
> # Set the label for the "username" field.
> self.username_field = 
> LegacyUser._meta.get_field(SchoolUser.USERNAME_FIELD)
> if self.fields['username'].label is None:
> self.fields['username'].label = 
> capfirst(self.username_field.verbose_name)
>
> def clean(self):
> school = self.cleaned_data.get('school')
> username = self.cleaned_data.get('username')
> password = self.cleaned_data.get('password')
>
> if school and username and password:
> self.user_cache = 
> SchoolModelBackend().authenticate(school_id=school.pk, username=username,
>   
> password=password)
> if self.user_cache is None:
> 

Re: Authentication when usernames are not unique

[Erik Cederstrand]

Ok, here's a stripped-down solution.

I ended up creating a new SchoolUser user model with a OneToOne relation to my 
LegacyUser, to keep the LegacyUser model uncluttered. The SchoolUser implements 
all methods from AbstractBaseUser and PermissionsMixin but doesn't inherit from 
them, because I don't want the model fields that they contain.

I also kept the SchoolUser independent from the standard Django User (i.e. no 
AUTH_USER_MODEL='SchoolUser' in settings.py), so I can still create superuser 
accounts for myself and my colleagues, that are not connected to a school user.

Here's the code:


settings.py:
[...]
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'school_auth.backends.SchoolModelBackend',
)


school_auth/backend.py:
from django.contrib.auth.backends import ModelBackend
from .models import SchoolUser, LegacyUser
class SchoolModelBackend(object):
def authenticate(self, school_id=None, username=None, password=None, 
**kwargs):
if LegacyUser.validate(school=school_id, username=username, 
password=password):
# Password hash validation
try:
school_user = SchoolUser.objects.get(user__school=school_id, 
user__name=username)
except SchoolUser.DoesNotExist:
school_user = 
SchoolUser.objects.create_user(school_id=school_id, username=username)
# Annotate the user object with the path of the backend.
school_user.backend = "%s.%s" % (self.__class__.__module__, 
self.__class__.__name__)
return school_user
#
# if LDAP.validate(school=school_id, username=username, 
password=password):
# pass
# if WAYF.validate(school=school_id, username=username, 
password=password):
# pass
return None

def get_group_permissions(self, user_obj, obj=None):
raise NotImplementedError()
def get_all_permissions(self, user_obj, obj=None):
raise NotImplementedError()

def has_perm(self, user_obj, perm, obj=None):
if not user_obj.is_active:
return False
return perm in self.get_all_permissions(user_obj, obj)

def has_module_perms(self, user_obj, app_label):
if not user_obj.is_active:
return False
for perm in self.get_all_permissions(user_obj):
if perm[:perm.index('.')] == app_label:
return True
return False

def get_user(self, user_id):
try:
return SchoolUser.objects.get(pk=user_id)
except SchoolUser.DoesNotExist:
return None


school_auth/forms.py:
from django.contrib.auth.forms import AuthenticationForm, PasswordResetForm, 
PasswordChangeForm
from django import forms
from django.utils.translation import ugettext_lazy as _
from django.utils.text import capfirst
from .models import LegacyUser, School, SchoolUser
from .backends import SchoolModelBackend
class SchoolAuthenticationForm(AuthenticationForm):
school = forms.ModelChoiceField(queryset=School.objects.active(), 
empty_label=_('Please select a school'))
username = forms.CharField(max_length=40)
password = forms.CharField(label=_("Password"), widget=forms.PasswordInput)

class Meta:
model = LegacyUser
fields = ['school', 'name', 'password']

def __init__(self, request=None, *args, **kwargs):
"""
The 'request' parameter is set for custom auth use by subclasses.
The form data comes in via the standard 'data' kwarg.
"""
self.request = request
self.user_cache = None
super().__init__(*args, **kwargs)

# Set the label for the "username" field.
self.username_field = 
LegacyUser._meta.get_field(SchoolUser.USERNAME_FIELD)
if self.fields['username'].label is None:
self.fields['username'].label = 
capfirst(self.username_field.verbose_name)

def clean(self):
school = self.cleaned_data.get('school')
username = self.cleaned_data.get('username')
password = self.cleaned_data.get('password')

if school and username and password:
self.user_cache = 
SchoolModelBackend().authenticate(school_id=school.pk, username=username,
  
password=password)
if self.user_cache is None:
raise forms.ValidationError(
self.error_messages['invalid_login'],
code='invalid_login',
params={'username': self.username_field.verbose_name},
)
else:
self.confirm_login_allowed(self.user_cache)

return self.cleaned_data


school_auth/models.py:
from django.contrib.auth.models import PermissionsMixin, BaseUserManager, 
AbstractBaseUser
from django.db import models
from django.utils.translation import ugettext_lazy as _
from django.utils import timezone
from django.utils.crypto import 

Re: Is Django suitable for this purpose?

[Cal Leeming]

On Tue, Jan 20, 2015 at 10:43 PM, Avraham Serour  wrote:

> I'm not sure what kind of answers you expect by asking if django is the
> best tool on a django forum...
>

Actually, OP should expect impartial advice on suitability, as list
membership does not automatically mean devout follower.


>
> In any case, of course it is possible to do this in django, it all depends
> on you, django is just a framework but you still need to connect the dots
>

+1, although I would argue that there are already many hosted appointment
booking systems out there, you should probably use one of those services
instead. To make the two systems work, either make use of their webhooks,
or if they don't have any, then write a connector for them.


>
> the time lag would only depend on how you code your system and your
> resources, django should not be on your way
>
> good luck
>
> On Tue, Jan 20, 2015 at 11:52 PM, Mike Taylor  wrote:
>
>> I want to have an appointment booking option built into a website for a
>> clinic.
>>
>> The feature needs to integrate with the software that runs their office (
>> http://www.atlaschirosys.com/)
>>
>> In order to be fully useful, it would need to be virtually instantaneous
>> in filling the requested appointment spot.  A time lag of more than a
>> couple minutes would not be acceptable.
>>
>> So, is this even possible and is Django the best tool for building it?
>>
>> Thank you for ANY input.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/15b83a17-8329-4fe0-afde-6f7b40345528%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAFWa6tJ-2hkz7S8%3D1sJM1n-qz_bNC8WckyU6gXretwi_oxrAog%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHKQagHiQV15DZX6W%2B9gB6RLLQpVO-biJHGEUKVGU%3DJPQ%3Dx-tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is Django suitable for this purpose?

[Avraham Serour]

I'm not sure what kind of answers you expect by asking if django is the
best tool on a django forum...

In any case, of course it is possible to do this in django, it all depends
on you, django is just a framework but you still need to connect the dots

the time lag would only depend on how you code your system and your
resources, django should not be on your way

good luck

On Tue, Jan 20, 2015 at 11:52 PM, Mike Taylor  wrote:

> I want to have an appointment booking option built into a website for a
> clinic.
>
> The feature needs to integrate with the software that runs their office (
> http://www.atlaschirosys.com/)
>
> In order to be fully useful, it would need to be virtually instantaneous
> in filling the requested appointment spot.  A time lag of more than a
> couple minutes would not be acceptable.
>
> So, is this even possible and is Django the best tool for building it?
>
> Thank you for ANY input.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/15b83a17-8329-4fe0-afde-6f7b40345528%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tJ-2hkz7S8%3D1sJM1n-qz_bNC8WckyU6gXretwi_oxrAog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Is Django suitable for this purpose?

[Mike Taylor]

I want to have an appointment booking option built into a website for a 
clinic.

The feature needs to integrate with the software that runs their office 
( http://www.atlaschirosys.com/)

In order to be fully useful, it would need to be virtually instantaneous in 
filling the requested appointment spot.  A time lag of more than a couple 
minutes would not be acceptable.

So, is this even possible and is Django the best tool for building it?

Thank you for ANY input.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/15b83a17-8329-4fe0-afde-6f7b40345528%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re-Order rendering of input fields of django-contact-form?

[Paul Royik]

Try

def __init__(self, *args, **kwargs):
super(CustomContactForm, self).__init__(*args, **kwargs)
self.fields.keyOrder = ['name', 'reason', 'email', 'body']


On Tuesday, January 20, 2015 at 11:26:01 PM UTC+2, Tobias Dacoir wrote:
>
> I'm using django-contact-form which allows me to subclass it and add 
> custom fields to it. However all my added fields will appear at the bottom. 
> I even tried overwriting the original fields but still the order they 
> appear is wrong. How can I control this? I tried searching for an answer, 
> but only found ModelForm info that didn't work as the parent just inherits 
> from forms.Form and is not a ModelForm.
>
> Parent Class cound be found here: 
> https://bitbucket.org/ubernostrum/django-contact-form/src/4b7d2fa20c1d01568fb7c4c800155378e176923b/contact_form/forms.py?at=default
>
> My overwritten class:
> class CustomContactForm(ContactForm):
> REASON = (
> ('support', 'Support'),
> ('feedback','Feedback'),
> )
> reason = forms.ChoiceField(choices=REASON, label='Reason')
> name = forms.CharField(max_length=100,
>label=u'Your name')
> email = forms.EmailField(max_length=200,
>  label=u'Your email address')
> body = forms.CharField(widget=forms.Textarea,
>   label=u'Your message')
>
>
>
> and my template:
> {% extends 'base.html' %}
>
> {% block body_block %}
> Contact Form
>   To send us a message fill out the below form.
> {% csrf_token %}
> {{ form.as_p }}
> 
>   
> {% endblock %}
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6b0ae083-59df-48d6-bc29-f6f9ae6878af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing south and using sqlite3's :memory: ruins total test suite time

[Peter Bengtsson]

It seems, for some reason settings.COMPRESS_ENABLED gets set to False when 
south is installed. 

On Tuesday, January 20, 2015 at 12:37:44 PM UTC-8, Peter Bengtsson wrote:
>
> I have a django project on django 1.6. It's using django-nose and it's 
> using sqlite3's :memory: trick:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': ':memory:',
> }
> }
>
> Before I added `south` to INSTALLED_APPS it would take about ~5 seconds to 
> run the 371 tests. 
>
> So I add `south` to INSTALLED_APPS (and make sure django_nose is mentioned 
> last) and I also set SOUTH_TESTS_MIGRATE=False (meaning I can put things in 
> the the 0001_initial.py files and it doesn't get executed).
>
> Now it takes ~50 seconds to run the whole test suite. That's 10x times 
> slower! :(
>
> I ran the tests with nose-timer and it basically seems every test now gets 
> a lot slower. You can compare 
> https://gist.github.com/peterbe/34c9b14028d63429491c with 
> https://gist.github.com/peterbe/9202c20edee964a370d3
>
>
> Anybody know what's causing South (1.0.2) to make everything so much 
> slower?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0ea1c01f-d887-427e-a2d4-f3b2cbb97b4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re-Order rendering of input fields of django-contact-form?

[Tobias Dacoir]

I'm using django-contact-form which allows me to subclass it and add custom 
fields to it. However all my added fields will appear at the bottom. I even 
tried overwriting the original fields but still the order they appear is 
wrong. How can I control this? I tried searching for an answer, but only 
found ModelForm info that didn't work as the parent just inherits from 
forms.Form and is not a ModelForm.

Parent Class cound be found here: 
https://bitbucket.org/ubernostrum/django-contact-form/src/4b7d2fa20c1d01568fb7c4c800155378e176923b/contact_form/forms.py?at=default

My overwritten class:
class CustomContactForm(ContactForm):
REASON = (
('support', 'Support'),
('feedback','Feedback'),
)
reason = forms.ChoiceField(choices=REASON, label='Reason')
name = forms.CharField(max_length=100,
   label=u'Your name')
email = forms.EmailField(max_length=200,
 label=u'Your email address')
body = forms.CharField(widget=forms.Textarea,
  label=u'Your message')



and my template:
{% extends 'base.html' %}

{% block body_block %}
Contact Form
  To send us a message fill out the below form.
{% csrf_token %}
{{ form.as_p }}

  
{% endblock %}


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/725a9615-1d66-430a-8dbd-c7b1e70a7920%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing south and using sqlite3's :memory: ruins total test suite time

[Peter Bengtsson]

Quick update there,
I've figured out where the time is spent. Those ~45 seconds is caused by 
django_compressor calling out to `lessc` to convert .less files to .css. 

I'm now trying to figure out why having south in INSTALLED_APPS changes 
whether that gets run or not. It shouldn't run anything in runtime because 
I have `COMPRESS_OFFLINE = True` on and I run compress before running 
tests. 

On Tuesday, January 20, 2015 at 12:37:44 PM UTC-8, Peter Bengtsson wrote:
>
> I have a django project on django 1.6. It's using django-nose and it's 
> using sqlite3's :memory: trick:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': ':memory:',
> }
> }
>
> Before I added `south` to INSTALLED_APPS it would take about ~5 seconds to 
> run the 371 tests. 
>
> So I add `south` to INSTALLED_APPS (and make sure django_nose is mentioned 
> last) and I also set SOUTH_TESTS_MIGRATE=False (meaning I can put things in 
> the the 0001_initial.py files and it doesn't get executed).
>
> Now it takes ~50 seconds to run the whole test suite. That's 10x times 
> slower! :(
>
> I ran the tests with nose-timer and it basically seems every test now gets 
> a lot slower. You can compare 
> https://gist.github.com/peterbe/34c9b14028d63429491c with 
> https://gist.github.com/peterbe/9202c20edee964a370d3
>
>
> Anybody know what's causing South (1.0.2) to make everything so much 
> slower?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c119985d-b914-4e6d-88c5-de7cf04a080c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Installing south and using sqlite3's :memory: ruins total test suite time

[Peter Bengtsson]

I have a django project on django 1.6. It's using django-nose and it's 
using sqlite3's :memory: trick:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': ':memory:',
}
}

Before I added `south` to INSTALLED_APPS it would take about ~5 seconds to 
run the 371 tests. 

So I add `south` to INSTALLED_APPS (and make sure django_nose is mentioned 
last) and I also set SOUTH_TESTS_MIGRATE=False (meaning I can put things in 
the the 0001_initial.py files and it doesn't get executed).

Now it takes ~50 seconds to run the whole test suite. That's 10x times 
slower! :(

I ran the tests with nose-timer and it basically seems every test now gets 
a lot slower. You can compare 
https://gist.github.com/peterbe/34c9b14028d63429491c with 
https://gist.github.com/peterbe/9202c20edee964a370d3


Anybody know what's causing South (1.0.2) to make everything so much slower?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8f13473b-5a24-4546-b42e-8d1ab81b864c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Map Django Model to Legacy multi-join query

[Fred]

I've got a complex 1000+ table vendor read-only MS SqlServer database and 
only have SELECT privileges.  I can connect with pymssql no problem.

Of all these tables, I probably care about 50 or less.

I cannot create views unless I introduce another physical server and use 
the "Linked Server" option.  There are several administrative and 
performance hurdles to this.

This DB is not clearly documented, so I have to explore and refine my 
SELECT statement for each query.  I'm typically ending up with 5...10 joins 
per query.

Most relationships are Foreign Keys although a few are many-to-many.

I've searched without success for a way to "encapsulate" a complex SELECT 
statement into a django model definition.

Is there any way to do this within the django model framework?



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8cc80725-083a-406e-a6cb-725ff6ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.contrib.auth doesn't support template context processors?

[Mark Rogaski]

And looking at the request using django-debug-toolbar, I confirmed that 
none of the context processors were applied to the templates.

On Tuesday, January 20, 2015 at 8:26:22 AM UTC-5, Mark Rogaski wrote:
>
> Yes, I've appended it to the defaults.
>
> TEMPLATE_CONTEXT_PROCESSORS += (   '
> django.core.context_processors.request',  )
>
> On Tuesday, January 20, 2015 at 7:43:54 AM UTC-5, Edgar Gabaldi wrote:
>>
>> did you register the context processor in settings?
>>
>> On Tue, Jan 20, 2015 at 3:32 AM, Mark Rogaski  wrote:
>>
>>> Hello,
>>>
>>> I'm coming back to Django after working with 1.4/1.5.  Within a custom 
>>> template for auth.views.password_reset, I'd like to access the request 
>>> data using django.core.context_processors.request.  But it doesn't look 
>>> like any template context processors are applied.
>>>
>>> It's not a big problem for me, but it seems that the contrib packages 
>>> should support this ... it's really a lovely feature.  Has anyone else run 
>>> into this or know if this is something that is slated to be added?
>>>
>>> Thanks,
>>> Mark
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bf857384-6699-49c7-a14f-3d6c6247eaa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Binding model data to a formset without POST

[Rob Groves]

Hi All,
I am new to Django and am enjoying it very much.  Excellent documentation, 
tutorials, and general environment to work in.  Good job Django developers!

I have a question on binding data to a ModelFormset.  I have looked 
extensively and not seen this particular issue covered before.

I have a ModelFormset that I send to a template for custom rendering so I 
can present the fields in a controlled tabular format.  The ultimate goal 
is to use CSS to create a red bounding box around any fields with 
validation errors and to set the "title" attribute of those input fields so 
that the user can see what errors were generated  by hovering over the red 
bounded field.  This presents a nice clean interface when there are 
errors.  It all works great, with one annoyance if the model data starts 
out with values that will generate validation errors (i.e. missing required 
data).  

I initially call the view with a GET, which creates the forms and populates 
the form fields.  Since the data is not bound to forms at this point, I 
can't validate and set the errors.  In order to validate the fields and set 
the table error borders, I have to submit the form using POST to bind the 
data, validate the form and generate the errors which ultimately set an 
error_class for styling the table.  This means that I have to "save" the 
from from my form page to get the table style I want.

What I really want is to instantiate a ModelFormset, setting the instance, 
but then to bind the data present in the instance and set errors by sending 
is_valid() to the formset before rendering (i.e. on initial page rendering 
with the GET, so no POST data).  It seemed to me that there should simply 
be a bind_instance() function for all ModelFormsets that contain an 
instance.  I looked and didn't find that.  Eventually, I just decided to 
bind the data myself manually using the following helper function:

# helper functions
def bind_formset(formset):
bindData={}
# add management form data
bindData[formset.get_default_prefix()+"-TOTAL_FORMS"]=str(formset.
management_form['TOTAL_FORMS'].value())
bindData[formset.get_default_prefix()+"-INITIAL_FORMS"]=str(formset.
management_form['INITIAL_FORMS'].value())
bindData[formset.get_default_prefix()+"-MIN_NUM_FORMS"]=str(formset.
management_form['MIN_NUM_FORMS'].value())
bindData[formset.get_default_prefix()+"-MAX_NUM_FORMS"]=str(formset.
management_form['MAX_NUM_FORMS'].value())
for form in formset:
if form.instance:
for fieldName,fieldValue in form.fields.iteritems():
try:
bindData[form.add_prefix(fieldName)]=getattr(form.
instance,fieldName)
except:
# this is an added field, not derived from the model
pass
newFormset=formset.__class__(bindData,instance=formset.instance,
  queryset=formset.queryset, error_class=
formset.error_class)
return newFormset

This works!  My question... Is this a reasonable approach?  Or did I just 
miss the obvious way of doing this?

Thanks for any help!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ad0edd7f-b8ea-42c1-9d2f-4ef836bba703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.contrib.auth doesn't support template context processors?

[Mark Rogaski]

Yes, I've appended it to the defaults.

TEMPLATE_CONTEXT_PROCESSORS += (   '
django.core.context_processors.request',  )

On Tuesday, January 20, 2015 at 7:43:54 AM UTC-5, Edgar Gabaldi wrote:
>
> did you register the context processor in settings?
>
> On Tue, Jan 20, 2015 at 3:32 AM, Mark Rogaski  > wrote:
>
>> Hello,
>>
>> I'm coming back to Django after working with 1.4/1.5.  Within a custom 
>> template for auth.views.password_reset, I'd like to access the request 
>> data using django.core.context_processors.request.  But it doesn't look 
>> like any template context processors are applied.
>>
>> It's not a big problem for me, but it seems that the contrib packages 
>> should support this ... it's really a lovely feature.  Has anyone else run 
>> into this or know if this is something that is slated to be added?
>>
>> Thanks,
>> Mark
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5bc8d50f-13c0-42e5-92f4-1c3bd678dde2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

OneToOne field versus model inheritance

[Paul Royik]

I have three models: Person, Client, Member
Person is a base model, Client and Member are profiles for Person.

class Person(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(
verbose_name=_('email address'),
max_length=255,
unique=True,
)


class Client(User): #or maybe models.Model and explicit OneToField 
first_name = models.CharField(verbose_name=_('first name'), 
max_length=30)
last_name = models.CharField(verbose_name=_('last name'), max_length=30)

class Member(User): #or maybe models.Model and explicit OneToField 
description = models.CharField(verbose_name=_('first name'), 
max_length=255)
   # other stuff


So, what I want?
1. In admin, when we add client or member, I want to fill field email 
(fields from base class) as if it was in derived class. For example, in 
admin list_display = ('email', 'first_name'). Not select boxes for user.
2. Person class can be instantiated separately and the "attached" to the 
created profiel. Like person=Person(email="t...@gmail.com"), client = 
Client(person=person,first_name="test"...). Especially, this should work in 
forms. When user (person) is authenticated I want to give ability to fill 
in profile (client) form and attach person to this form.
3. One person can have both accounts. If I delete client/member, 
corresponding person should not be deleted.

3rd option actually is not necessary, but it is useful for me to know how 
to do it.

So, option 1 is perfectly solved by inheritance, Person is User, but this 
approach fails when option 2 is implemented. Since Person and Client is 
considered as one whole, I can't attach user, duplicate key error.
Option 2 is resolved by extending models.Model and appending 
person=models.OnetoOneField(Person,primary_key=True). However, admin is 
broken (1st option), because Client don't have fields like email.


So, what approach to take in order to solve above issues?
Are there simple ways?
If there are no simple ways, is there advanced way, like overriding 
metaclass, object descriptors or writing custom OneToOne field?

Any suggestions are welcomed.

Thank you. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/280bb9b1-f667-423d-81e3-4ea6e0c84c59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.contrib.auth doesn't support template context processors?

[Edgar Gabaldi]

did you register the context processor in settings?

On Tue, Jan 20, 2015 at 3:32 AM, Mark Rogaski  wrote:

> Hello,
>
> I'm coming back to Django after working with 1.4/1.5.  Within a custom
> template for auth.views.password_reset, I'd like to access the request
> data using django.core.context_processors.request.  But it doesn't look
> like any template context processors are applied.
>
> It's not a big problem for me, but it seems that the contrib packages
> should support this ... it's really a lovely feature.  Has anyone else run
> into this or know if this is something that is slated to be added?
>
> Thanks,
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAGjPPHmx3dMssdOOdTDCHy35hSV-TQoZfSrymYGmA_6Vm0a7qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: block php requests

[Avraham Serour]

you can tell apache to get any request ending with .php and return 404 from
apache without passing the request to django
you could return something else like 403 and ban the ip for some time

On Tue, Jan 20, 2015 at 1:55 PM, hinnack  wrote:

> Hi,
>
> I get a lot of intrusion checks on my website - especially for PHP
> (wordpress, joomla, …).
> Today they all raise a 404 errors in python-django - so if you have emails
> enabled for 404 errors…
>
> What is the best way to block those requests in a standard apache
> deployment?
> ( https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/modwsgi/ )
>
> regards
>
> Hinnack
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/6ae3fac4-4de2-4b26-8fce-aafb84c6a01a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tLK5_v3u5TVosTcdTKd5xumbVVm1oxLjrnJ%2BXdgu5LjcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why this code does not change users firstname and lastname?

[Jayadeep Karnati]

Looks like you really want to stick with normal forms. I see there is nothing 
wrong with the code you've posted. Can you also post the snippets of 
AdditionalCandidateInfo() and your template.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f978214f-62ca-474b-8309-4d801fa433a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django.contrib.auth doesn't support template context processors?

[Mark Rogaski]

Hello,

I'm coming back to Django after working with 1.4/1.5.  Within a custom 
template for auth.views.password_reset, I'd like to access the request data 
using django.core.context_processors.request.  But it doesn't look like any 
template context processors are applied.

It's not a big problem for me, but it seems that the contrib packages 
should support this ... it's really a lovely feature.  Has anyone else run 
into this or know if this is something that is slated to be added?

Thanks,
Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/df79e5ef-67e0-41fd-9ca1-af4d0eaefd4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

block php requests

[hinnack]

Hi,

I get a lot of intrusion checks on my website - especially for PHP 
(wordpress, joomla, …).
Today they all raise a 404 errors in python-django - so if you have emails 
enabled for 404 errors…

What is the best way to block those requests in a standard apache 
deployment?
( https://docs.djangoproject.com/en/1.7/howto/deployment/wsgi/modwsgi/ )

regards

Hinnack

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6ae3fac4-4de2-4b26-8fce-aafb84c6a01a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to check appname via Django commands?

[Sugita Shinsuke]

Hello Vijay

Thank you for replying.

But, I want to know the project name of django not app name.


2015年1月17日土曜日 23時18分46秒 UTC+9 Vijay Khemlani:
>
> What problem are you having exactly?
>
> Also I'm not sure what do you mean by "hierarchy" of the project folders, 
> do you mean the order the apps appear in the INSTALLED_APPS setting?
>
> On Sat, Jan 17, 2015 at 6:38 AM, Sugita Shinsuke  > wrote:
>
>> Hi there.
>>
>> I use Django 1.6 version.
>>
>> The database of Django store the information of application.
>> So, I know that if I  change the hierarchy of the Django project folders, 
>> some trouble occurs.
>> That is why, I'd like to check the name of my application.
>>
>> I think some of Django commands  like manage.py command can check the 
>> application name in the database of Django project.
>> Or, if you know other Django command. Could you tell me it?
>>
>> I would appreciate it if you would give me some advice.
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/4ea222eb-1fdd-44af-97c7-3f5bb05a13ef%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/bb475cbc-c48e-46eb-bfb0-9f92631056ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why this code does not change users firstname and lastname?

[Daniel Roseman]

On Monday, 19 January 2015 12:39:38 UTC, joulumaa wrote:
>
> Why would it make sense to switch from different form type?
> I use below form to get information that I like to save to user database?
> Part of information I need ot update goes to Additional user info class, I 
> would like to stay in my own form.
>
> -Thanks
>
>
Well you can do that with a ModelForm, but fair enough.

You haven't shown the rest of your view, or any of the form. Perhaps it is 
not valid? 
--
DR. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8f1b4f70-3100-4abd-bacf-0bbf678cb087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any reliable django stripe payments library

[Daniel Roseman]

On Tuesday, 20 January 2015 04:39:47 UTC, Chen Xu wrote:
>
> Hi Everyone,
> Is there any reliable django stripe payments library that does not require 
> to run a python manage.py syncdb? The reason I am asking is I am uaing 
> SQLAlchemy instead of its builtin ORM.
>
> Thanks
>

You don't need a Django library. You just need the standard Python Stripe 
library, which has the advantage of being both fully supported and fully 
documented in the API docs.
--
DR. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/712d5013-a864-4899-8c33-d2049af323ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.