Monday, November 2, 2015

Re: django-allauth facebook doesn't collect more information other than "name" and "id"

First you should add SCOPE and FIELDS keys to facebook settings (in file settings.py) to allow allauth your website capture other information

SOCIALACCOUNT_PROVIDERS = {
   
'facebook': {
       
'METHOD': 'oauth2',
       
'SCOPE': ['email', 'public_profile', 'user_friends'],
       
'AUTH_PARAMS': {'auth_type': 'reauthenticate'},
       
'FIELDS': [
           
'id',
           
'email',
           
'name',
           
'first_name',
           
'last_name',
           
'link',
           
'gender',
           
'updated_time'],

       
'EXCHANGE_TOKEN': True,
       
'VERIFIED_EMAIL': True,
       
'VERSION': 'v2.4'
   
}
}    

   

Next you should add signup signal handler. It will save extra info into database/ For example:

from allauth.account.signals import user_signed_up, user_logged_in

from django.dispatch import receiver


@receiver(user_signed_up)
def on_user_signed_up(request, user, sociallogin=None, **kwargs):

    if sociallogin:

        if sociallogin.account.provider == 'facebook':
            name = sociallogin.account.extra_data['name']
            user.email = sociallogin.account.extra_data['email']
            user.save()
            if sociallogin.account.extra_data['gender'] == 'male':
                gender = 'M'
            elif sociallogin.account.extra_data['gender'] == 'female':
                gender = 'F'
            user.create_profile(fullname=name, gender=gender)




понедельник, 2 ноября 2015 г., 14:27:32 UTC+2 пользователь Saleem Jaffer написал:
I tried adding facebook login to my application using django-allauth. Unfortunately the only fields that get captured are "name" and "id". All the other information is not captured.

This issue has already been addressed here: https://github.com/pennersr/django-allauth/issues/1061.

Supposedly, using django-allauth version 0.22 and higher should solve this. But I am using 0.23 and still the issue persists. 

Any help will be appreciated!

--
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+unsubscribe@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/ae3add24-5b57-4cd9-87b7-a2720d3cc3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with date validator

El 24/09/15 15:18, felix escribió:
El 23/09/15 17:12, felix escribió:

When today's date is entered in the form  it shows a form error saying that this date (today) is in the future.
What is wrong with the validator I'm using to allow dates until today?

models.py

...
import datetime

...

class SolicitudBase(models.Model):
    ....
    fecha = models.DateField(validators=[MaxValueValidator(datetime.date.today(), message="This date can't be in the future")])
    ....


I'm using Mysql and the following settings in my django project related to timezone are commented:

#TIME_ZONE = 'EST'
#USE_TZ = True

My server (debian 7) is using US/Eastern timezone.

and right now:
root@webapp:~# date
Wed Sep 23 17:04:36 EDT 2015

Thanks in advance,
Felix.

Thanks Simon for your suggestion.
I forgot to mention that it only happens with the present date (today) but it doesn't happen with past dates. So it makes me think it could be a time zone issue.
You were right Simon.
Using a custom validator instead of MaxValueValidator for dates solved my issue.

....
def validate_not_future_date(value):
    if value > datetime.date.today():
        raise ValidationError('%s is in the future' % value)

....
class SolicitudBase(models.Model):
    ....
    fecha = models.DateField(validators=[validate_not_future_date])



Thanks.

Re: How do I let forms.models.ModelChoiceField.queryset relate on request.user?

At least what I do in those cases is to add a constructor (__init__) to the form class which takes the user as a parameter, modify the choicefield queryset, and then call the original constructor of the form.

On Sun, Nov 1, 2015 at 3:50 PM, Axel Rau <Axel.Rau@chaos1.de> wrote:
User should see only choices related to him in a ModelChoiceField.
Do I need a fresh form per request?
What would be the best approach?

Thanks, Axel
---
PGP-Key:29E99DD6  ☀ +49 160 9945 7889  ☀ computing @ chaos claudius

--
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+unsubscribe@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/728C3EDF-62BB-4450-920B-BB7376417D9C%40Chaos1.DE.
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+unsubscribe@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/CALn3ei0v3POcwmw9s0beYyGXK15ybwDPooPsYDm%3D1_0XvpStpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translation is not working for Template even though po and mo files are created

Hi,

I am unsure about the project level translations path, if they should be found as well. I have added them manually to settings, but only that path. Application paths get imported automatically.

Regards,

Andréas

2015-11-02 6:38 GMT+01:00 Sean Xu <seanxu1984@gmail.com>:
Sorry, 

~/django-swingtime/django-swingtime-master/demo should be the project path where project level translation files were generated under ~/django-swingtime/django-swingtime-master/demo/locale.
The project level locale files should also be recognized, right?
The application path should be ~/django-swingtime/django-swingtime-master/demo/karate.

Br
Sean

On Sunday, November 1, 2015 at 6:09:02 PM UTC+8, Andréas Kühne wrote:
Hi Sean,

That's interesting. You shouldn't have to add the locale paths explicitly. Good that it's wokring, but as long as you put the locale files in a directory named locale under each app and also under the project, it should just work (as long as all apps are included in the config). Just check so that you follow the correct way of setting up a project.

Regards,

Andréas

2015-11-01 4:27 GMT+01:00 Sean Xu <seanx...@gmail.com>:
The translation for my template finally gets to work after I explicitly have LOCALE_PATHS configured in settings.py!!!!!
Thanks very much for providing the hint :)

Actually the models and template come from different applications:

~/django-swingtime/django-swingtime-master/swingtime # Models come from this swingtime application where translation worked.

~/django-swingtime/django-swingtime-master/demo # Templates come from this demo application where translation didn't work previously. (I'm running the server from demo folder actually... '~/django-swingtime/django-swingtime-master/demo> python manage.py runserver
')
It's weird demo was not recognized while swingtime was recognized for translation, though.

Br
Sean

On Friday, October 30, 2015 at 9:47:53 PM UTC+8, Andréas Kühne wrote:
Hmmm....

I'm a bit at a loss here. But does Django know where to find the .mo files? Is it only your template that isn't getting translated, because you said that the form itself is?

Regards,

Andréas

2015-10-30 12:45 GMT+01:00 Sean Xu <seanx...@gmail.com>:
Now I have corrected the orders of each Middleware class and removed the duplicated SessionMiddleware:
MIDDLEWARE_CLASSES = (
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.middleware.locale.LocaleMiddleware',
   
'django.middleware.common.CommonMiddleware',    
   
'django.contrib.auth.middleware.AuthenticationMiddleware',    
   
'django.contrib.messages.middleware.MessageMiddleware',
)
I also added django.core.context_processors.i18n as one of the context processors. (I just realized that I'm using Django version 1.7 something so django.template.context_processors.i18n should really be django.core.context_processors.i18n).
But unfortunately the translation for my template still does not work :(

On Friday, October 30, 2015 at 7:27:36 PM UTC+8, Sean Xu wrote:
Hi Andréas,

Thanks very much for providing the help.
Currently the middleware classes are configured like this:

MIDDLEWARE_CLASSES = (
   
'django.middleware.common.CommonMiddleware',
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.contrib.auth.middleware.AuthenticationMiddleware',
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.middleware.locale.LocaleMiddleware',
   
'django.contrib.messages.middleware.MessageMiddleware',
)

 I guess the order of these middleware is not correct because LocaleMiddleware should come before CommonMiddleware.

I have LANGUAGES defined in settings.py like this:
from django.utils.translation import ugettext_lazy as _

...
LANGUAGES
= (
 
('zh', _('Chinese')),
 
('en', _('English')),
)
And I don't have django.template.context_processors.i18n defined for TEMPLATE_CONTEXT_PROCESSORS in settings.py. Do I need to add this i18n context processor to settings.py?

Br
Sean

On Friday, October 30, 2015 at 6:07:21 PM UTC+8, Andréas Kühne wrote:
Hi,

Have you made sure that you have activated the languages you want in your application? 
Also, how is the current language being selected?

Regards,

Andréas

2015-10-30 7:45 GMT+01:00 Sean Xu <seanx...@gmail.com>:
Hi,

I'm learning Django Translation using django-swingtime with Django 1.7.9 installed.
I followed the official docs and embedded my string to translate with <title>{% trans "String to translate" %}</title> in my Template and managed to create both the po and mo files successfully.
But, the page is still shown up in English.
Note: the translation works just fine for my models.

Partly of the template I was using can be found from below:
{% extends "base.html" %}
{% load url from future %}
{% load i18n %}
{% block title %}Event Occurrence{% endblock %}
{% block main_content %}
     
<h3>{% trans "Swingtime Event Occurrence" %}</h3>
     
<h4>
         
<a href="{{ occurrence.event.get_absolute_url }}">{{ occurrence.title }}</a>
         
&ndash;
         
{% with occurrence.start_time as st  %}
         
<a href="{% url 'swingtime-daily-view' st.year st.month st.day %}">
           
{{ st|date:"l, F jS P" }}</a>
       
</h4>
        {% endwith %}
     <dl>
         <dt>{% trans "Event type:" %}</
dt>
         
<dd>{{ occurrence.event.event_type }}</dd>

The subroutine to render my Template is:
#-------------------------------------------------------------------------------
def occurrence_view(
    request
,
    event_pk
,
    pk
,
   
template='swingtime/occurrence_detail.html',
    form_class
=forms.SingleOccurrenceForm
):
   
'''
    View a specific occurrence and optionally handle any updates.
   
    Context parameters:
   
    ``occurrence``
        the occurrence object keyed by ``pk``


    ``form``
        a form object for updating the occurrence
    '''

 
    occurrence
= get_object_or_404(Occurrence, pk=pk, event__pk=event_pk)
   
if request.method == 'POST':
        form
= form_class(request.POST, instance=occurrence)
       
if form.is_valid():
            form
.save()
           
return http.HttpResponseRedirect(request.path)
   
else:  
        form
= form_class(instance=occurrence)
       
   
return render(request, template, {'occurrence': occurrence, 'form': form})

And the url configuration associated with the Template reads:
    url(
        r
'^events/(\d+)/(\d+)/$',
        views
.occurrence_view,
        name
='swingtime-occurrence'
   
),

Could some one help me solve this problem?
Thanks very much

Br
Sean

--
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/a45afc10-97ad-4574-b541-14ff67e892cd%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...@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/4c2d6bbe-c586-410c-8c61-338ecc01caf1%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...@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/a3d0f50f-a5dd-4d84-915d-3b31266eea9c%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+unsubscribe@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/8f46d82c-dcce-4bc3-a5ad-08060e04fddc%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+unsubscribe@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/CALXYUbmVcqMb0RL_L1Ut-mBLwMzej4_5Y%2B4FGb2A0yC%3D-rZ5RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Sunday, November 1, 2015

django- allauth facebook login does not return any information other than "name" and "id"

I have added django-auth to my application to authenticate a user via facebook. But on authentication, only the name and id is fetched. Other details like first_name, gender, etc are not fetched.

This issue has already been raised here: https://github.com/pennersr/django-allauth/issues/1061

I use django-allauth version 0.22.

But I still face the issue. Any help will be appreciated!

--
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+unsubscribe@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/440b823d-3e5a-4e3d-888c-f1dd8dbd5c03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django-allauth facebook doesn't collect more information other than "name" and "id"

I tried adding facebook login to my application using django-allauth. Unfortunately the only fields that get captured are "name" and "id". All the other information is not captured.

This issue has already been addressed here: https://github.com/pennersr/django-allauth/issues/1061.

Supposedly, using django-allauth version 0.22 and higher should solve this. But I am using 0.23 and still the issue persists. 

Any help will be appreciated!

--
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+unsubscribe@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/88a12817-f84c-49ad-affa-fee8ba74422e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translation is not working for Template even though po and mo files are created

Sorry, 

~/django-swingtime/django-swingtime-master/demo should be the project path where project level translation files were generated under ~/django-swingtime/django-swingtime-master/demo/locale.
The project level locale files should also be recognized, right?
The application path should be ~/django-swingtime/django-swingtime-master/demo/karate.

Br
Sean

On Sunday, November 1, 2015 at 6:09:02 PM UTC+8, Andréas Kühne wrote:
Hi Sean,

That's interesting. You shouldn't have to add the locale paths explicitly. Good that it's wokring, but as long as you put the locale files in a directory named locale under each app and also under the project, it should just work (as long as all apps are included in the config). Just check so that you follow the correct way of setting up a project.

Regards,

Andréas

2015-11-01 4:27 GMT+01:00 Sean Xu <seanx...@gmail.com>:
The translation for my template finally gets to work after I explicitly have LOCALE_PATHS configured in settings.py!!!!!
Thanks very much for providing the hint :)

Actually the models and template come from different applications:

~/django-swingtime/django-swingtime-master/swingtime # Models come from this swingtime application where translation worked.

~/django-swingtime/django-swingtime-master/demo # Templates come from this demo application where translation didn't work previously. (I'm running the server from demo folder actually... '~/django-swingtime/django-swingtime-master/demo> python manage.py runserver
')
It's weird demo was not recognized while swingtime was recognized for translation, though.

Br
Sean

On Friday, October 30, 2015 at 9:47:53 PM UTC+8, Andréas Kühne wrote:
Hmmm....

I'm a bit at a loss here. But does Django know where to find the .mo files? Is it only your template that isn't getting translated, because you said that the form itself is?

Regards,

Andréas

2015-10-30 12:45 GMT+01:00 Sean Xu <seanx...@gmail.com>:
Now I have corrected the orders of each Middleware class and removed the duplicated SessionMiddleware:
MIDDLEWARE_CLASSES = (
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.middleware.locale.LocaleMiddleware',
   
'django.middleware.common.CommonMiddleware',    
   
'django.contrib.auth.middleware.AuthenticationMiddleware',    
   
'django.contrib.messages.middleware.MessageMiddleware',
)
I also added django.core.context_processors.i18n as one of the context processors. (I just realized that I'm using Django version 1.7 something so django.template.context_processors.i18n should really be django.core.context_processors.i18n).
But unfortunately the translation for my template still does not work :(

On Friday, October 30, 2015 at 7:27:36 PM UTC+8, Sean Xu wrote:
Hi Andréas,

Thanks very much for providing the help.
Currently the middleware classes are configured like this:

MIDDLEWARE_CLASSES = (
   
'django.middleware.common.CommonMiddleware',
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.contrib.auth.middleware.AuthenticationMiddleware',
   
'django.contrib.sessions.middleware.SessionMiddleware',
   
'django.middleware.locale.LocaleMiddleware',
   
'django.contrib.messages.middleware.MessageMiddleware',
)

 I guess the order of these middleware is not correct because LocaleMiddleware should come before CommonMiddleware.

I have LANGUAGES defined in settings.py like this:
from django.utils.translation import ugettext_lazy as _

...
LANGUAGES
= (
 
('zh', _('Chinese')),
 
('en', _('English')),
)
And I don't have django.template.context_processors.i18n defined for TEMPLATE_CONTEXT_PROCESSORS in settings.py. Do I need to add this i18n context processor to settings.py?

Br
Sean

On Friday, October 30, 2015 at 6:07:21 PM UTC+8, Andréas Kühne wrote:
Hi,

Have you made sure that you have activated the languages you want in your application? 
Also, how is the current language being selected?

Regards,

Andréas

2015-10-30 7:45 GMT+01:00 Sean Xu <seanx...@gmail.com>:
Hi,

I'm learning Django Translation using django-swingtime with Django 1.7.9 installed.
I followed the official docs and embedded my string to translate with <title>{% trans "String to translate" %}</title> in my Template and managed to create both the po and mo files successfully.
But, the page is still shown up in English.
Note: the translation works just fine for my models.

Partly of the template I was using can be found from below:
{% extends "base.html" %}
{% load url from future %}
{% load i18n %}
{% block title %}Event Occurrence{% endblock %}
{% block main_content %}
     
<h3>{% trans "Swingtime Event Occurrence" %}</h3>
     
<h4>
         
<a href="{{ occurrence.event.get_absolute_url }}">{{ occurrence.title }}</a>
         
&ndash;
         
{% with occurrence.start_time as st  %}
         
<a href="{% url 'swingtime-daily-view' st.year st.month st.day %}">
           
{{ st|date:"l, F jS P" }}</a>
       
</h4>
        {% endwith %}
     <dl>
         <dt>{% trans "Event type:" %}</
dt>
         
<dd>{{ occurrence.event.event_type }}</dd>

The subroutine to render my Template is:
#-------------------------------------------------------------------------------
def occurrence_view(
    request
,
    event_pk
,
    pk
,
   
template='swingtime/occurrence_detail.html',
    form_class
=forms.SingleOccurrenceForm
):
   
'''
    View a specific occurrence and optionally handle any updates.
   
    Context parameters:
   
    ``occurrence``
        the occurrence object keyed by ``pk``


    ``form``
        a form object for updating the occurrence
    '''

 
    occurrence
= get_object_or_404(Occurrence, pk=pk, event__pk=event_pk)
   
if request.method == 'POST':
        form
= form_class(request.POST, instance=occurrence)
       
if form.is_valid():
            form
.save()
           
return http.HttpResponseRedirect(request.path)
   
else:  
        form
= form_class(instance=occurrence)
       
   
return render(request, template, {'occurrence': occurrence, 'form': form})

And the url configuration associated with the Template reads:
    url(
        r
'^events/(\d+)/(\d+)/$',
        views
.occurrence_view,
        name
='swingtime-occurrence'
   
),

Could some one help me solve this problem?
Thanks very much

Br
Sean

--
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/a45afc10-97ad-4574-b541-14ff67e892cd%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...@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/4c2d6bbe-c586-410c-8c61-338ecc01caf1%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...@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/a3d0f50f-a5dd-4d84-915d-3b31266eea9c%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+unsubscribe@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/8f46d82c-dcce-4bc3-a5ad-08060e04fddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.