Re: Why the extra minute in PostgreSQL when using time zone info?

[aRkadeFR]

Hey,

Indeed, the problem comes from the representation on PG,
cause I have only good results (0/30 for the minutes) from
the python function.

I don't get though why it is showing the wrong datetime.
@Avraham: It's not the representation of the timezone offset.
It's a false representation. He is not talking about the *+01*
at the end, but why it is 31 or 1 minute on the datetime.

Correct me if I'm wrong.

On 05/29/2015 08:42 AM, Avraham Serour wrote:

this is not an extra minute, it is a representation of the timezone offset

On Thu, May 28, 2015 at 11:42 PM, Daniel Grace > wrote:


I used this function, seemed to tidy up the problem:

from datetime import datetime
from pytz import timezone

def utcDtTm(self, dt_tm):
tz = timezone('Europe/London')
return
tz.normalize(tz.localize(dt_tm)).astimezone(timezone('UTC'))

-- 
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/12a0ab90-8108-46b4-8e90-5aadedbb3d2c%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/CAFWa6tJp2CLSSqzkiOMyGysGzxk%3DyhP2OD23toS1FOb43%3D%3D3Dg%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
aRkadeFR

--
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/55681EAB.9020602%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Gjango - debugging argument of type <> is not iterable

[Shekar Tippur]

Hello,

Acurl post request is throwing this error:

Request Method:POSTRequest URL:http://127.0.0.1:8000/setProfile/Django 
Version:1.8Exception Type:TypeErrorException Value:

argument of type 'ReadOnlyField' is not iterable

Exception 
Location:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/rest_framework/serializers.py
 
in _get_model_fields, line 1243Python Executable:
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4Python 
Version:3.4.3Python Path:

['/Users/PycharmProjects/screens',
 '/Users/PycharmProjects/screens',
 '/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip',
 '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4',
 '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin',
 '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload',
 '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages'



Appreciate any input on how to troubleshoot this.


- Shekar

-- 
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/7fbf5109-98ad-4f4b-a652-8ce4778aaf9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gjango - debugging argument of type <> is not iterable

[xutaoding . rose]

No
Note: you use 'ReadOnlyField' argument type is error, case modules call of 
django is incorrect

在 2015年5月29日星期五 UTC+8下午4:43:29，Shekar Tippur写道：
>
>
> Hello,
>
> Acurl post request is throwing this error:
>
> Request Method:POSTRequest URL:http://127.0.0.1:8000/setProfile/Django 
> Version:1.8Exception Type:TypeErrorException Value:
>
> argument of type 'ReadOnlyField' is not iterable
>
> Exception 
> Location:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/rest_framework/serializers.py
>  
> in _get_model_fields, line 1243Python Executable:
> /Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4Python 
> Version:3.4.3Python Path:
>
> ['/Users/PycharmProjects/screens',
>  '/Users/PycharmProjects/screens',
>  '/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip',
>  '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4',
>  
> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin',
>  
> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload',
>  
> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages'
>
>
>
> Appreciate any input on how to troubleshoot this.
>
>
> - Shekar
>
>

-- 
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/316e5f29-0721-4368-8e97-144a1cfb4dbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Having problem in assigning urls to different views

[akshat]

I have a project - 'django_test'.django_test root folder contains one app - 
'article',manage.py and django_test sub-folder. Inside django_test 
sub-folder I have urls.py -  

from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = [
# Examples:
# url(r'^$', 'django_test.views.home', name='home'),
# url(r'^blog/', include('blog.urls')),

url(r'^admin/', include(admin.site.urls)),
url(r'^hello/$',include('article.urls')),
url(r'^hello_template/$',include('article.urls')),
]


views.py inside article app looks like this - 

from django.shortcuts import render
from django.http import HttpResponse
from django.template.loader import get_template
from django.template import Context

def hello(request):
name = "Hello World"
html = " Hi,my name is %s" %name
return HttpResponse(html)

def hello_template(request):
name = "Akshat"
t = get_template('hello.html')
html = t.render(Context({"name":name}))
return HttpResponse(html)

I want to give two urls like this for the above mentioned views - 
'localhost:8000/hello/' and 'localhost:8000/hello_template'
urls.py inside article app right now looks like this - 

from django.conf.urls import url

from . import views

urlpatterns = [
url(r'^$',views.hello,name='hello'),
]

By this code If I give url - localhost:8000/hello,then it will look into 
django_test/urls.py and after finding r'^hello/$' it will go to 
article.urls.py and fetch the first url there which corresponds to hello 
class in views.py
I want to do the same steps for localhost:8000/hello_template url. But 
however after looking into django_test/urls.py and finding 
r'^hello_template/$' it will again go to article.urls.py and fetch the 
first url only which corresponds to hello class in views.py.How to point 
hello_template url to hello_template class in views.py.

-- 
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/ae9d8ed2-6759-4bb6-885f-20b9fa66c5c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Having problem in assigning urls to different views

[Galia Ladiray]

You need the second URL to be /hello/template/
and then it the article.urls you add
url(r'^template/$, views.hello_template,name='hello_template')


On Friday, May 29, 2015 at 12:05:47 PM UTC+2, akshat wrote:
>
> I have a project - 'django_test'.django_test root folder contains one app 
> - 'article',manage.py and django_test sub-folder. Inside django_test 
> sub-folder I have urls.py -  
>
> from django.conf.urls import include, url
> from django.contrib import admin
>
> urlpatterns = [
> # Examples:
> # url(r'^$', 'django_test.views.home', name='home'),
> # url(r'^blog/', include('blog.urls')),
>
> url(r'^admin/', include(admin.site.urls)),
> url(r'^hello/$',include('article.urls')),
> url(r'^hello_template/$',include('article.urls')),
> ]
>
>
> views.py inside article app looks like this - 
>
> from django.shortcuts import render
> from django.http import HttpResponse
> from django.template.loader import get_template
> from django.template import Context
>
> def hello(request):
> name = "Hello World"
> html = " Hi,my name is %s" %name
> return HttpResponse(html)
>
> def hello_template(request):
> name = "Akshat"
> t = get_template('hello.html')
> html = t.render(Context({"name":name}))
> return HttpResponse(html)
>
> I want to give two urls like this for the above mentioned views - 
> 'localhost:8000/hello/' and 'localhost:8000/hello_template'
> urls.py inside article app right now looks like this - 
>
> from django.conf.urls import url
>
> from . import views
>
> urlpatterns = [
> url(r'^$',views.hello,name='hello'),
> ]
>
> By this code If I give url - localhost:8000/hello,then it will look into 
> django_test/urls.py and after finding r'^hello/$' it will go to 
> article.urls.py and fetch the first url there which corresponds to hello 
> class in views.py
> I want to do the same steps for localhost:8000/hello_template url. But 
> however after looking into django_test/urls.py and finding 
> r'^hello_template/$' it will again go to article.urls.py and fetch the 
> first url only which corresponds to hello class in views.py.How to point 
> hello_template url to hello_template class in views.py.
>

-- 
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/c835367c-8a5b-47ee-86c6-159fc7ed457f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with customizing Django authentication

[Vishnuprabha Sridharan]

Hi,

Try this views.py 

from django.contrib.auth import authenticateuser = authenticate(username='', 
password='secret')if user is not None:
# the password verified for the user
if user.is_active:
print("User is valid, active and authenticated")
else:
print("The password is valid, but the account has been disabled!")else:
# the authentication system was unable to verify the username and password
print("The username and password were incorrect.")


On Wednesday, May 27, 2015 at 9:24:59 PM UTC+5:30, Carlos Ribas wrote:
>
> Hello All,
>
> I am currently extending the existing User model to store additional 
> information. So, basically I have:
>
> # models.py
> class Person(models.Model):
> user = models.OneToOneField(User, verbose_name=_('User'))
> zipcode = models.CharField(_('Zip Code'), max_length=9, blank=True, 
> null=True)
> street = models.CharField(_('Address'), max_length=255, blank=True, 
> null=True)
> ...
>
> #admin.py
> class PersonAdmin(admin.StackedInline):
> model = Person
> ...
>
> class UserAdmin(UserAdmin):
> inlines = (PersonAdmin, )
> ...
>
> admin.site.unregister(User)
> admin.site.register(User, UserAdmin)   
>
>
> The problem is that my system should be able to register a new person, but 
> this person may not need an account on the system (I just need to have 
> his/her information). Right now, I can not create a person without an 
> account. Besides that, first_name and last_name fields are not in the 
> person class. 
>
> I am wondering what is the best solution for my case. Probably, I will 
> need to move the first_name and last_name fields to the Person class, and 
> to do that, I will have to create custom users, is that right? 
>
> If that is the case, may I just copy and paste the lines shown here (
> https://github.com/django/django/blob/master/django/contrib/auth/models.py) 
> and remove the lines about first_name and last_name? 
>
> Well, any help will be appreciated.  
>
>
-- 
Confidentiality Notice: The above information contained in this email is 
intended for the confidential use of the above-named recipient(s). If a 
reader of this message is not the intended recipient or person responsible 
for delivering it to the intended recipient, you are hereby notified that 
you have received this communication in error, and that any review, 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this in error, please notify the sender 
immediately and destroy this message.**

-- 
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/14654226-722c-45c2-9692-997293f4dcf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with customizing Django authentication

[Vishnuprabha Sridharan]

hi ,

Try to use the django administration to create the user authentication with 
admin.py,views.py and forms.py

try by using this link:

https://docs.djangoproject.com/en/1.8/topics/auth/default/














On Wednesday, May 27, 2015 at 9:24:59 PM UTC+5:30, Carlos Ribas wrote:
>
> Hello All,
>
> I am currently extending the existing User model to store additional 
> information. So, basically I have:
>
> # models.py
> class Person(models.Model):
> user = models.OneToOneField(User, verbose_name=_('User'))
> zipcode = models.CharField(_('Zip Code'), max_length=9, blank=True, 
> null=True)
> street = models.CharField(_('Address'), max_length=255, blank=True, 
> null=True)
> ...
>
> #admin.py
> class PersonAdmin(admin.StackedInline):
> model = Person
> ...
>
> class UserAdmin(UserAdmin):
> inlines = (PersonAdmin, )
> ...
>
> admin.site.unregister(User)
> admin.site.register(User, UserAdmin)   
>
>
> The problem is that my system should be able to register a new person, but 
> this person may not need an account on the system (I just need to have 
> his/her information). Right now, I can not create a person without an 
> account. Besides that, first_name and last_name fields are not in the 
> person class. 
>
> I am wondering what is the best solution for my case. Probably, I will 
> need to move the first_name and last_name fields to the Person class, and 
> to do that, I will have to create custom users, is that right? 
>
> If that is the case, may I just copy and paste the lines shown here (
> https://github.com/django/django/blob/master/django/contrib/auth/models.py) 
> and remove the lines about first_name and last_name? 
>
> Well, any help will be appreciated.  
>
>
-- 
Confidentiality Notice: The above information contained in this email is 
intended for the confidential use of the above-named recipient(s). If a 
reader of this message is not the intended recipient or person responsible 
for delivering it to the intended recipient, you are hereby notified that 
you have received this communication in error, and that any review, 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this in error, please notify the sender 
immediately and destroy this message.**

-- 
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/8202e393-43cc-4510-8319-97ab88bb3845%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issues Upgrading to django 1.8 and migrating from south

[Tim Graham]

I guess you might have an old database created using the PostGIS template. 
See 
http://gis.stackexchange.com/questions/112592/installed-postgis-extension-not-listed-for-database

On Thursday, May 28, 2015 at 5:09:47 PM UTC-4, Marcela Campo wrote:
>
> Hi all,
>   I am upgrading an app from django 1.5 + south to 1.8. I am having some 
> issues when faking migrations with the recommended procedure here 
>
> https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south
>
> I am using postgres with postgis extension and engine 
>
>  'ENGINE': 'django.contrib.gis.db.backends.postgis',
>
>
> I followed the procedure indicated in the docs, solved circular 
> dependencies issues etc. I tried locally and worked fine, but now in 
> another environment I get the following error
>
>  File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>  
> line 338, in execute_from_command_line
> utility.execute()
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>  
> line 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/core/management/base.py",
>  
> line 390, in run_from_argv
> self.execute(*args, **cmd_options)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py",
>  
> line 41, in new_execute
> return original_func(self, *args, **kwargs)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/core/management/base.py",
>  
> line 441, in execute
> output = self.handle(*args, **options)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>  
> line 91, in handle
> connection.prepare_database()
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/contrib/gis/db/backends/postgis/base.py",
>  
> line 39, in prepare_database
> cursor.execute("CREATE EXTENSION IF NOT EXISTS postgis")
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/db/backends/utils.py",
>  
> line 79, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/db/backends/utils.py",
>  
> line 64, in execute
> return self.cursor.execute(sql, params)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/db/utils.py",
>  
> line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File 
> "/home/deploy/marcela-dev/src/hhenv_1_8/local/lib/python2.7/site-packages/django/db/backends/utils.py",
>  
> line 62, in execute
> return self.cursor.execute(sql)
> django.db.utils.InternalError: PostGIS is already installed in schema 
> 'public', uninstall it first
>
>
> my env is
>
> ubuntu 15.04
> python 2.7.9
> postgres 9.4.1
> Django==1.8.2
> psycopg2==2.6
>
>
> Any ideas why this could be happening? Any help appreciated!
>
> Thanks!
> Marcela
>
>
>
>

-- 
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/1c7f8d91-25f1-491a-8887-97e1ceeb2f69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

problem with requests and django view

[ogi]

Hi

I have problems to post some json data from a python script using *requests* 
to a django view defined as base classed view.
Thinking that problem is with permissions I also installed django rest 
framework to temporary allow any user to call the view.

the file with post data is looking like:

data = {'k1': 'val1', 'k2': 'val2'}
jdata = json.dumps(data)
r = requests.post(url, data=jdata, headers=headers)
print r

and the correspondign class based view registrated in urls.py:

class LoadData(APIView):

"""
A view that can accept POST requests with JSON content.
"""
parser_classes = (JSONParser,)
permission_classes = (AllowAny,)

def post(self, request, format=None):
# pdb.set_trace()

now the method post will be not executed.
When I use *put* method instead of *post* the situation is better but also 
without data
in request.data or args, kwargs.

I used many times jQuery with ajax and post method in similar cases and it 
was always working,
so I have no idea what is the difference and what I am missing.

Any hint will be very appreciated and thanks in advance.
Ogi



-- 
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/534487cb-1677-4cdf-bf2e-579f3c0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gjango - debugging argument of type <> is not iterable

[Shekar Tippur]

Hello,
Thanks for responding. I am not sure where in the code this is coming from. 
I have this code in my view. Not sure if this is the culprit. If it is, 
what is a better way to access this data.

class UserPrefSerializer(serializers.ModelSerializer):
class Meta:

*owner = serializers.ReadOnlyField(source='owner.username')*
model = UserPrefs
fields = (owner, 'name', 'value')
depth = 1


On Friday, 29 May 2015 03:05:33 UTC-7, xutaodi...@gmail.com wrote:
>
> No
> Note: you use 'ReadOnlyField' argument type is error, case modules call 
> of django is incorrect
>
> 在 2015年5月29日星期五 UTC+8下午4:43:29，Shekar Tippur写道：
>>
>>
>> Hello,
>>
>> Acurl post request is throwing this error:
>>
>> Request Method:POSTRequest URL:http://127.0.0.1:8000/setProfile/Django 
>> Version:1.8Exception Type:TypeErrorException Value:
>>
>> argument of type 'ReadOnlyField' is not iterable
>>
>> Exception 
>> Location:/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/rest_framework/serializers.py
>>  
>> in _get_model_fields, line 1243Python Executable:
>> /Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4Python 
>> Version:3.4.3Python Path:
>>
>> ['/Users/PycharmProjects/screens',
>>  '/Users/PycharmProjects/screens',
>>  '/Library/Frameworks/Python.framework/Versions/3.4/lib/python34.zip',
>>  '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4',
>>  
>> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin',
>>  
>> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload',
>>  
>> '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages'
>>
>>
>>
>> Appreciate any input on how to troubleshoot this.
>>
>>
>> - Shekar
>>
>>

-- 
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/e58d5ce3-211f-49fb-b9ec-f9d52d0d001d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why the extra minute in PostgreSQL when using time zone info?

[Carl Meyer]

Hi aRkadeFR,

On 05/29/2015 02:09 AM, aRkadeFR wrote:
> Indeed, the problem comes from the representation on PG,
> cause I have only good results (0/30 for the minutes) from
> the python function.
[snip]

The OP already found and posted the solution (see below) and it is not
related to Postgres. Here's a fuller explanation:

A pytz timezone class does not represent a single offset from UTC, it
represents a geographical area which, over the course of history, has
probably gone through several different UTC offsets. The oldest offset
for a given zone, representing the offset from before time zones were
standardized (in the late 1800s, most places) is usually called "LMT"
(Local Mean Time), and it is often offset from UTC by an odd number of
minutes.

When you create a timezone using `pytz.timezone('Europe/London')`, pytz
doesn't yet know what datetime you plan to attach the timezone object
to, so it doesn't know which historical period's offset it should use,
and it defaults to the first one in the zoneinfo database, which is
usually LMT:

>>> import pytz
>>> uktz = pytz.timezone('Europe/London')
>>> uktz


You can see that this timezone object is Europe/London _LMT_, and you
can also see that it is one minute offset from UTC (that's the "23:59:00
STD" bit).

The _wrong_ way to attach a pytz timezone to a naive Python datetime is
by passing it to the `tzinfo` argument of the datetime constructor (or
by using `.replace(tzinfo=...)`). When you do this, pytz literally
attaches the exact timezone offset (London LMT, dating from the
mid-1800s) to your datetime:

>>> from datetime import datetime
>>> lmt_dt = datetime(2015, 6, 11, 13, 30, tzinfo=uktz)
datetime.datetime(2015, 6, 11, 13, 30, tzinfo=)

If you convert this to UTC, you'll see the effect of that mysterious one
minute offset:

>>> lmt_dt.astimezone(pytz.utc)
datetime.datetime(2015, 6, 11, 13, 31, tzinfo=)

The _right_ way to attach a pytz timezone to a naive Python datetime is
to call `tzobj.localize(dt)`. This gives pytz a chance to say "oh, your
datetime is in 2015, so I'll use the offset for Europe/London that's in
use in 2015, rather than the one that was in use in the mid-1800s":

>>> good_dt = uktz.localize(datetime(2015, 6, 11, 13, 30))
>>> good_dt
datetime.datetime(2015, 6, 11, 13, 30, tzinfo=)

You can see that this datetime object is in BST (one hour offset from
UTC, at least in June) instead of LMT - a much better choice for this
century. And we can convert it to UTC and get a more sensible result:

>>> good_dt.astimezone(pytz.utc)
datetime.datetime(2015, 6, 11, 12, 30, tzinfo=)

Since we're on the Django list here, I should also point out that
`django.utils.timezone` has a `make_aware` method which handles this
correctly for you automatically.

Interesting historical sidenote: the 1-minute offset for London LMT is
based on historical observations such as this [1]:

# From Peter Ilieve (1994-07-06):
#
# On 17 Jan 1994 the Independent, a UK quality newspaper, had a piece about
# historical vistas along the Thames in west London. There was a photo
# and a sketch map showing some of the sightlines involved. One paragraph
# of the text said:
#
# 'An old stone obelisk marking a forgotten terrestrial meridian stands
# beside the river at Kew. In the 18th century, before time and longitude
# was standardised by the Royal Observatory in Greenwich, scholars observed
# this stone and the movement of stars from Kew Observatory nearby. They
# made their calculations and set the time for the Horse Guards and
Parliament,
# but now the stone is obscured by scrubwood and can only be seen by walking
# along the towpath within a few yards of it.'
#
# I have a one inch to one mile map of London and my estimate of the stone's
# position is 51 degrees 28' 30" N, 0 degrees 18' 45" W. The longitude
should
# be within about +-2". The Ordnance Survey grid reference is TQ172761.
#
# [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.]


Carl

[1] https://github.com/eggert/tz/blob/master/europe#L107


>> On Thu, May 28, 2015 at 11:42 PM, Daniel Grace > > wrote:
>>
>> I used this function, seemed to tidy up the problem:
>>
>> from datetime import datetime
>> from pytz import timezone
>>
>> def utcDtTm(self, dt_tm):
>> tz = timezone('Europe/London')
>> return
>> tz.normalize(tz.localize(dt_tm)).astimezone(timezone('UTC'))

-- 
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/55688D0F.9040602%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description:

Re: Django formset hidden id field

[Luis Zárate]

Mmm I am not sure of this but I guest that this number is not a primary key
(pk start in 1 not in 0 in  postgres and mysql), it is a formset control
number used by formset for group fields in the server side ( for create
forms in correct order also)


El miércoles, 27 de mayo de 2015, Matthias Müller 
escribió:
>> Just in general, is it a good idea to expose primary keys like this?
sometimes you can see them in urls too, like: www.yoursite/blog/1/,  1
would be the primary key of a blog.
>
> It's an easy way to refer to an object. Unless there is a secure
connection it's this is IMHO the best way to refer to the object.
> Of cause you can do it complicated ( with look up tables on the server
etc. )  but the result matters.
> And I like to keep my life and my apps simple <
https://mail.google.com/mail/e/softbank_ne_jp/337>
> 2015-05-27 16:05 GMT+02:00 Cheng Guo :
>>
>> Thank you! Yes, I forgot about the csrf. You are right, it would be
difficult to fake the CSRF string.
>> Just in general, is it a good idea to expose primary keys like this?
sometimes you can see them in urls too, like: www.yoursite/blog/1/,  1
would be the primary key of a blog.
>> On Wednesday, 27 May 2015 22:01:37 UTC+8, Matthias Müller wrote:
>>>
>>> Without looking at the link I guess that you explantion is more or less
correct.
>>> But it's not a security issue that the database is updated by a form.
It has to be updated by a form. To make it a correct django form there is a
hidden field with the CSRF token. This protects the database being updated
from any illegal source.
>>> In your example there is this csrf missing, Most probably for
didactical reasons.
>>> Refer to https://docs.djangoproject.com/en/1.8/ref/csrf/
>>> Cheers
>>> Matthias
>>> 2015-05-27 15:47 GMT+02:00 Cheng Guo :

 Hello,

 I have a formset and when I render it, Django would include this line
in the HTML:

 

 I am curious what is the purpose of having an id field here.

 I mean in what situation would you use it. I did look through
Django's documentation on formsetbut cannot find much documentation on this.

 One answer I got is that this id field is the value of the primary key
of the model bound to this form. It is there so that when the formset
updates, people can use it to retrieve the corresponding record from the
database.
 Is the above explaination correct?
 If this explaination is correct, then my next question is, wouldn't it
be dangerous to expose the primary key like that? I can make a post call to
your server with a modified pk which can mess up your database.
 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...@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/18e0d250-c4a9-4060-ae4f-19afb57566e0%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/285ee494-8b28-42cd-8af9-4cb33983a82c%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/CAA2xsHSSy03DSHaBfT4RNxv4zYJUBTdySLvg__mjMDheSemE4w%40mail.gmail.com
.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
"La utopía sirve para caminar" Fernando Birri

-- 
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/CAG%2B5VyMWvzFEYCR9KESXpqFYErbmX0XmYtOW_oReu4qs35b7Uw%40mail.gmail.com.
For more options, v

Re: Why the extra minute in PostgreSQL when using time zone info?

[aRkadeFR]

awesome explanation.

I was only aware of time zone information, and got to
understand the daylight saving time not that long ago.

Glad to know, after reading from you, the historical
differences on the time offset of the same geographical
area.

Have a good weekend :)

On 05/29/2015 06:00 PM, Carl Meyer wrote:

Hi aRkadeFR,

On 05/29/2015 02:09 AM, aRkadeFR wrote:

Indeed, the problem comes from the representation on PG,
cause I have only good results (0/30 for the minutes) from
the python function.

[snip]

The OP already found and posted the solution (see below) and it is not
related to Postgres. Here's a fuller explanation:

A pytz timezone class does not represent a single offset from UTC, it
represents a geographical area which, over the course of history, has
probably gone through several different UTC offsets. The oldest offset
for a given zone, representing the offset from before time zones were
standardized (in the late 1800s, most places) is usually called "LMT"
(Local Mean Time), and it is often offset from UTC by an odd number of
minutes.

When you create a timezone using `pytz.timezone('Europe/London')`, pytz
doesn't yet know what datetime you plan to attach the timezone object
to, so it doesn't know which historical period's offset it should use,
and it defaults to the first one in the zoneinfo database, which is
usually LMT:


import pytz
uktz = pytz.timezone('Europe/London')
uktz



You can see that this timezone object is Europe/London _LMT_, and you
can also see that it is one minute offset from UTC (that's the "23:59:00
STD" bit).

The _wrong_ way to attach a pytz timezone to a naive Python datetime is
by passing it to the `tzinfo` argument of the datetime constructor (or
by using `.replace(tzinfo=...)`). When you do this, pytz literally
attaches the exact timezone offset (London LMT, dating from the
mid-1800s) to your datetime:


from datetime import datetime
lmt_dt = datetime(2015, 6, 11, 13, 30, tzinfo=uktz)

datetime.datetime(2015, 6, 11, 13, 30, tzinfo=)

If you convert this to UTC, you'll see the effect of that mysterious one
minute offset:


lmt_dt.astimezone(pytz.utc)

datetime.datetime(2015, 6, 11, 13, 31, tzinfo=)

The _right_ way to attach a pytz timezone to a naive Python datetime is
to call `tzobj.localize(dt)`. This gives pytz a chance to say "oh, your
datetime is in 2015, so I'll use the offset for Europe/London that's in
use in 2015, rather than the one that was in use in the mid-1800s":


good_dt = uktz.localize(datetime(2015, 6, 11, 13, 30))
good_dt

datetime.datetime(2015, 6, 11, 13, 30, tzinfo=)

You can see that this datetime object is in BST (one hour offset from
UTC, at least in June) instead of LMT - a much better choice for this
century. And we can convert it to UTC and get a more sensible result:


good_dt.astimezone(pytz.utc)

datetime.datetime(2015, 6, 11, 12, 30, tzinfo=)

Since we're on the Django list here, I should also point out that
`django.utils.timezone` has a `make_aware` method which handles this
correctly for you automatically.

Interesting historical sidenote: the 1-minute offset for London LMT is
based on historical observations such as this [1]:

# From Peter Ilieve (1994-07-06):
#
# On 17 Jan 1994 the Independent, a UK quality newspaper, had a piece about
# historical vistas along the Thames in west London. There was a photo
# and a sketch map showing some of the sightlines involved. One paragraph
# of the text said:
#
# 'An old stone obelisk marking a forgotten terrestrial meridian stands
# beside the river at Kew. In the 18th century, before time and longitude
# was standardised by the Royal Observatory in Greenwich, scholars observed
# this stone and the movement of stars from Kew Observatory nearby. They
# made their calculations and set the time for the Horse Guards and
Parliament,
# but now the stone is obscured by scrubwood and can only be seen by walking
# along the towpath within a few yards of it.'
#
# I have a one inch to one mile map of London and my estimate of the stone's
# position is 51 degrees 28' 30" N, 0 degrees 18' 45" W. The longitude
should
# be within about +-2". The Ordnance Survey grid reference is TQ172761.
#
# [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.]


Carl

[1] https://github.com/eggert/tz/blob/master/europe#L107



On Thu, May 28, 2015 at 11:42 PM, Daniel Grace mailto:danwgr...@gmail.com>> wrote:

 I used this function, seemed to tidy up the problem:

 from datetime import datetime
 from pytz import timezone

 def utcDtTm(self, dt_tm):
 tz = timezone('Europe/London')
 return
 tz.normalize(tz.localize(dt_tm)).astimezone(timezone('UTC'))


--
aRkadeFR

--
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.

calling a view from a view doesnt clear the URL path

[dk]

I am doing something like this.
http://stackoverflow.com/questions/4808329/can-i-call-a-view-from-within-another-view

I have my original view that actually gets render as html.
the html have a button that runs another view. with all the logic to 
process the information. and at the end I want to return to the original 
view with an extra parameter. just a message saying that was successfully.

everything work perfect,  but the URL path at the top on the browser 
doesn't reset. still shows all the information that I passed to my second 
view.   still shows all the variables that I passed from the second url to 
the view. =(  
is there I way to reset that?





-- 
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/de221155-79ad-459c-9f5d-402fcf961abb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: calling a view from a view doesnt clear the URL path

[dk]

in the second view I am doing at the end.

return original_view(request, message="successfully")

-- 
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/72437253-30d5-4c6a-86f3-b87539621936%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gjango - debugging argument of type <> is not iterable

[Shekar Tippur]

If I change this to

class Meta:

*owner = serializers.ReadOnlyField(source='owner.username')*
model = UserPrefs
fields = ('owner', 'name', 'value')
depth = 1


I get a error: {"value":["This field is required."]}

-- 
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/4ca2351f-a31d-42ca-80b9-1ebe25513930%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

calling a view from a view doesnt clear the URL path

[Daniel Roseman]

Why should it? The browser requested the original view, and the code returned a 
response to that request. The browser doesn't know or care that the process of 
constructing that response involved calling another view function.

If you want to change the URL, instead of returning the result of another view, 
you should return a *redirect* to that view.

-- 
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/f041caab-c0cd-4d42-b12b-b2cf6928b659%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: calling a view from a view doesnt clear the URL path

[dk]

can I redirect with an argument?

On Friday, May 29, 2015 at 1:00:07 PM UTC-5, Daniel Roseman wrote:
>
> Why should it? The browser requested the original view, and the code 
> returned a response to that request. The browser doesn't know or care that 
> the process of constructing that response involved calling another view 
> function. 
>
> If you want to change the URL, instead of returning the result of another 
> view, you should return a *redirect* to that view. 
>
> -- 
> 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/908461ec-513e-4193-b465-00670074c366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: calling a view from a view doesnt clear the URL path

[Daniel Roseman]

You can redirect with whatever arguments you want, as long as the receiving URL 
accepts them.

-- 
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/66f5578e-fc4c-4422-a7cf-e98d60438ece%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: calling a view from a view doesnt clear the URL path

[dk]

so that redirect needs to be catch by the url,   interesting.

On Friday, May 29, 2015 at 1:22:40 PM UTC-5, Daniel Roseman wrote:
>
> You can redirect with whatever arguments you want, as long as the 
> receiving URL accepts them.

-- 
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/ef6e3139-e78b-43eb-b1c8-671f50a64eac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Trying to Build File Upload using jQuery dialog (jQuery 1.10.2/django 1.7/Python 2.7.8)

[Henry Versemann]

I'm constructing my file-upload dialog using jquery(jq)/javascript/html 
where the file-upload is supposed to begin like this:

   htmlStr = 'SELECT FILE TO 
UPLOAD:';
   jq("#upldfildialog").append(htmlStr); 

Everything seems to work except for actually being able to capture the file 
information that the user selects, from the file selection dialog, because 
when execution of the server-side code of my django application receives 
the request I'm trying to print out the value of "request.Files" and the 
app is printing this:

MultiValueDict:: {}

I'm sure its my code, that is the problem, but I just haven't yet figured 
out what little piece or pieces that I'm still missing to get this to work. 
I've done this before  several years ago, on another project, but don't 
have any complete working examples of it. I also still haven't found any 
other complete code examples thus far, in my search for possible solutions.

So any help would be greatly appreciated.

Thanks.

Henry



-- 
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/a1702fd3-43ee-4a1b-b17c-4a92f5ffdc39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with customizing Django authentication

[Carlos Ribas]

Hello,

I have to confess that I did not understand your suggestion. How this will 
help me to reverse the logic of my system? I mean, instead of User with or 
without a profile (the Person class, in my case), I want a Person with or 
without a User.

Thanks anyway

Em quarta-feira, 27 de maio de 2015 12:54:59 UTC-3, Carlos Ribas escreveu:
>
> Hello All,
>
> I am currently extending the existing User model to store additional 
> information. So, basically I have:
>
> # models.py
> class Person(models.Model):
> user = models.OneToOneField(User, verbose_name=_('User'))
> zipcode = models.CharField(_('Zip Code'), max_length=9, blank=True, 
> null=True)
> street = models.CharField(_('Address'), max_length=255, blank=True, 
> null=True)
> ...
>
> #admin.py
> class PersonAdmin(admin.StackedInline):
> model = Person
> ...
>
> class UserAdmin(UserAdmin):
> inlines = (PersonAdmin, )
> ...
>
> admin.site.unregister(User)
> admin.site.register(User, UserAdmin)   
>
>
> The problem is that my system should be able to register a new person, but 
> this person may not need an account on the system (I just need to have 
> his/her information). Right now, I can not create a person without an 
> account. Besides that, first_name and last_name fields are not in the 
> person class. 
>
> I am wondering what is the best solution for my case. Probably, I will 
> need to move the first_name and last_name fields to the Person class, and 
> to do that, I will have to create custom users, is that right? 
>
> If that is the case, may I just copy and paste the lines shown here (
> https://github.com/django/django/blob/master/django/contrib/auth/models.py) 
> and remove the lines about first_name and last_name? 
>
> Well, 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+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/f8930d9e-dc5d-4b7f-870b-404be70c82c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help with customizing Django authentication

[Carl Meyer]

Hello Carlos,

On 05/29/2015 03:19 PM, Carlos Ribas wrote:
> Hello,
> 
> I have to confess that I did not understand your suggestion. How this
> will help me to reverse the logic of my system? I mean, instead of User
> with or without a profile (the Person class, in my case), I want a
> Person with or without a User.
> 
> Thanks anyway
> 
> Em quarta-feira, 27 de maio de 2015 12:54:59 UTC-3, Carlos Ribas escreveu:
> 
> Hello All,
> 
> I am currently extending the existing User model to store additional
> information. So, basically I have:
> 
> # models.py
> class Person(models.Model):
> user = models.OneToOneField(User, verbose_name=_('User'))
> zipcode = models.CharField(_('Zip Code'), max_length=9,
> blank=True, null=True)
> street = models.CharField(_('Address'), max_length=255,
> blank=True, null=True)
> ...
> 
> #admin.py
> class PersonAdmin(admin.StackedInline):
> model = Person
> ...
> 
> class UserAdmin(UserAdmin):
> inlines = (PersonAdmin, )
> ...
> 
> admin.site.unregister(User)
> admin.site.register(User, UserAdmin)   
> 
> 
> The problem is that my system should be able to register a new
> person, but this person may not need an account on the system (I
> just need to have his/her information). Right now, I can not create
> a person without an account. Besides that, first_name and last_name
> fields are not in the person class. 
> 
> I am wondering what is the best solution for my case. Probably, I
> will need to move the first_name and last_name fields to the Person
> class, and to do that, I will have to create custom users, is that
> right? 

Yes, the best solution for your case (and for all Django projects) is to
use a custom User model.

In order to have every User linked to a Person, but not all Persons
linked to Users, you need to place the OneToOneField on the User model
pointing to Person, rather than the other way around. And in order to do
that, you need to have control over the User model.

(You _could_ sort of do it without a custom User model by having a
ManyToMany relationship between User and Person, but that allows a wide
variety of situations you don't want to allow.)

> If that is the case, may I just copy and paste the lines shown here
> 
> (https://github.com/django/django/blob/master/django/contrib/auth/models.py
> 
> )
> and remove the lines about first_name and last_name? 

No, you should follow the documentation on custom User models.

You'll want to inherit from AbstractBaseUser instead of AbstractUser, so
as to not have first_name and last_name fields. You'll need to add the
PermissionsMixin and probably a few other fields (including a username
field). The docs should explain what you need to know.

Carl

-- 
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/5568DFAC.8020800%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature