different behaviour of datetime.datetime object before vs after save

2015-09-23 Thread Alex Kleider

I'm baffled by the fact that the __str__ method of an instance fails
before the instance is saved but works fine afterwards.

The relevant snippet from my models.py file:
class Journal(models.Model):
date = models.DateTimeField(default=timezone.now)
user = models.CharField(max_length=24)
description = models.CharField(max_length=256)
def __str__(self):
ret = ["  #{:0>3} on {:<12} by {}."
.format(self.id,
self.date.strftime('%Y-%m-%d %H:%M'),
self.user)]
for line in self.description.split('\n'):
ret.append("{}".format(line))
return '\n'.join(ret)

Here's the result of some experimentation using the shell:
(venv)alex@x301:~/Py/debk$ ./manage.py shell
Python 3.4.0 (default, Jun 19 2015, 14:18:46)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)

from journal.models import Journal
j = Journal(user='Alex', description='Test entry')
j

Traceback (most recent call last):
  File "", line 1, in 
  File
"/home/alex/Py/venv/lib/python3.4/site-packages/django/db/models/base.py",
line 496, in __repr__
u = six.text_type(self)
  File "/home/alex/Py/debk/journal/models.py", line 22, in __str__
self.user)]
TypeError: non-empty format string passed to object.__format__

j.save()
j






I don't understand why saving would change the behavior of an instance.
I'd like my code to be able to display such an instance before a
decision is made whether or not to save it.
I'd be grateful if anyone could explain what's happening and perhaps
suggest a way to use the __str__ method before saving.

Thanks in advance for any help.

Alex K

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


Re: custom setting provided by myapp

2015-09-23 Thread Gergely Polonkai
Hello,

Most apps I know don't do such things. They write everything needed for
them to work in their docs, and if something is not set, they either work
with a sane default, or raise ImproperlyConfigured. I do the same myself.

Also, Python does this in general; it assumes you read the manual before
using something :)

Best,
Gergely
On 23 Sep 2015 23:20, "Bill Freeman"  wrote:

> If you have a system based on Django (some CMS for example), rather than
> an app for folks to add to a site that has a lot of unrelated stuff, then
> sure, generate one, but don't replace one that may have hours of
> customization work into it.  Let the site owner/tech do the merging.  If
> there are no settings when you install, then, yes, you could create the
> active settings file.  But you might find that difficult as Django versions
> change, or if you are going to allow it to work with the user's choice of
> Django version.  One possible approach is to read in the existing settings,
> see what it doesn't have that you need, and produce a file that the main
> settings file could import * from.
>
> On Wed, Sep 23, 2015 at 5:12 PM, Luis Zárate  wrote:
>
>> Hi,
>>
>> Sure, but why not auto-generate the setting file?, for example I know
>> various CMS than have an installer that provide a custom setting with
>> auto-generate configuration file (I don't know how to do that).
>>
>> Other idea is that my app can add configuration if is not set explicitly,
>> so the user have the possibility to change whatever he want and my app only
>> guarantee that run well most of time.
>>
>> 2015-09-23 12:10 GMT-06:00 Bill Freeman :
>>
>>> I would be upset to find an app that I installed fiddling with my
>>> project settings.
>>>
>>> On Wed, Sep 23, 2015 at 12:53 PM, Luis Zárate 
>>> wrote:
>>>
 Hi,

 l have an app than need other apps to run well, I create a requirements
 file and setup file and insert the required apps in my settings, also
 include my custom configurations.

 I want to build the settings file automatically (with installer script)
 or when the user put my app in his installed_apps automatically update the
 project settings with my custom apps settings.

 So what is the best approach for do that.



 --
 "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%2B5VyMutG68Dh2MuC1h7-uL%3DRzw6Y9v7RM33k5WN8qH-i3VAQ%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/CAB%2BAj0s%3Det%2B7%2BvHVcGGz%2BAkbQNWykHoMqzX6gO-XxxRTE0xmLQ%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%2B5VyMX_YcXaJuyNQi%2BQhfv7cepG5t4WXVnWM3eoyzyf5rV8w%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 t

[ANNOUNCE] Django 1.9 alpha 1 released

2015-09-23 Thread Tim Graham
We've made the first release on the way to Django's next major release, 
Django 1.9! With two and a half months until the scheduled final release, 
we'll need timely testing from the community to ensure an on-time and 
stable release. Check out the blog post:

https://www.djangoproject.com/weblog/2015/sep/23/django-19-alpha-1-released/


-- 
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/52e90bda-c1fc-49e0-ad82-6edeb4bb28cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django admin suitable for external users?

2015-09-23 Thread Luis Zárate
Sure, you could have several admin site with the same models.

I read an specific page about how to do that, but right now can remember
what is the specific url.

Those other links could help you.

https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#the-register-decorator
http://blog.tryolabs.com/2012/06/18/django-administration-interface-non-staff-users/

the specific class than provide admin site feature is django.contrib.admin.
sites.AdminSite

2015-09-23 15:44 GMT-06:00 Joshua Pokotilow :

> That's an interesting idea. Thanks.
>
> I suppose it's possible to register models with two different admin sites,
> although I've never tried doing that myself.
>
> On Wednesday, September 23, 2015 at 5:21:04 PM UTC-4, luisza14 wrote:
>>
>> I suggest you to create a custom admin site for your external user where
>> you expose only the models that interact with the external user and create
>> a middleware for forbidden access to the other admin site.
>>
>> 2015-09-23 14:49 GMT-06:00 Bill Freeman :
>>
>>> How technical are your users?
>>> What are your security constraints?
>>> How much work can you do to make it "pretty"?  (Believe me, someone will
>>> ask.)
>>> Are there fields that you want to administer internally but don't want
>>> to expose to the users?
>>> Will your users object if you decide to move to a newer Django version
>>> and the interface changes/
>>>
>>> You can make it work, but in many instances it will save you less effort
>>> than you though (might even be harder).
>>>
>>> A few custom views are pretty easy to roll out.
>>>
>>> On Wed, Sep 23, 2015 at 4:00 PM, Joshua Pokotilow 
>>> wrote:
>>>
 Hello! I just had a fairly lengthy conversation with my colleagues
 about whether or not Django admin is well-suited to external users outside
 our company. I took the position that for certain use-cases, exposing
 Django admin to third parties makes a lot of sense, given that the admin
 application has all kinds of features baked in that are well-suited to
 certain admin tasks (ACL, customizable templates, dynamically built CRUD
 forms, etc.). Unfortunately, I met with a lot of resistance on account of
 fears over ease of customizability, security, and technology lock-in.
 Furthermore, there was some concern that exposing Django admin to
 third-parties might send us off the beaten path, and that doing so could be
 an antipattern.

 I would appreciate knowing how other developers feel on this subject,
 and would love to hear about how some larger companies that use Django
 (Instagram, Disqus) think things through.

 Thanks.

 --
 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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%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/CAB%2BAj0tme%3DvZdzKBf5ygJRqtACozy2ugi5qyKjG5WHDWENkUWA%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/8f4edbde-28b5-4002-99e1-d08ea7c30f3b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-

Re: Problem with date validator

2015-09-23 Thread Simon Charette
Hi Felix,

The way you create your validator instance it is passed the
value returned by `date.today()` at module initialization time.
That is when the Python process starts.

It means that if you started your development server or say
a gunicorn process on your server yesterday the max value
the value will compare against will be yesterday and not the
actual date which is what I'm assuming you're trying to do
here.

Instead of relying on MaxValueValidator I suggest you write
your own by simply defining the following function and
passing in your field validators list.

def validate_past_date(value):
if value > datetime.date.today():
  raise ValidationError('This date can't be in the future')

Cheers,
Simon

Le mercredi 23 septembre 2015 17:06:54 UTC-4, felix a écrit :
>
>
> 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.
>

-- 
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/0112d817-7598-40c1-9fbc-4b5b1620b886%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django admin suitable for external users?

2015-09-23 Thread Joshua Pokotilow
That's an interesting idea. Thanks.

I suppose it's possible to register models with two different admin sites, 
although I've never tried doing that myself.

On Wednesday, September 23, 2015 at 5:21:04 PM UTC-4, luisza14 wrote:
>
> I suggest you to create a custom admin site for your external user where 
> you expose only the models that interact with the external user and create 
> a middleware for forbidden access to the other admin site.
>
> 2015-09-23 14:49 GMT-06:00 Bill Freeman >:
>
>> How technical are your users?
>> What are your security constraints?
>> How much work can you do to make it "pretty"?  (Believe me, someone will 
>> ask.)
>> Are there fields that you want to administer internally but don't want to 
>> expose to the users?
>> Will your users object if you decide to move to a newer Django version 
>> and the interface changes/
>>
>> You can make it work, but in many instances it will save you less effort 
>> than you though (might even be harder).
>>
>> A few custom views are pretty easy to roll out.
>>
>> On Wed, Sep 23, 2015 at 4:00 PM, Joshua Pokotilow > > wrote:
>>
>>> Hello! I just had a fairly lengthy conversation with my colleagues about 
>>> whether or not Django admin is well-suited to external users outside our 
>>> company. I took the position that for certain use-cases, exposing Django 
>>> admin to third parties makes a lot of sense, given that the admin 
>>> application has all kinds of features baked in that are well-suited to 
>>> certain admin tasks (ACL, customizable templates, dynamically built CRUD 
>>> forms, etc.). Unfortunately, I met with a lot of resistance on account of 
>>> fears over ease of customizability, security, and technology lock-in. 
>>> Furthermore, there was some concern that exposing Django admin to 
>>> third-parties might send us off the beaten path, and that doing so could be 
>>> an antipattern.
>>>
>>> I would appreciate knowing how other developers feel on this subject, 
>>> and would love to hear about how some larger companies that use Django 
>>> (Instagram, Disqus) think things through.
>>>
>>> Thanks.
>>>
>>> -- 
>>> 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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%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/CAB%2BAj0tme%3DvZdzKBf5ygJRqtACozy2ugi5qyKjG5WHDWENkUWA%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/8f4edbde-28b5-4002-99e1-d08ea7c30f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django admin suitable for external users?

2015-09-23 Thread Joshua Pokotilow

>
> How technical are your users?

Not very technical, necessarily. They're normal end-users.

What are your security constraints?

We're in the medical industry, so security is a key consideration for us in 
general. I think the main concerns about Django admin specifically were 
that it encompasses so much functionality, we might wind up shooting 
ourselves in the foot by failing to lock something down properly. Also, 
there might be discoverable exploits since it's an open source product.

How much work can you do to make it "pretty"?  (Believe me, someone will 
> ask.)
>
I believe the hope is that we wouldn't spend anymore time making it pretty 
than we would spend if we wrote our own custom HTML. We don't have strict 
style guidelines we would need to adhere to, except maybe for the header / 
footer.

Are there fields that you want to administer internally but don't want to 
> expose to the users?
>
Yes, but I think(?) this can be tailored to the logged-in user.

Will your users object if you decide to move to a newer Django version and 
> the interface changes/

I think it's possible they would, but perhaps not too much.

Thank you for the insights!


On Wednesday, September 23, 2015 at 4:50:28 PM UTC-4, ke1g wrote:
>
> How technical are your users?
> What are your security constraints?
> How much work can you do to make it "pretty"?  (Believe me, someone will 
> ask.)
> Are there fields that you want to administer internally but don't want to 
> expose to the users?
> Will your users object if you decide to move to a newer Django version and 
> the interface changes/
>
> You can make it work, but in many instances it will save you less effort 
> than you though (might even be harder).
>
> A few custom views are pretty easy to roll out.
>
> On Wed, Sep 23, 2015 at 4:00 PM, Joshua Pokotilow  > wrote:
>
>> Hello! I just had a fairly lengthy conversation with my colleagues about 
>> whether or not Django admin is well-suited to external users outside our 
>> company. I took the position that for certain use-cases, exposing Django 
>> admin to third parties makes a lot of sense, given that the admin 
>> application has all kinds of features baked in that are well-suited to 
>> certain admin tasks (ACL, customizable templates, dynamically built CRUD 
>> forms, etc.). Unfortunately, I met with a lot of resistance on account of 
>> fears over ease of customizability, security, and technology lock-in. 
>> Furthermore, there was some concern that exposing Django admin to 
>> third-parties might send us off the beaten path, and that doing so could be 
>> an antipattern.
>>
>> I would appreciate knowing how other developers feel on this subject, and 
>> would love to hear about how some larger companies that use Django 
>> (Instagram, Disqus) think things through.
>>
>> Thanks.
>>
>> -- 
>> 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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%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/b1e73edd-a4b5-440b-ac27-05e2ccfa4bae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django admin suitable for external users?

2015-09-23 Thread Luis Zárate
I suggest you to create a custom admin site for your external user where
you expose only the models that interact with the external user and create
a middleware for forbidden access to the other admin site.

2015-09-23 14:49 GMT-06:00 Bill Freeman :

> How technical are your users?
> What are your security constraints?
> How much work can you do to make it "pretty"?  (Believe me, someone will
> ask.)
> Are there fields that you want to administer internally but don't want to
> expose to the users?
> Will your users object if you decide to move to a newer Django version and
> the interface changes/
>
> You can make it work, but in many instances it will save you less effort
> than you though (might even be harder).
>
> A few custom views are pretty easy to roll out.
>
> On Wed, Sep 23, 2015 at 4:00 PM, Joshua Pokotilow 
> wrote:
>
>> Hello! I just had a fairly lengthy conversation with my colleagues about
>> whether or not Django admin is well-suited to external users outside our
>> company. I took the position that for certain use-cases, exposing Django
>> admin to third parties makes a lot of sense, given that the admin
>> application has all kinds of features baked in that are well-suited to
>> certain admin tasks (ACL, customizable templates, dynamically built CRUD
>> forms, etc.). Unfortunately, I met with a lot of resistance on account of
>> fears over ease of customizability, security, and technology lock-in.
>> Furthermore, there was some concern that exposing Django admin to
>> third-parties might send us off the beaten path, and that doing so could be
>> an antipattern.
>>
>> I would appreciate knowing how other developers feel on this subject, and
>> would love to hear about how some larger companies that use Django
>> (Instagram, Disqus) think things through.
>>
>> Thanks.
>>
>> --
>> 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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%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/CAB%2BAj0tme%3DvZdzKBf5ygJRqtACozy2ugi5qyKjG5WHDWENkUWA%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%2B5VyPdmtjHsy2igmFSESEBPFQSU5NAshGe3dY%3D3vrORR%3DuVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: custom setting provided by myapp

2015-09-23 Thread Bill Freeman
If you have a system based on Django (some CMS for example), rather than an
app for folks to add to a site that has a lot of unrelated stuff, then
sure, generate one, but don't replace one that may have hours of
customization work into it.  Let the site owner/tech do the merging.  If
there are no settings when you install, then, yes, you could create the
active settings file.  But you might find that difficult as Django versions
change, or if you are going to allow it to work with the user's choice of
Django version.  One possible approach is to read in the existing settings,
see what it doesn't have that you need, and produce a file that the main
settings file could import * from.

On Wed, Sep 23, 2015 at 5:12 PM, Luis Zárate  wrote:

> Hi,
>
> Sure, but why not auto-generate the setting file?, for example I know
> various CMS than have an installer that provide a custom setting with
> auto-generate configuration file (I don't know how to do that).
>
> Other idea is that my app can add configuration if is not set explicitly,
> so the user have the possibility to change whatever he want and my app only
> guarantee that run well most of time.
>
> 2015-09-23 12:10 GMT-06:00 Bill Freeman :
>
>> I would be upset to find an app that I installed fiddling with my project
>> settings.
>>
>> On Wed, Sep 23, 2015 at 12:53 PM, Luis Zárate  wrote:
>>
>>> Hi,
>>>
>>> l have an app than need other apps to run well, I create a requirements
>>> file and setup file and insert the required apps in my settings, also
>>> include my custom configurations.
>>>
>>> I want to build the settings file automatically (with installer script)
>>> or when the user put my app in his installed_apps automatically update the
>>> project settings with my custom apps settings.
>>>
>>> So what is the best approach for do that.
>>>
>>>
>>>
>>> --
>>> "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%2B5VyMutG68Dh2MuC1h7-uL%3DRzw6Y9v7RM33k5WN8qH-i3VAQ%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/CAB%2BAj0s%3Det%2B7%2BvHVcGGz%2BAkbQNWykHoMqzX6gO-XxxRTE0xmLQ%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%2B5VyMX_YcXaJuyNQi%2BQhfv7cepG5t4WXVnWM3eoyzyf5rV8w%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/CAB%2BAj0sDU80C3hPEr7YLyTE-LbtdjVuptn%2BTBBGq1eN0hMqZ%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: custom setting provided by myapp

2015-09-23 Thread Luis Zárate
Hi,

Sure, but why not auto-generate the setting file?, for example I know
various CMS than have an installer that provide a custom setting with
auto-generate configuration file (I don't know how to do that).

Other idea is that my app can add configuration if is not set explicitly,
so the user have the possibility to change whatever he want and my app only
guarantee that run well most of time.

2015-09-23 12:10 GMT-06:00 Bill Freeman :

> I would be upset to find an app that I installed fiddling with my project
> settings.
>
> On Wed, Sep 23, 2015 at 12:53 PM, Luis Zárate  wrote:
>
>> Hi,
>>
>> l have an app than need other apps to run well, I create a requirements
>> file and setup file and insert the required apps in my settings, also
>> include my custom configurations.
>>
>> I want to build the settings file automatically (with installer script)
>> or when the user put my app in his installed_apps automatically update the
>> project settings with my custom apps settings.
>>
>> So what is the best approach for do that.
>>
>>
>>
>> --
>> "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%2B5VyMutG68Dh2MuC1h7-uL%3DRzw6Y9v7RM33k5WN8qH-i3VAQ%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/CAB%2BAj0s%3Det%2B7%2BvHVcGGz%2BAkbQNWykHoMqzX6gO-XxxRTE0xmLQ%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%2B5VyMX_YcXaJuyNQi%2BQhfv7cepG5t4WXVnWM3eoyzyf5rV8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Problem with date validator

2015-09-23 Thread felix


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.

--
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/560315A9.4070509%40epepm.cupet.cu.
For more options, visit https://groups.google.com/d/optout.


Re: Django admin suitable for external users?

2015-09-23 Thread Bill Freeman
How technical are your users?
What are your security constraints?
How much work can you do to make it "pretty"?  (Believe me, someone will
ask.)
Are there fields that you want to administer internally but don't want to
expose to the users?
Will your users object if you decide to move to a newer Django version and
the interface changes/

You can make it work, but in many instances it will save you less effort
than you though (might even be harder).

A few custom views are pretty easy to roll out.

On Wed, Sep 23, 2015 at 4:00 PM, Joshua Pokotilow 
wrote:

> Hello! I just had a fairly lengthy conversation with my colleagues about
> whether or not Django admin is well-suited to external users outside our
> company. I took the position that for certain use-cases, exposing Django
> admin to third parties makes a lot of sense, given that the admin
> application has all kinds of features baked in that are well-suited to
> certain admin tasks (ACL, customizable templates, dynamically built CRUD
> forms, etc.). Unfortunately, I met with a lot of resistance on account of
> fears over ease of customizability, security, and technology lock-in.
> Furthermore, there was some concern that exposing Django admin to
> third-parties might send us off the beaten path, and that doing so could be
> an antipattern.
>
> I would appreciate knowing how other developers feel on this subject, and
> would love to hear about how some larger companies that use Django
> (Instagram, Disqus) think things through.
>
> Thanks.
>
> --
> 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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%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/CAB%2BAj0tme%3DvZdzKBf5ygJRqtACozy2ugi5qyKjG5WHDWENkUWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Django admin suitable for external users?

2015-09-23 Thread Joshua Pokotilow
Hello! I just had a fairly lengthy conversation with my colleagues about 
whether or not Django admin is well-suited to external users outside our 
company. I took the position that for certain use-cases, exposing Django 
admin to third parties makes a lot of sense, given that the admin 
application has all kinds of features baked in that are well-suited to 
certain admin tasks (ACL, customizable templates, dynamically built CRUD 
forms, etc.). Unfortunately, I met with a lot of resistance on account of 
fears over ease of customizability, security, and technology lock-in. 
Furthermore, there was some concern that exposing Django admin to 
third-parties might send us off the beaten path, and that doing so could be 
an antipattern.

I would appreciate knowing how other developers feel on this subject, and 
would love to hear about how some larger companies that use Django 
(Instagram, Disqus) think things through.

Thanks.

-- 
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/59231ea7-4bd1-41c2-97ef-f294a380bcb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Reverse for 'post_detail' with arguments '()' and keyword arguments '{'pk': 1}' not found. 1 pattern(s) tried:

2015-09-23 Thread Luis Zárate
As Remco said your problem are with your pattern because starts with $ or
have  ^*$*



[projectname]/
├── [projectname]/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py <--  The error is here
│   └── wsgi.py
└── manage.py
└── blog/
   └── __init__.py
   └── models.py
   └── managers.py
   └── views.py
   └── urls.py


In the urls.py do you have somethig like this ?

urlpatterns = patterns('',
url(*r'^$'*, include('blog.urls')),<--  The error is here
url(r'^admin/', include(admin.site.urls)),
)


2015-09-23 13:16 GMT-06:00 sankar vasu :

> Dear Luis,
>
> As you said, i tried but can't success.
>
> Thanks in advance
> Sankar B
>
> On Wed, Sep 23, 2015 at 12:29 AM, Luis Zárate  wrote:
>
>>
>> 2015-09-22 12:48 GMT-06:00 sankar vasu :
>>
>>> {{ post.title
>>> }}
>>
>>
>> try:
>>
>> {{ post.title }}
>>
>> If not found then check your project url.py , do you have something like
>>
>>
>> urlpatterns = [
>> url(r'^$', include('myapp.urls') ),
>> 
>> ]
>> --
>> "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%2B5VyPXAjmyVWj5jJzvX70%2BE0%3DLaAaXW4DpvoUdyLqrONxOpA%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> By,
>
> Sankar
>
> --
> 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/CAPzi0vD5xRApko4TJnXAtBm9R7xfOmpcRbObh8Pyjg6TSHa%2Bfw%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%2B5VyOOryjyV%2BpdMson%2BX3X3uxySuFh1FsEwyZfQoyoiG3Lkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Reverse for 'post_detail' with arguments '()' and keyword arguments '{'pk': 1}' not found. 1 pattern(s) tried:

2015-09-23 Thread sankar vasu
Dear Luis,

As you said, i tried but can't success.

Thanks in advance
Sankar B

On Wed, Sep 23, 2015 at 12:29 AM, Luis Zárate  wrote:

>
> 2015-09-22 12:48 GMT-06:00 sankar vasu :
>
>> {{ post.title
>> }}
>
>
> try:
>
> {{ post.title }}
>
> If not found then check your project url.py , do you have something like
>
>
> urlpatterns = [
> url(r'^$', include('myapp.urls') ),
> 
> ]
> --
> "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%2B5VyPXAjmyVWj5jJzvX70%2BE0%3DLaAaXW4DpvoUdyLqrONxOpA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
By,

Sankar

-- 
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/CAPzi0vD5xRApko4TJnXAtBm9R7xfOmpcRbObh8Pyjg6TSHa%2Bfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: custom setting provided by myapp

2015-09-23 Thread Bill Freeman
I would be upset to find an app that I installed fiddling with my project
settings.

On Wed, Sep 23, 2015 at 12:53 PM, Luis Zárate  wrote:

> Hi,
>
> l have an app than need other apps to run well, I create a requirements
> file and setup file and insert the required apps in my settings, also
> include my custom configurations.
>
> I want to build the settings file automatically (with installer script) or
> when the user put my app in his installed_apps automatically update the
> project settings with my custom apps settings.
>
> So what is the best approach for do that.
>
>
> --
> "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%2B5VyMutG68Dh2MuC1h7-uL%3DRzw6Y9v7RM33k5WN8qH-i3VAQ%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/CAB%2BAj0s%3Det%2B7%2BvHVcGGz%2BAkbQNWykHoMqzX6gO-XxxRTE0xmLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


custom setting provided by myapp

2015-09-23 Thread Luis Zárate
Hi,

l have an app than need other apps to run well, I create a requirements
file and setup file and insert the required apps in my settings, also
include my custom configurations.

I want to build the settings file automatically (with installer script) or
when the user put my app in his installed_apps automatically update the
project settings with my custom apps settings.

So what is the best approach for do that.


-- 
"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%2B5VyMutG68Dh2MuC1h7-uL%3DRzw6Y9v7RM33k5WN8qH-i3VAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 1.8 - It translates or it falls back when it should'nt...

2015-09-23 Thread Luis Zárate
I had the same problem with 1.8, l solved editing with external program
called poedit. I don't know why django build wrong po file, but when
compile the translation is not complete.

El miércoles, 23 de septiembre de 2015, PyMan 
escribió:
> Oh shame on me! I had this problem may years ago.here I go with the
ugettext_lazy
http://stackoverflow.com/questions/2694798/django-form-and-i18n/2694847#2694847
>
> Il giorno mercoledì 23 settembre 2015 14:23:38 UTC+2, PyMan ha scritto:
>>
>> Hi,
>>  I'm using django 1.8.4 with these settings
>>
>> LANGUAGE_CODE = 'en'
>>
>> ugettext = lambda s: s
>>
>> LANGUAGES = (
>> ('it', ugettext('LANG_ITALIANO')),
>> ('en', ugettext('LANG_INGLESE')),
>> )
>>
>> LOCALE_PATHS = (
>> 'C:/path1/locale',
>> 'C:/path2/locale',
>> )
>>
>> In both path1 and path2 I have "en/LC_MESSAGES/django.po/mo" and
"it/LC_MESSAGES/django.po/mo" where all the "msgid" defined in english are
also defined in italian (created by "makemessages") and all of them have
their "msgstr" compiled with some value (with PO edit and/or manually
edited), then compiled with "compilemessages".
>>
>> For example I have in "en/LC_MESSAGES/django.po"
>> msgid "TIPO_DOCUMENTO"
>> msgstr "Document type"
>>
>> and in "it/LC_MESSAGES/django.po"
>> msgid "TIPO_DOCUMENTO"
>> msgstr "Tipo documento"
>>
>> When using the site in english, the base language, all terms are
correctly in english, instead when I change the language via
django.views.i18n.set_language something really weird happens: some of the
terms (NOT EVERYONE) are not translated, and since django 1.8 introduced
fallback system about translations (
https://code.djangoproject.com/ticket/24739) I get the english msgstr for
"TIPO DOCUMENTO" that is "Document type".
>>
>> I have some other locale folders in some used django-apps, anyway none
of them contains that "msgid". The same is for the ones that are correctly
translated.
>>
>> Anyway if I set the base language to "it", it happens the same problem
for english when surfing in english.
>>
>> Why
>> 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/6d0945d6-e284-481d-b356-a5a508e9d34a%40googlegroups.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%2B5VyMMb-XU%3DWha2HJiussU0ffQ7WhkUbO0cJfzUKHPf6uB4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 1.8 - It translates or it falls back when it should'nt...

2015-09-23 Thread PyMan
Oh shame on me! I had this problem may years ago.here I go with the 
ugettext_lazy 
http://stackoverflow.com/questions/2694798/django-form-and-i18n/2694847#2694847

Il giorno mercoledì 23 settembre 2015 14:23:38 UTC+2, PyMan ha scritto:
>
> Hi,
>  I'm using django 1.8.4 with these settings
>
> LANGUAGE_CODE = 'en'
>
> ugettext = lambda s: s
>
> LANGUAGES = (
> ('it', ugettext('LANG_ITALIANO')),
> ('en', ugettext('LANG_INGLESE')),
> )
>
> LOCALE_PATHS = (
> 'C:/path1/locale',
> 'C:/path2/locale',
> )
>
> In both path1 and path2 I have "en/LC_MESSAGES/django.po/mo" and 
> "it/LC_MESSAGES/django.po/mo" where all the "msgid" defined in english are 
> also defined in italian (created by "makemessages") and all of them have 
> their "msgstr" compiled with some value (with PO edit and/or manually 
> edited), then compiled with "compilemessages".
>
> For example I have in "en/LC_MESSAGES/django.po"
> msgid "TIPO_DOCUMENTO"
> msgstr "Document type"
>
> and in "it/LC_MESSAGES/django.po"
> msgid "TIPO_DOCUMENTO"
> msgstr "Tipo documento"
>
> When using the site in english, the base language, all terms are correctly 
> in english, instead when I change the language via 
> django.views.i18n.set_language something really weird happens: some of the 
> terms (NOT EVERYONE) are not translated, and since django 1.8 introduced 
> fallback system about translations (
> https://code.djangoproject.com/ticket/24739) I get the english msgstr for 
> "TIPO DOCUMENTO" that is "Document type".
>
> I have some other locale folders in some used django-apps, anyway none of 
> them contains that "msgid". The same is for the ones that are correctly 
> translated.
>
> Anyway if I set the base language to "it", it happens the same problem for 
> english when surfing in english.
>
> Why
> 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/6d0945d6-e284-481d-b356-a5a508e9d34a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django 1.8 - It translates or it falls back when it should'nt...

2015-09-23 Thread PyMan
Hi,
 I'm using django 1.8.4 with these settings

LANGUAGE_CODE = 'en'

ugettext = lambda s: s

LANGUAGES = (
('it', ugettext('LANG_ITALIANO')),
('en', ugettext('LANG_INGLESE')),
)

LOCALE_PATHS = (
'C:/path1/locale',
'C:/path2/locale',
)

In both path1 and path2 I have "en/LC_MESSAGES/django.po/mo" and 
"it/LC_MESSAGES/django.po/mo" where all the "msgid" defined in english are 
also defined in italian (created by "makemessages") and all of them have 
their "msgstr" compiled with some value (with PO edit and/or manually 
edited), then compiled with "compilemessages".

For example I have in "en/LC_MESSAGES/django.po"
msgid "TIPO_DOCUMENTO"
msgstr "Document type"

and in "it/LC_MESSAGES/django.po"
msgid "TIPO_DOCUMENTO"
msgstr "Tipo documento"

When using the site in english, the base language, all terms are correctly 
in english, instead when I change the language via 
django.views.i18n.set_language something really weird happens: some of the 
terms (NOT EVERYONE) are not translated, and since django 1.8 introduced 
fallback system about translations 
(https://code.djangoproject.com/ticket/24739) I get the english msgstr for 
"TIPO DOCUMENTO" that is "Document type".

I have some other locale folders in some used django-apps, anyway none of 
them contains that "msgid". The same is for the ones that are correctly 
translated.

Anyway if I set the base language to "it", it happens the same problem for 
english when surfing in english.

Why
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/eda1a687-0c00-4a84-8761-269e021cbe5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Debugging Django using Pycharm

2015-09-23 Thread varun naganathan
Here's an article that might help:
https://www.jetbrains.com/pycharm/help/run-debug-configuration-django-test.html
Also PDB,the python debugger does a very good job of debuuging your Django 
App.
In case you've never used pdb,this should get you started:
https://gimmebar-assets.s3.amazonaws.com/4fe38b76be0a5.html

On Tuesday, September 15, 2015 at 12:35:00 PM UTC+5:30, Prabhu wrote:
>
>
> Hi Team,
>
> This is Prabhu just started using Django.
>
> I would like to know how to debug the code by attaching django application 
> which is running on server.
>
> Please share the Pycharm Setting and Steps to be followed.
>
> If you are recommend any other debug tool that too ok for me.
>
> Thanks and Regards,
>
> Prabhu
>

-- 
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/084581fb-e4d5-49fd-b814-2abab4834cbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


ANN: eGenix mxODBC Connect 2.1.4 - Remote Python Database Interface

2015-09-23 Thread eGenix Team: M.-A. Lemburg


ANNOUNCING

  eGenix.com mxODBC Connect

  Remote Python Database Interface

Version 2.1.4


 mxODBC Connect is our commercially supported client-server product for
   connecting Python applications to relational databases
 in a truly platform independent way.


This announcement is also available on our website for online reading:
http://www.egenix.com/company/news/eGenix-mxODBC-Connect-2.1.4-GA.html



INTRODUCTION

The mxODBC Connect Database Interface for Python allows users to
easily connect Python applications to all major databases on the
market today in a highly portable, convenient and secure way.

Python Database Connectivity the Easy Way
-

Building on our mxODBC database interface for Python, mxODBC Connect
is designed as client-server application, so you no longer need to
find production quality database drivers for all platforms you target
with your Python application.

Instead, you use an easy to install royalty-free Python client library
which connects directly to the mxODBC Connect database server over the
network.

This makes mxODBC Connect a great basis for writing cross-platform
multi-tier database applications and utilities in Python, especially
if you run applications that need to communicate with databases such
as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix,
Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many
more, that run on Windows or Linux machines.

Ideal for Database Driven Client Applications
-

By removing the need to install and configure ODBC drivers on the
client side and dealing with complicated network setups for each set
of drivers, mxODBC Connect greatly simplifies deployment of database
driven client applications, while at the same time making the network
communication between client and database server more efficient and
more secure.

For more information, please have a look at the mxODBC Connect product
page, in particular, the full list of available features.

For more information, please see the product page:

http://www.egenix.com/products/python/mxODBCConnect/



NEWS

mxODBC Connect 2.1.4 is a patch level release of our successful mxODBC
Connect database product. It includes these enhancements and fixes:

Security Enhancements
-

 * Updated included OpenSSL libraries to 1.0.1p. Please see the
   egenix-pyopenssl change log for a complete list of changes. Among
   other security fixes, this addresses the Logjam attack.

   http://www.egenix.com/products/python/pyOpenSSL/changelog.html

mxODBC Connect Enhancements
---

 * Added support for the BinaryNull work-around added to mxODBC 3.3.5
   in order to better support VARBINARY columns in MS SQL Server.

   Both mxODBC Connect Client and Server will need to upgraded to
   version 2.1.4 in order to be able to use the new singleton.

 * The mxODBC Connect Client can now be compiled to a wheel file to
   simplify deployment. Simply point the pip at the prebuilt archive.

mxODBC API Enhancements
---

 * Upgraded the mxODBC Connect Server to mxODBC 3.3.5:

   http://www.egenix.com/company/news/eGenix-mxODBC-3.3.5-GA.html

MS SQL Server
-

 * Documented and recommended use of SET NOCOUNT ON for running
   multiple statements or stored procedures. This can not only resolve
   issues with error reporting, it also results in better performance.

 * Added a work-around for MS SQL Server Native Client to be able to
   support VARCHAR/VARBINARY(MAX) columns when using the Native Client
   with direct execution mode or Python type binding mode. Thanks to
   ZeOmega for reporting this.

 * Added new helper singleton BinaryNull to allow binding a NULL to a
   VARBINARY column with SQL Server in direct execution mode or Python
   type binding mode (as used for FreeTDS). Using the usual None
   doesn't work in those cases, since SQL Server does not accept a
   VARCHAR data type as input for VARBINARY, except by using an
   explicit "CAST(? AS VARBINARY)". mxODBC binds None as VARCHAR for
   best compatibility, when not getting any type hints from the ODBC
   driver.

 * Added a fix for the MS SQL Server Native Client error
   "[Microsoft][ODBC Driver 11 for SQL Server][SQL Server]The data
   types varchar and text are incompatible in the equal to operator."
   when trying to bind a string of more than 256 bytes to a VARCHAR
   column while using cursor.executedirect(). cursor.execute() was
   unaffected by this. Thanks to Paul Perez for reporting this.

 * Added a note to avoid using "execute " when calling stored
   procedures with 

Re: Django oauth2 extend auth.user result in errors

2015-09-23 Thread Shekar Tippur
I have tried to 
follow 
https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#a-full-example 
and i get an error:

django.contrib.admin.sites.AlreadyRegistered: The model CustomUser is 
already registered

-- 
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/e6b28ad1-ec83-4084-9c15-c8e550c3932d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Django oauth2 extend auth.user result in errors

2015-09-23 Thread Shekar Tippur
I am sorry if this is a duplicate. I did post the same on Django REST 
Framework. I was not sure where I should post this.

I am trying to add some custom fields to oauth2. I am using python 3.4 and 
django 1.8.
I am having varying errors. But with the combination I got below, the error 
I get is

ERRORS:
logistics.CustomUser.user: (fields.E301) Field defines a relation with the 
model 'auth.User', which has been swapped out.
HINT: Update the relation to point at 'settings.AUTH_USER_MODEL'.
oauth2_provider.AccessToken.application: (fields.E304) Reverse accessor for 
'AccessToken.application' clashes with reverse accessor for 
'AccessToken.user'.
HINT: Add or change a related_name argument to the definition for 
'AccessToken.application' or 'AccessToken.user'.
oauth2_provider.AccessToken.user: (fields.E304) Reverse accessor for 
'AccessToken.user' clashes with reverse accessor for 
'AccessToken.application'.
HINT: Add or change a related_name argument to the definition for 
'AccessToken.user' or 'AccessToken.application'.
oauth2_provider.Grant.application: (fields.E304) Reverse accessor for 
'Grant.application' clashes with reverse accessor for 'Grant.user'.
HINT: Add or change a related_name argument to the definition for 
'Grant.application' or 'Grant.user'.
oauth2_provider.Grant.user: (fields.E304) Reverse accessor for 'Grant.user' 
clashes with reverse accessor for 'Grant.application'.
HINT: Add or change a related_name argument to the definition for 
'Grant.user' or 'Grant.application'.
oauth2_provider.RefreshToken.application: (fields.E304) Reverse accessor 
for 'RefreshToken.application' clashes with reverse accessor for 
'RefreshToken.user'.
HINT: Add or change a related_name argument to the definition for 
'RefreshToken.application' or 'RefreshToken.user'.
oauth2_provider.RefreshToken.user: (fields.E304) Reverse accessor for 
'RefreshToken.user' clashes with reverse accessor for 
'RefreshToken.application'.
HINT: Add or change a related_name argument to the definition for 
'RefreshToken.user' or 'RefreshToken.application'.


*Here is my model:*

from django.db import models
from django.contrib.auth.models import User
from oauth2_provider.models import AbstractApplication

from django.contrib.auth.models import AbstractUser,BaseUserManager, 
AbstractBaseUser,PermissionsMixin
from django.conf import settings
from django.contrib.auth import get_user_model


class CustomUser(AbstractUser):
some_additional_field = models.BooleanField(default=False)
user = models.OneToOneField(User, on_delete=models.CASCADE)


*Here is my settings.py*


import os

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.8/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'y_g)p7ut03#i&2zj5*$q06^f9yz%&#$wu78qn05(a88iuaa%gq'
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []

#print (os.path.join(os.path.dirname(__file__), 'template').replace('\\','/'))


# Application definition

INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'oauth2_provider',
'corsheaders',
'custom_user',
'rest_framework',
'logistics',
'rest_framework_swagger',
'debug_toolbar',
)

MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'oauth2_provider.middleware.OAuth2TokenMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'oauth2_provider.middleware.OAuth2TokenMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware',
'corsheaders.middleware.CorsMiddleware'
)

ROOT_URLCONF = 'logistics.urls'

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
],
},
},
]

OAUTH2_PROVIDER = {
'AUTHORIZATION_CODE_EXPIRE_SECONDS': 60 * 60,
'ACCESS_TOKEN_EXPIRE_SECONDS': 60 * 60 * 24 * 7,
# this is the list of available scopes
'SCOPES': {