Re: flatpages-tinymce

[Karl Arunachal]

Thank you.


On Sun, Jul 28, 2013 at 7:03 PM, Roberto López López
wrote:

>
> Your message is quite confusing and difficult to understand, I have to
> say. What are you asking for? To show tinymce within your change_form or
> within the admin app? What do you mean by "flat pages"? Which error are you
> getting?
>
>
>
>
> On 07/28/2013 08:35 AM, Karl Arunachal wrote:
>
>  Hello,
>  I am trying to use tinymce in the flat pages. But i just can't show it up
> in my admin. Please help me out where am going wrong.
>
> The javascript file is in:
>
> C:\Users\Kakar\web\cms\static\js\tinymce\tinymce.min.js
>
> urls.py:
>
> (r'^tiny_mce/(?P.*)$', 'django.views.static.serve', {
> 'document_root': 'C:/Users/Kakar/web/cms/static/js/tinymce' }),
>
> In my templates dir i have another admin folder, which have the
> change_form.html, and right after {{ media }}:
>
> 
> 
> tinyMCE.init({
> mode: "textareas",
> theme: "simple"
> });
> 
>
>  Please help me out. 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
> --
>
> Roberto López López
> System Developer
> Parallab, Uni Computing
> +47 55584091
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

background image

[Karl Arunachal]

Hello,
What do I do to let user upload their own images, and as use it as their
profile's background.
I am out of clue. Please advice me.

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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: South migration ordering on different timeline

[Nora Olsen]

Another issue is that once I create a new schemamigration --auto for 006 in 
my master, there are alot of changes in the migration files. 

Is this because of the serialized model inside 005?



On Tuesday, July 30, 2013 12:28:37 PM UTC+8, Nora Olsen wrote:
>
> Hi,
>
> I'm using git-flow and I use the develop and master branches. 
>
> Since I had to move features ahead of schedule and bring forward to 
> production, I had to cherry-pick[1] them into the master branch.
>
> The south migration scripts are not in order anymore and and staging box 
> is up to date with the develop branch. 
>
> For example:
> Develop 001-002-003-004-005
> Master 001-002--004-005
>
> Staging box: 001-002-003-004-005
> Master box: 001-002--004-005
>
> 1. When I merge develop into master, what will happen to 003 migration 
> script when I deploy to my production box?
>
> 2. I guess the staging box will be fine when I merge master back into 
> develop since all the migration scripts have been applied?
>
> Thanks!
> [1] 
> http://stackoverflow.com/questions/17919408/bringing-selective-changes-from-develop-to-master
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django not enforcing blank=False on a model

[Jani Tiainen]

On Mon, 29 Jul 2013 18:14:50 -0700 (PDT)
Knight Samar  wrote:

> Hi,
> 
> I have a model
> 
> > from django.db import models
> >
> > class Organization(models.Model):
> > name = models.CharField(max_length=100,
> > blank = False,  #mandatory
> > help_text = "Name of your Organization",
> > verbose_name = '',
> > unique = True,
> > primary_key = True,
> > )
> >
> >
> and a piece of code
> 
> > from organization.models import Organization
> > o = Organization.objects.create() 
> > o.save() 
> 
> 
> which works *without raising an IntegrityError!* And the following also 
> works just the same!
> 
> > from organization.models import Organization
> > o = Organization() 
> 
> o.save() 
> 
> 
> I am using SQLite3(SQLite 3.7.9 2011-11-01 00:52:41 
> c7c6050ef060877ebe77b41d959e9df13f8c9b5e) as the database backend and it 
> shows the following as the schema:
> 
> CREATE TABLE "organization_organization" ( "name" varchar(100) NOT NULL 
> > PRIMARY KEY ); 
> 
>  
> Even if SQLite3 was buggy, shouldn't Django itself enforce the constraint 
> on ORM layer ?
> 
> I have deleted .pyc files and also the .sqlite3 file before testing again. 
> I am using Django 1.5.1
> 
> What am I missing ? Why is Django *NOT* enforcing blank=False ?

Blank is for input fields. It means that when validating form input value 
cannot be blank. And by default django uses empty string to denote empty 
charfield, not null. (Except Oracle)

>From 
>:
"Note that this is different than null. null is purely database-related, 
whereas blank is validation-related. If a field has blank=True, form validation 
will allow entry of an empty value. If a field has blank=False, the field will 
be required."

Also, you should note that .save() doesn't imply running validation 


-- 

Jani Tiainen

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 Feature Suggestion

[JJ Zolper]

My apologies for not making this quickly accessible. I meant to stick the 
link in there but it didn't make it into my previous post. It's been a long 
day. Here it is:

https://github.com/Liberationtech/django-libtech-emailuser

JJ

On Monday, July 29, 2013 9:07:43 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 30, 2013 at 8:37 AM, JJ Zolper 
> > wrote:
>
>> Russell Keith-Magee,
>>
>> Are you the one who is doing "Getting Started With Django" ? Sorry for 
>> getting off topic but just was curious. If so I donated money to that 
>> project and I am glad you are doing it.
>>
>
> Sorry, that's not me. You're thinking of Kenneth Love (@kennethlove on 
> twitter).
>  
>
>> Yes, that's what it seems to be called by other Django devs, "Email 
>> address as username." I prefer more to think of it as just "Email" with the 
>> same exact login handlign as "Username." That's my goal with this post is 
>> keep pushing until the point is reached where we can just call it "Email" 
>> login. I also think it is such a common case that it should be within 
>> Django's core. It is obvious from the large number of posts online about 
>> replacing the username with an email. 
>>
>
> A lot of those posts will be from pre-1.5 days; having the ability to 
> easily use an email address as a username was one of the primary 
> motivations behind introducing swappable users as a new feature. It was 
> always possible; in Django 1.5, it's a lot easier; the next step is to make 
> it trivial by having a custom user model for that purpose available in the 
> box.
>
> If you have heard Jacob discussing it before, that would be wonderful! It 
>> would be awesome if the Django guys accepted this into Django all together. 
>> Given it must be considered with the release of Django 1.5 they did give a 
>> lot more support to people like me trying to have the email as the username 
>> through things like:
>>
>> class CustomUser(AbstractBaseUser, PermissionsMixin):
>>  
>>  email = models.EmailField(max_length=255, unique=True)
>>  
>>
>>  objects = CustomUserManager()
>>
>>  USERNAME_FIELD = 'email'
>>
>>
>> So maybe Jacob and Adrian are already on top of this. 
>>
>
> Jacob and Adrian are only "on top of it" in the sense that Jacob has said 
> it's a good idea. I wouldn't hang around waiting for either of them to 
> commit such a patch -- they're both busy, and don't spend a lot of time 
> committing to Django itself these days. 
>  
>
>> The only thing I have been trying to do is follow the suggestions of 
>> those posts I have found online. I could surely route some possible people 
>> I think might have already banged this out but I'm not sure I'm the best 
>> bet. However, I did go ahead and open a ticket:
>>
>> https://code.djangoproject.com/ticket/20824
>>
>> Thanks again to all the Django developers for their hard work,
>>
>
> Thanks for opening a ticket and driving the discussion. I've added some 
> comments to the ticket and marked it as accepted; next step is a patch :-)
>
> Yours,
> Russ Magee %-)
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 Feature Suggestion

[JJ Zolper]

Russell Keith-Magee,

This came to mind, before in my post I described a package I had come 
across that someone had made as their fix.

In quoting his github:

"There's a number apps out there for doing authentication with 
emailaddresses prior to Django 1.5. With the advent of Django 1.5 the 
Django core team has made it very easy to use any model for authentication 
simply by setting AUTH_USER_MODEL. Unfortunately it's not possible to 
create a EmailUser model by simply subclassing the User class in 
django.contrib.auth.models instead if you want a model that plays nicely 
with the rest of django.contrib.auth the simplest way is to copy all the 
code in django.contrib.auth.models.User and substitute username for 
emailaddress. You also need to edit some other minor stuff in forms.py and 
admin.py. This Django app does just that. I'm using it in production for a 
couple of client sites and it works fine."

Rewriting code that exists never did anyone any good. It seems he just 
stripped out the previous auth and replaced it with the email address. I 
feel like it should at least be given a look because maybe his work can be 
reviewed, tweaked if needed, verified, and ultimately merged into Django?

Thanks,

JJ

On Monday, July 29, 2013 9:07:43 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 30, 2013 at 8:37 AM, JJ Zolper 
> > wrote:
>
>> Russell Keith-Magee,
>>
>> Are you the one who is doing "Getting Started With Django" ? Sorry for 
>> getting off topic but just was curious. If so I donated money to that 
>> project and I am glad you are doing it.
>>
>
> Sorry, that's not me. You're thinking of Kenneth Love (@kennethlove on 
> twitter).
>  
>
>> Yes, that's what it seems to be called by other Django devs, "Email 
>> address as username." I prefer more to think of it as just "Email" with the 
>> same exact login handlign as "Username." That's my goal with this post is 
>> keep pushing until the point is reached where we can just call it "Email" 
>> login. I also think it is such a common case that it should be within 
>> Django's core. It is obvious from the large number of posts online about 
>> replacing the username with an email. 
>>
>
> A lot of those posts will be from pre-1.5 days; having the ability to 
> easily use an email address as a username was one of the primary 
> motivations behind introducing swappable users as a new feature. It was 
> always possible; in Django 1.5, it's a lot easier; the next step is to make 
> it trivial by having a custom user model for that purpose available in the 
> box.
>
> If you have heard Jacob discussing it before, that would be wonderful! It 
>> would be awesome if the Django guys accepted this into Django all together. 
>> Given it must be considered with the release of Django 1.5 they did give a 
>> lot more support to people like me trying to have the email as the username 
>> through things like:
>>
>> class CustomUser(AbstractBaseUser, PermissionsMixin):
>>  
>>  email = models.EmailField(max_length=255, unique=True)
>>  
>>
>>  objects = CustomUserManager()
>>
>>  USERNAME_FIELD = 'email'
>>
>>
>> So maybe Jacob and Adrian are already on top of this. 
>>
>
> Jacob and Adrian are only "on top of it" in the sense that Jacob has said 
> it's a good idea. I wouldn't hang around waiting for either of them to 
> commit such a patch -- they're both busy, and don't spend a lot of time 
> committing to Django itself these days. 
>  
>
>> The only thing I have been trying to do is follow the suggestions of 
>> those posts I have found online. I could surely route some possible people 
>> I think might have already banged this out but I'm not sure I'm the best 
>> bet. However, I did go ahead and open a ticket:
>>
>> https://code.djangoproject.com/ticket/20824
>>
>> Thanks again to all the Django developers for their hard work,
>>
>
> Thanks for opening a ticket and driving the discussion. I've added some 
> comments to the ticket and marked it as accepted; next step is a patch :-)
>
> Yours,
> Russ Magee %-)
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

South migration ordering on different timeline

[Nora Olsen]

Hi,

I'm using git-flow and I use the develop and master branches. 

Since I had to move features ahead of schedule and bring forward to 
production, I had to cherry-pick[1] them into the master branch.

The south migration scripts are not in order anymore and and staging box is 
up to date with the develop branch. 

For example:
Develop 001-002-003-004-005
Master 001-002--004-005

Staging box: 001-002-003-004-005
Master box: 001-002--004-005

1. When I merge develop into master, what will happen to 003 migration 
script when I deploy to my production box?

2. I guess the staging box will be fine when I merge master back into 
develop since all the migration scripts have been applied?

Thanks!
[1] 
http://stackoverflow.com/questions/17919408/bringing-selective-changes-from-develop-to-master

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 Feature Suggestion

[JJ Zolper]

Oh that's right it was Kenneth, not sure why I thought it was you.

That's a good point about 1.5. That's sort of where I was going. I agree 
that everything is headed in the right direction.

And I'm sure they are busy. I can only imagine.

No problem on opening the ticket and getting it started and yes I see your 
comments thanks for that. And yes now it's time for the patch.

I will begin working on it. I will see what I can do. If anyone is willing 
to help don't hesitate to send them my way. I can be e-mailed at: 
jjzol...@madtrak.com. I haven't developed for the Django internals before 
so I'm completely new to all of this and I haven't been programming in 
Python or Django for a significant amount of time but I feel like I can 
make this happen. Hopefully others will be wanting to help along the way 
and I'm sure your coordinating support will be critical if you are able to 
help.

JJ

On Monday, July 29, 2013 9:07:43 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 30, 2013 at 8:37 AM, JJ Zolper 
> > wrote:
>
>> Russell Keith-Magee,
>>
>> Are you the one who is doing "Getting Started With Django" ? Sorry for 
>> getting off topic but just was curious. If so I donated money to that 
>> project and I am glad you are doing it.
>>
>
> Sorry, that's not me. You're thinking of Kenneth Love (@kennethlove on 
> twitter).
>  
>
>> Yes, that's what it seems to be called by other Django devs, "Email 
>> address as username." I prefer more to think of it as just "Email" with the 
>> same exact login handlign as "Username." That's my goal with this post is 
>> keep pushing until the point is reached where we can just call it "Email" 
>> login. I also think it is such a common case that it should be within 
>> Django's core. It is obvious from the large number of posts online about 
>> replacing the username with an email. 
>>
>
> A lot of those posts will be from pre-1.5 days; having the ability to 
> easily use an email address as a username was one of the primary 
> motivations behind introducing swappable users as a new feature. It was 
> always possible; in Django 1.5, it's a lot easier; the next step is to make 
> it trivial by having a custom user model for that purpose available in the 
> box.
>
> If you have heard Jacob discussing it before, that would be wonderful! It 
>> would be awesome if the Django guys accepted this into Django all together. 
>> Given it must be considered with the release of Django 1.5 they did give a 
>> lot more support to people like me trying to have the email as the username 
>> through things like:
>>
>> class CustomUser(AbstractBaseUser, PermissionsMixin):
>>  
>>  email = models.EmailField(max_length=255, unique=True)
>>  
>>
>>  objects = CustomUserManager()
>>
>>  USERNAME_FIELD = 'email'
>>
>>
>> So maybe Jacob and Adrian are already on top of this. 
>>
>
> Jacob and Adrian are only "on top of it" in the sense that Jacob has said 
> it's a good idea. I wouldn't hang around waiting for either of them to 
> commit such a patch -- they're both busy, and don't spend a lot of time 
> committing to Django itself these days. 
>  
>
>> The only thing I have been trying to do is follow the suggestions of 
>> those posts I have found online. I could surely route some possible people 
>> I think might have already banged this out but I'm not sure I'm the best 
>> bet. However, I did go ahead and open a ticket:
>>
>> https://code.djangoproject.com/ticket/20824
>>
>> Thanks again to all the Django developers for their hard work,
>>
>
> Thanks for opening a ticket and driving the discussion. I've added some 
> comments to the ticket and marked it as accepted; next step is a patch :-)
>
> Yours,
> Russ Magee %-)
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Django not enforcing blank=False on a model

[Knight Samar]

Hi,

I have a model

> from django.db import models
>
> class Organization(models.Model):
> name = models.CharField(max_length=100,
> blank = False,  #mandatory
> help_text = "Name of your Organization",
> verbose_name = '',
> unique = True,
> primary_key = True,
> )
>
>
and a piece of code

> from organization.models import Organization
> o = Organization.objects.create() 
> o.save() 


which works *without raising an IntegrityError!* And the following also 
works just the same!

> from organization.models import Organization
> o = Organization() 

o.save() 


I am using SQLite3(SQLite 3.7.9 2011-11-01 00:52:41 
c7c6050ef060877ebe77b41d959e9df13f8c9b5e) as the database backend and it 
shows the following as the schema:

CREATE TABLE "organization_organization" ( "name" varchar(100) NOT NULL 
> PRIMARY KEY ); 

 
Even if SQLite3 was buggy, shouldn't Django itself enforce the constraint 
on ORM layer ?

I have deleted .pyc files and also the .sqlite3 file before testing again. 
I am using Django 1.5.1

What am I missing ? Why is Django *NOT* enforcing blank=False ?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

invalid reference to FROM-clause entry for table

[hippomoe]

I'm using djorm-ext-pgfulltext extension to do full-text-search using 
Postgres on a title field for one of my models (Bookmark).

class Bookmark(TimeStampModel):
title = models.CharField(max_length = 100)
# other fields

search_index = VectorField()

objects = SearchManager(
fields = ('title'),
config = 'pg_catalog.english',
search_field = 'search_index',
auto_update_search_field = True
)

I have another model called SharedBookmark that is OneToOne related to the 
Bookmark.

class SharedBookmark(TimeStampedModel):
bookmark = models.OneToOneField(Bookmark)
# other fields

I am able to do a search through my Bookmark instances using:

Bookmark.objects.search(query)

But when I try to do the following filter

SharedBookmark.objects.filter(bookmark__in=Bookmark.objects.search(query))

I receive the following error:

invalid reference to FROM-clause entry for table "bookmarks_bookmark" LINE 
1: ...ECT U0."id" FROM "bookmarks_bookmark" U0 WHERE ( ("bookmarks... ^ 
HINT: Perhaps you meant to reference the table alias "u0"

This is the traceback:

Traceback:
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/core/handlers/base.py"
 
in get_response
  115. response = callback(request, *callback_args, 
**callback_kwargs)
File "/home/derek/Development/skillfare/skillfare/bookmarks/views.py" in 
search
  76. print shared_bookmarks
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/query.py"
 
in __repr__
  77. data = list(self[:REPR_OUTPUT_SIZE + 1])
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/query.py"
 
in __len__
  92. self._result_cache.extend(self._iter)
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/query.py"
 
in _safe_iterator
  344. for item in iterator:
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/query.py"
 
in iterator
  301. for row in compiler.results_iter():
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py"
 
in results_iter
  775. for rows in self.execute_sql(MULTI):
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py"
 
in execute_sql
  840. cursor.execute(sql, params)
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/backends/util.py"
 
in execute
  41. return self.cursor.execute(sql, params)
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py"
 
in execute
  58. six.reraise(utils.DatabaseError, 
utils.DatabaseError(*tuple(e.args)), sys.exc_info()[2])
File 
"/home/derek/.virtualenvs/skillfare/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py"
 
in execute
  54. return self.cursor.execute(query, args)

I can't make sense of the error. What causes this error and how should I 
fix it? 

Thanks for any advice!
hippomoe

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 Feature Suggestion

[Russell Keith-Magee]

On Tue, Jul 30, 2013 at 8:37 AM, JJ Zolper  wrote:

> Russell Keith-Magee,
>
> Are you the one who is doing "Getting Started With Django" ? Sorry for
> getting off topic but just was curious. If so I donated money to that
> project and I am glad you are doing it.
>

Sorry, that's not me. You're thinking of Kenneth Love (@kennethlove on
twitter).


> Yes, that's what it seems to be called by other Django devs, "Email
> address as username." I prefer more to think of it as just "Email" with the
> same exact login handlign as "Username." That's my goal with this post is
> keep pushing until the point is reached where we can just call it "Email"
> login. I also think it is such a common case that it should be within
> Django's core. It is obvious from the large number of posts online about
> replacing the username with an email.
>

A lot of those posts will be from pre-1.5 days; having the ability to
easily use an email address as a username was one of the primary
motivations behind introducing swappable users as a new feature. It was
always possible; in Django 1.5, it's a lot easier; the next step is to make
it trivial by having a custom user model for that purpose available in the
box.

If you have heard Jacob discussing it before, that would be wonderful! It
> would be awesome if the Django guys accepted this into Django all together.
> Given it must be considered with the release of Django 1.5 they did give a
> lot more support to people like me trying to have the email as the username
> through things like:
>
> class CustomUser(AbstractBaseUser, PermissionsMixin):
>  
>  email = models.EmailField(max_length=255, unique=True)
>  
>
>  objects = CustomUserManager()
>
>  USERNAME_FIELD = 'email'
>
>
> So maybe Jacob and Adrian are already on top of this.
>

Jacob and Adrian are only "on top of it" in the sense that Jacob has said
it's a good idea. I wouldn't hang around waiting for either of them to
commit such a patch -- they're both busy, and don't spend a lot of time
committing to Django itself these days.


> The only thing I have been trying to do is follow the suggestions of those
> posts I have found online. I could surely route some possible people I
> think might have already banged this out but I'm not sure I'm the best bet.
> However, I did go ahead and open a ticket:
>
> https://code.djangoproject.com/ticket/20824
>
> Thanks again to all the Django developers for their hard work,
>

Thanks for opening a ticket and driving the discussion. I've added some
comments to the ticket and marked it as accepted; next step is a patch :-)

Yours,
Russ Magee %-)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 Feature Suggestion

[JJ Zolper]

Russell Keith-Magee,

Are you the one who is doing "Getting Started With Django" ? Sorry for 
getting off topic but just was curious. If so I donated money to that 
project and I am glad you are doing it.

Yes, that's what it seems to be called by other Django devs, "Email address 
as username." I prefer more to think of it as just "Email" with the same 
exact login handlign as "Username." That's my goal with this post is keep 
pushing until the point is reached where we can just call it "Email" login. 
I also think it is such a common case that it should be within Django's 
core. It is obvious from the large number of posts online about replacing 
the username with an email. If you have heard Jacob discussing it before, 
that would be wonderful! It would be awesome if the Django guys accepted 
this into Django all together. Given it must be considered with the release 
of Django 1.5 they did give a lot more support to people like me trying to 
have the email as the username through things like:

class CustomUser(AbstractBaseUser, PermissionsMixin):
 
 email = models.EmailField(max_length=255, unique=True)
 

 objects = CustomUserManager()

 USERNAME_FIELD = 'email'


So maybe Jacob and Adrian are already on top of this. The only thing I have 
been trying to do is follow the suggestions of those posts I have found 
online. I could surely route some possible people I think might have 
already banged this out but I'm not sure I'm the best bet. However, I did 
go ahead and open a ticket:

https://code.djangoproject.com/ticket/20824

Thanks again to all the Django developers for their hard work,

JJ



On Friday, July 26, 2013 9:21:04 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Fri, Jul 26, 2013 at 10:43 PM, JJ Zolper 
> > wrote:
>
>> Hello everyone,
>>
>> So I want to say thanks to the Django guys for providing more support for 
>> those of us that want to use a user's email as the UID and login handler 
>> versus the previous method of handling based on the username. I and 
>> probably many others appreciate the effort given to the topic and that it 
>> was integrated into Django 1.5.
>>
>> Today I would like to request a continuing expansion about this concept.
>>
>> In referencing this link:
>>
>>
>> https://geekwentfreak-raviteja.rhcloud.com/2012/12/custom-user-models-in-django-1-5/
>>
>> I would like to request that if we want to make email the UID we don't 
>> have to do things such as:
>>
>> class MyUser(AbstractBaseUser, PermissionsMixin):
>>  
>>  is_staff = models.BooleanField('staff status', default=False,
>>  help_text='Designates whether the user can log into this admin '
>>  'site.')
>>  is_active = models.BooleanField('active', default=True,
>>  help_text='Designates whether this user should be treated as '
>>  'active. Unselect this instead of deleting 
>> accounts.')
>>   
>> def get_full_name(self):
>>  full_name = '%s %s' % (self.first_name, self.last_name)
>>  return full_name.strip()
>>   
>> def get_short_name(self):
>>  return self.first_name
>>  
>>  just to retain what could already be apart of Django. You guys know 
>> more about Django then I ever will and what the best way is to go about it 
>> but if we can eliminate additional code that is already in Django that 
>> would be wonderful.
>>  
>>  Now in referencing:
>>  
>>  
>> http://stackoverflow.com/questions/16638414/set-email-as-username-in-django-1-5
>>  
>>  Basically what I'm saying is, we shouldn't have to do what this fellow 
>> had to do:
>>  
>>  Unfortunately there's nothing within django.contrib.auth that you can 
>> simply subclass to get a model that has
>>
>>1. 
>>
>>email address in place of user name and
>>2. 
>>
>>works nicely with other django.contrib.auth-stuff, like groups.
>>
>> The simplest approach is to copy models.py, admin.py and forms.py from
>> django.contrib.auth, rip out user name all over the place and put in 
>> email address in it's place. I've done just that and I'm using it 
>> successfully in a couple of client projects.
>>
>> I've put it up on github and pypi so you can install it with
>>
>> pip install django-libtech-emailuser
>>
>>  
>>  I thank you for your time and I appreciate your consideration for 
>> integrating this once and for all into Django.
>>
>
> Hi JJ,
>  
> That's a fair comment -- "Email address as username" is a sufficiently 
> common use case that it probably warrants being included in Django's core. 
> I think I've overheard Jacob endorsing the same thing at some point in the 
> past (although I'll stand corrected on this if I 
> misheard/misunderstood/misattributed his comments). 
>
> If you've already done the heavy lifting here, then all we need to do is 
> massage your external package into contrib. Open a ticket and we can see 
> what we can do about getting this in for 1.7.
>
> Yours,
> Russ Magee %-)
>
>

Re: django workaround for multiple primary keys or sqlalchemy

[Guy Tamir]

Great thanks for the helpful reply!
I'll use the Django ORM like you suggested, that was my gut filling 
anyways..

Thanks!

On Monday, July 29, 2013 3:09:56 PM UTC-4, Justin Michalicek wrote:
>
> I would go with the Django ORM and just add a unique_together for a 
> multiple column uniqueness constraint.  That index won't be your primary 
> key, but it will still be a unique index.  I've even gone as far as to use 
> custom .sql files (which manage.py syncdb runs) and custom sql in South 
> migrations to create highly customized things like a partial unique index 
> (a Postgres specific thing) when necessary.
>
> Going with SQLAlchemy is probably asking for trouble, especially if you're 
> new both Django and SQLAlchemy.  Swapping SQLAlchemy in for the Django ORM 
> was more common early in Django's lifetime when its ORM was not as robust 
> as it is today.  By doing so you'll lose a number of things that currently 
> "just work", which to me is one of strengths of Django - these things were 
> made to work together and so I know they will work and will continue to 
> work.  I suspect using SQLAlchemy is going to cause issues if you try to 
> use any 3rd party Django apps as well.
>
> On Monday, July 29, 2013 11:39:20 AM UTC-4, Guy Tamir wrote:
>>
>> Hi all,
>>
>> i'm fairly new to Django and i have a question regarding the best 
>> practice for a situation i've got.
>>
>> I'm working on a new project and after designing my ERD I know i need a 
>> few tables to have multiple primary keys and one table with triple primary 
>> keys.
>>
>> after reading about the subject online i found out that Django does not 
>> support this feature yet but there is a workaround which is to add a 
>> unique_together constraint (if i understand correct)
>> reading some more online there are recommendations for working with 
>> SQLAlchemy that does support the multiple primary key issue.
>>
>> I have 2 questions regarding those issues:
>> 1. if I use the django workaround will it later bite me in the ass 
>> performance wise and simply by not working correctly?
>> 2. if i'll work with SQLAlchemy does that mean that i wont be able to 
>> work with django models and all that is derived from working like so?
>>
>> whats the recommended practice for my situation?
>>
>> Thanks all..
>>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: django workaround for multiple primary keys or sqlalchemy

[Bill Freeman]

Its not clear to me whether unique_together will make there be an index, so
it might be slow.


On Mon, Jul 29, 2013 at 3:09 PM, Justin Michalicek wrote:

> I would go with the Django ORM and just add a unique_together for a
> multiple column uniqueness constraint.  That index won't be your primary
> key, but it will still be a unique index.  I've even gone as far as to use
> custom .sql files (which manage.py syncdb runs) and custom sql in South
> migrations to create highly customized things like a partial unique index
> (a Postgres specific thing) when necessary.
>
> Going with SQLAlchemy is probably asking for trouble, especially if you're
> new both Django and SQLAlchemy.  Swapping SQLAlchemy in for the Django ORM
> was more common early in Django's lifetime when its ORM was not as robust
> as it is today.  By doing so you'll lose a number of things that currently
> "just work", which to me is one of strengths of Django - these things were
> made to work together and so I know they will work and will continue to
> work.  I suspect using SQLAlchemy is going to cause issues if you try to
> use any 3rd party Django apps as well.
>
> On Monday, July 29, 2013 11:39:20 AM UTC-4, Guy Tamir wrote:
>>
>> Hi all,
>>
>> i'm fairly new to Django and i have a question regarding the best
>> practice for a situation i've got.
>>
>> I'm working on a new project and after designing my ERD I know i need a
>> few tables to have multiple primary keys and one table with triple primary
>> keys.
>>
>> after reading about the subject online i found out that Django does not
>> support this feature yet but there is a workaround which is to add a
>> unique_together constraint (if i understand correct)
>> reading some more online there are recommendations for working with
>> SQLAlchemy that does support the multiple primary key issue.
>>
>> I have 2 questions regarding those issues:
>> 1. if I use the django workaround will it later bite me in the ass
>> performance wise and simply by not working correctly?
>> 2. if i'll work with SQLAlchemy does that mean that i wont be able to
>> work with django models and all that is derived from working like so?
>>
>> whats the recommended practice for my situation?
>>
>> Thanks all..
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Creating libraries that use django ORM and they use each other.

[Roberto Bouza]

Hello,

I'm building a set of common libraries and a few other specific libraries. 
As of right now the common library works great as an independent library 
that can be used by applications.

The problem I'm having now is that I'm building a new library that will use 
the common library. This new library needs to load its settings and 
configure them but the common library
already did that for its own settings. A call to configure again triggers 
an already configured error. 

So a nice thing will be to append the new settings to the ones already 
configured and trigger a reload. Is this possible or feasible? are there 
any other options?

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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: django workaround for multiple primary keys or sqlalchemy

[Justin Michalicek]

I would go with the Django ORM and just add a unique_together for a 
multiple column uniqueness constraint.  That index won't be your primary 
key, but it will still be a unique index.  I've even gone as far as to use 
custom .sql files (which manage.py syncdb runs) and custom sql in South 
migrations to create highly customized things like a partial unique index 
(a Postgres specific thing) when necessary.

Going with SQLAlchemy is probably asking for trouble, especially if you're 
new both Django and SQLAlchemy.  Swapping SQLAlchemy in for the Django ORM 
was more common early in Django's lifetime when its ORM was not as robust 
as it is today.  By doing so you'll lose a number of things that currently 
"just work", which to me is one of strengths of Django - these things were 
made to work together and so I know they will work and will continue to 
work.  I suspect using SQLAlchemy is going to cause issues if you try to 
use any 3rd party Django apps as well.

On Monday, July 29, 2013 11:39:20 AM UTC-4, Guy Tamir wrote:
>
> Hi all,
>
> i'm fairly new to Django and i have a question regarding the best practice 
> for a situation i've got.
>
> I'm working on a new project and after designing my ERD I know i need a 
> few tables to have multiple primary keys and one table with triple primary 
> keys.
>
> after reading about the subject online i found out that Django does not 
> support this feature yet but there is a workaround which is to add a 
> unique_together constraint (if i understand correct)
> reading some more online there are recommendations for working with 
> SQLAlchemy that does support the multiple primary key issue.
>
> I have 2 questions regarding those issues:
> 1. if I use the django workaround will it later bite me in the ass 
> performance wise and simply by not working correctly?
> 2. if i'll work with SQLAlchemy does that mean that i wont be able to work 
> with django models and all that is derived from working like so?
>
> whats the recommended practice for my situation?
>
> Thanks all..
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: installing RemoteUserMiddleware causes errors

[Brian Tingle]

code.djangoproject.com is back up now; seems like I bumping up against this 
three year old bug that has not been updated in 19 months:

https://code.djangoproject.com/ticket/13394

Any advice on how to handle this?  Do I need to re-write all the tests? 
 Does this mean RemoteUserMiddleware is not really supported?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

installing RemoteUserMiddleware causes errors

[Brian Tingle]

I keep getting 504 gateway timeout errors on http://code.djangoproject.com/ 
so I can't look through the tickets for this.

There are some threads on this list that seem like they might be related; 
but I can't tell because they link to code.djangoproject.com which I can't 
get to.

I tried to follow the directions at 
https://docs.djangoproject.com/en/1.5/howto/auth-remote-user/

Before I make the change `python manage.py test` works; I after I make the 
change, the test command fails with these errors: 
https://gist.github.com/tingletech/6106397#file-2-errors-txt

Any ideas what I'm doing wrong?

This test below is django 1.5.1; but I noticed the issue on a django 1.5.0 
site


diff --git a/blah/settings.py b/blah/settings.py
index b3f2aec..0701641 100644
--- a/blah/settings.py
+++ b/blah/settings.py
@@ -97,11 +97,16 @@ MIDDLEWARE_CLASSES = (
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
+'django.contrib.auth.middleware.RemoteUserMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 # Uncomment the next line for simple clickjacking protection:
 # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 )
 +AUTHENTICATION_BACKENDS = (
+'django.contrib.auth.backends.RemoteUserBackend',
+)
+
 ROOT_URLCONF = 'blah.urls'
  # Python dotted path to the WSGI application used by Django's runserver.


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Django Pipeline not overwriting the hash of the cache busting js file

[Benjamin Plesser]

class S3PipelineStorage(PipelineMixin, CachedFilesMixin, S3BotoStorage):
 pass



PIPELINE_JS = {
 'main.js': {
'output_filename': 'js/main.min.js',
'source_filenames': [
'js/external/underscore.js',
'js/external/backbone-1.0.0.js',
'js/external/bootstrap-2.2.0.min.js',
]
  }}

When I first ran the collectstatic command yesterday, it properly created a 
cache busting file named "main.min.d25bdd71759d.js

However, when I now run the command, it is failing to overwrite that cached 
file (and update the hash) during the post process phase.

It keeps updating "main.min.js", such that main.min.js on S3 is current 
with the code in my filesystem. A new cached file, however is not created. 
It keeps the same old hash even though the underlying main.min.js file has 
changed.

When I manually delete the cache busting file on AWS, I get the following 
message from running collectstatic with verbosity set to 3:

Post-processed 'js/main.min.js' as 'js/main.min.d25bdd71759d.js

So, it kept the same hash as the old version and it is not up to date.

settings.DEBUG is set to False

Why won't the hash update?  I assume that it is because it is hashing the 
contents of  the old version of "js/main.min.js" but how would it access 
that old version if the new version is up on S3?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Django/Python based webmail

[Tomas Ehrlich]

Hi there,
I'm looking for django (or python) based webmail, similar to RoundCube
and SquirrelMail.

I tried djangopackages.com and google search, but it doesn't seem to be
an alive project out there. How you ever wondered why? :) Seems to me
like useful app.

Thanks in advance


Cheers,
  Tom

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

django workaround for multiple primary keys or sqlalchemy

[Guy Tamir]

Hi all,

i'm fairly new to Django and i have a question regarding the best practice 
for a situation i've got.

I'm working on a new project and after designing my ERD I know i need a few 
tables to have multiple primary keys and one table with triple primary keys.

after reading about the subject online i found out that Django does not 
support this feature yet but there is a workaround which is to add a 
unique_together constraint (if i understand correct)
reading some more online there are recommendations for working with 
SQLAlchemy that does support the multiple primary key issue.

I have 2 questions regarding those issues:
1. if I use the django workaround will it later bite me in the ass 
performance wise and simply by not working correctly?
2. if i'll work with SQLAlchemy does that mean that i wont be able to work 
with django models and all that is derived from working like so?

whats the recommended practice for my situation?

Thanks all..

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changing log filename

[Bill Freeman]

Since your handler is used for the "myproject" logger, to use that handler
all your apps would have to use loggers descended from that logger, that
is, all your apps would have to use something like:

  logging.getLogger('myproject')
or
  logging.getLogger('myproject.app1')
or
  logging.getLogger('myproject.app4.models")  # might also be expressed as
logging.getLogger(__name__), but, depending on where you put your apps,
that might produce app4.models instead.

This is less than satisfactory since it ties your apps to this project, and
means that they must be edited to be used in a new project.

Also uncomfortable is that if you want apps that you have pip installed (as
opposed to having copied into your project's directory) have to be modified
to use this scheme.

Note that if you uses logging in multiple modules within a project, all
such modules have to be edited.


An (commonly used) alternative is to attach your handler to the root
logger, since it is the ancestor of all loggers.  So long as you don't set
propagate to False (default is True) on any descendant logger, all events
will reach the handler on the root logger.  This gives you a single place
to change the file name.

The logging documentation at
http://docs.python.org/2.7/library/logging.htmlis not as clear as I
might wish about the tree of ancestors and dependents
and how events are passed to higher level handlers, but the information is
there to be dug out.


On Fri, Jul 26, 2013 at 10:01 PM, David Kumar  wrote:

> I have a standard logger that I would like to use for all of my
> applications, the only thing I want to change is the name of the file.  Is
> there a way to do that with out having to create a logger and handler for
> each of my apps.
>
> Here is the logging settings that I am using.
>
> LOGGING = {
> 'version': 1,
> 'disable_existing_loggers': True,
> 'formatters': {
> 'standard': {
> 'format' : "[%(asctime)s] %(levelname)s
> [%(module)s:%(lineno)s] %(message)s",
> 'datefmt' : "%d/%b/%Y %H:%M:%S"
> },
> },
> 'handlers': {
> 'app_logger': {
> 'level':'DEBUG',
> 'class':'logging.handlers.TimedRotatingFileHandler',
> 'filename': '/var/log/django/app.log',
> 'backupCount': 5,
> 'when' : 'midnight',
> 'formatter': 'standard',
> },
> },
> 'loggers': {
> 'myproject': {
> 'handlers': ['app_logger'],
> 'level': 'INFO',
> }
> }
> }
>
>
> In my app I would like to be able to override the 'filename':
> '/var/log/django/another_app.log',
>
> import logging
> log = logging.getLogger('myproject')
>
> 
> log.info("Something here")
>
> Any ideas?
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Multiple Form Submit with Single Submit Button

[pattinson]

I'm currently working with django project. I had to filter the data store 
on the database based on the user input on form (at template) as looked 
below.




On form user either enter value or leave it blank. So what I have to do is 
first find the (valid) user input and then fire appropriate query to 
display data as user input in the form. So final result should be displayed 
on table at template.

As I'm new to django, how should I have to pass the data and fire query to 
represent data at multiple field. As help or link related to these type 
problem are expected. ( I just able to filter from the database with only 
one form and had no concept to solve this.)

Model of my temp project is as below.

class exReporter(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
email = models.EmailField()
gender = models.CharField(max_length=1)
age = models.IntegerField()
label = models.IntegerField()


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How the authentication takes place at the backend in django?

[Kelvin Wong]

You can always read the source code to find this out

https://github.com/django/django/blob/master/django/contrib/auth/models.py

https://github.com/django/django/blob/master/django/contrib/auth/backends.py

https://github.com/django/django/blob/master/django/contrib/auth/hashers.py

Also the docs are very good

https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests

https://docs.djangoproject.com/en/dev/ref/contrib/auth/

K


On Saturday, July 27, 2013 10:37:25 PM UTC-7, Viji Venkatesan wrote:
>
> Hi,
>
>
> If we are giving credentials in login form as username and password,how 
> the process takes place to check with database at the backend ,whether the 
> user is authenticated or not.?
> just make clear of itplease give detail explanation for it.
>
> 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: working with images in django

[Kelvin Wong]

So you have images already made and you want to place them into HTML? 
That's easy. If you want to make the image dynamically using something like 
PIL or Pillow then flow them into a PDF then that's a little more involved.

Try explaining your use case a bit more.

K


On Sunday, July 28, 2013 7:21:33 AM UTC-7, Robert Brown wrote:
>
> Hello, can anyone suggest where I might find some of example of working 
> with images in django.  I want to store them and pull them into text 
> documents, about one every couple of paragraphs.  I am finding a lot of 
> posts on this site about the img class but most of them seem to address 
> very specific problems.  I am looking more for a beginners how to do it 
> discussion or tutorial.
>
> 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: or-ing to QuerySets turns INNER into LEFT OUTER joins?

[Carsten Fuchs]

Hi Martin,

Am 2013-07-26 20:48, schrieb Martin J. Laubach:

   This is rather unusual. A join in the database should be quite a bit faster 
than
doing things manually, except if the joined tables produce massive amounts of 
data. This
suggests that you're missing useful indexes and/or statistics for your query.



Could you please elaborate a bit?

As I mentioned earlier, I'm no SQL/database expert. When I run the queries individually, 
they're all reasonably fast, even though all of them have several thousand rows, and the 
ERFASST table even has several millions. So I concluded that the proper indexes were 
already in place.


I've also talked to our DB admins, who ran the full query through some Oracle 
auto-optimizer tool, but said that it only suggested to add more indexes that, when 
tried out, did not seem to buy anything.


Anything else that I should look into or steps to take?

Best regards,
Carsten



--
Dipl.-Inf. Carsten Fuchs

Carsten Fuchs Software
Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany
Internet: http://www.cafu.de | E-Mail: i...@cafu.de

Cafu - the open-source game and graphics engine for multiplayer 3D action

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django throws an exception when I add data from admin interface

[Yu Yang]

Thanks for your reply, you are right. 

On Saturday, July 27, 2013 12:21:07 AM UTC+8, Tom Evans wrote:
>
> On Fri, Jul 26, 2013 at 4:22 PM, Yu Yang > 
> wrote: 
> > It is a blog app, I have created a Article model and Tag model. when I 
> add 
> > data to Article table from Admin interface, the data is stored to 
> database, 
> > but if I click the link to change the entry, it throws an exception 
> "string 
> > indices must be integers, not str", the traceback is as follows: 
> > Environment: 
> > 
> > 
> > Request Method: GET 
> > Request URL: http://localhost:8000/admin/blog/article/1/ 
> > 
> > Django Version: 1.5.1 
> > Python Version: 2.7.3 
> > Installed Applications: 
> > ('django.contrib.auth', 
> >  'django.contrib.contenttypes', 
> >  'django.contrib.sessions', 
> >  'django.contrib.sites', 
> >  'django.contrib.messages', 
> >  'django.contrib.staticfiles', 
> >  'django.contrib.admin', 
> >  'blog') 
> > Installed Middleware: 
> > ('django.middleware.common.CommonMiddleware', 
> >  'django.contrib.sessions.middleware.SessionMiddleware', 
> >  'django.middleware.csrf.CsrfViewMiddleware', 
> >  'django.contrib.auth.middleware.AuthenticationMiddleware', 
> >  'django.contrib.messages.middleware.MessageMiddleware') 
> > 
> > 
> > Traceback: 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  
>
> > in get_response 
> >   115. response = callback(request, 
> *callback_args, 
> > **callback_kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/contrib/admin/options.py"
>  
>
> > in wrapper 
> >   372. return self.admin_site.admin_view(view)(*args, 
> > **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/utils/decorators.py"
>  
>
> > in _wrapped_view 
> >   91. response = view_func(request, *args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/views/decorators/cache.py"
>  
>
> > in _wrapped_view_func 
> >   89. response = view_func(request, *args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/contrib/admin/sites.py"
>  
>
> > in inner 
> >   202. return view(request, *args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/utils/decorators.py"
>  
>
> > in _wrapper 
> >   25. return bound_func(*args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/utils/decorators.py"
>  
>
> > in _wrapped_view 
> >   91. response = view_func(request, *args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/utils/decorators.py"
>  
>
> > in bound_func 
> >   21. return func(self, *args2, **kwargs2) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/db/transaction.py"
>  
>
> > in inner 
> >   223. return func(*args, **kwargs) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/contrib/admin/options.py"
>  
>
> > in change_view 
> >   1112. form = ModelForm(instance=obj) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/forms/models.py"
>  
>
> > in __init__ 
> >   244. object_data = model_to_dict(instance, opts.fields, 
> > opts.exclude) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/forms/models.py"
>  
>
> > in model_to_dict 
> >   129. data[f.name] = 
> > list(f.value_from_object(instance).values_list('pk', flat=True)) 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/db/models/fields/related.py"
>  
>
> > in value_from_object 
> >   1333. return getattr(obj, self.attname).all() 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/db/models/manager.py"
>  
>
> > in all 
> >   128. return self.get_query_set() 
> > File 
> > 
> "/home/yangyu/.virtualenvs/django-blog/local/lib/python2.7/site-packages/django/db/models/fields/related.py"
>  
>
> > in get_query_set 
> >   612. return 
> > self.instance._prefetched_objects_cache[self.prefetch_cache_name] 
> > 
> > Exception Type: TypeError at /admin/blog/article/1/ 
> > Exception Value: string indices must be integers, not str 
> > 
> > 
> > the code of Article model and Tag model is as follows: 
> > 
> > 
> > class Tag(models.Model): 
> > name = models.CharField(max_length=50, unique=True, 
> verbose_name='标签') 
> > slug = models.SlugField() 
> > 
> > def __unicode__(self): 
> > return s

[ANN] django-localflavor 1.0 release

[Jannis Leidel]

Hi all,

As proposed two months ago [1], I just released django-localflavor 1.0 with all 
"local flavors" recombined.

This fixes the failed handover of the django.contrib.localflavor app to the 
broader community with the per-country django-localflavor-* apps before the 
Django 1.5 release. Those packages are now all integrated again in the new 
django-localflavor app. All contributors of the now defunct per-country apps 
have been given commit access to the new app. The main purpose of the new app 
is to reduce maintenance friction of 40+ separate "localflavors".

Releases of django-localflavor are independent from Django's release cycle but 
will always support the currently maintained Django releases. It currently 
supports Python 2.6, 2.7, 3.2 and 3.3 and runs on Django 1.5.x and the upcoming 
1.6.x.

Here's the source code of django-localflavor:

  https://github.com/django/django-localflavor

The documentation:

  https://django-localflavor.readthedocs.org/

Translations can be updated on Transifex:

  https://www.transifex.com/projects/p/django-localflavor/

And the tests are hosted on Travis CI (a tox config also exists):

  https://travis-ci.org/django/django-localflavor

Thanks for the attention, please let me know if you have any questions :)

Jannis


PS: In case pip installing the app doesn't work right away please allow the 
PyPI CDN a few minutes to fetch the file.


1: https://groups.google.com/d/msg/django-developers/vxCStIvpXc4/o68setV25e4J



signature.asc
Description: Message signed with OpenPGP using GPGMail

manage.py dumpdata for FieldFile serializes payload of file

[jrief]

Yesterday, I added a useful feature to 
*django-filer
*, which allows to dump the payload of files together with their meta-data, 
when runningmanage.py dumpdata > dumpfile.json. A dumpfile which is 
reimported using manage.py loaddata dumpfile.json then restores the file on 
disk.

This simplifies backups and migrations of projects using *django-filer* to 
manage their media data, since an administrator does not require additional 
tools such as zip or tar. It also makes backups less error prone, since 
everything is contained in one single file.

More details here: 
https://github.com/jrief/django-filer/blob/serialize-payload/docs/dump_payload.rst
 and here: https://github.com/stefanfoulis/django-filer/pull/335

Stefan Foulis, the maintainer of *django-filer* considered: "But I'd really 
prefer a solution that works with django-filer and any other FileFields in 
the project."

So my question is, if such an additional feature would be accepted on the 
main Django project, rather than only in an external app, such as *
django-filer*.

- Jacob

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

pdf conversion error

[Harjot Mann]

I am trying to convert the html templates in my project from localhost
using wkhtltopdf. I used weasyprint and a script also but the getting
the same errror from all. It creates the pdf but inside this is
written:
Not Found
The requested URL /accounts/login/ was not found on this server.
Apache/2.2.22 (Ubuntu) Server at localhost Port 80

What is its solution??

-- 
Harjot Kaur Mann
Blog: http://harjotmann.wordpress.com/

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What client side html layout tools are people using to speed up template development?

[Mario Gudelj]

Use http://twitter.github.io/bootstrap/ framework for your frontend. If you
google "django bootstrap" you'll find some apps that will help.

For fonts i usually pick Google font that looks good. If you want to use
web safe font go to http://cssfontstack.com/

As for colors, try https://kuler.adobe.com/create/color-wheel/

You can also google something like "20 web designer tools" and you'll get
one of those blog posts that lists them all.

And if you have time check out this list
https://github.com/dypsilon/frontend-dev-bookmarks. It's truly amazing!

Cheers,

M


On 29 July 2013 19:18, Sam Walters  wrote:

> Its not specific to django however i have a few small projects on the
> horizon where i could really save time spent on the things im not good at:
>
> Graphic design CSS layouts, choosing fonts, colours that look good.
>
> What are the tools people are using for this these days? What are strong
> points of the system you are using?
>
> All this stuff will get partiitoned up and placed in my django templates.
>
> I used to use yahoo yui gris css, 960 grid system and a few other things a
> couple of years back. I assume there are better things i dont know about
> though.
>
> thanks in advance!
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What client side html layout tools are people using to speed up template development?

[Avraham Serour]

I never used this yahoo lib bit it seems to me that you are looking for
twitter bootstrap or zurb foundation
On Jul 29, 2013 12:18 PM, "Sam Walters"  wrote:

> Its not specific to django however i have a few small projects on the
> horizon where i could really save time spent on the things im not good at:
>
> Graphic design CSS layouts, choosing fonts, colours that look good.
>
> What are the tools people are using for this these days? What are strong
> points of the system you are using?
>
> All this stuff will get partiitoned up and placed in my django templates.
>
> I used to use yahoo yui gris css, 960 grid system and a few other things a
> couple of years back. I assume there are better things i dont know about
> though.
>
> thanks in advance!
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

What client side html layout tools are people using to speed up template development?

[Sam Walters]

Its not specific to django however i have a few small projects on the
horizon where i could really save time spent on the things im not good at:

Graphic design CSS layouts, choosing fonts, colours that look good.

What are the tools people are using for this these days? What are strong
points of the system you are using?

All this stuff will get partiitoned up and placed in my django templates.

I used to use yahoo yui gris css, 960 grid system and a few other things a
couple of years back. I assume there are better things i dont know about
though.

thanks in advance!

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Learning how to build a web site for my python games and a blog

[Christian Erhardt]

Sry, I have no idea what you are talking about

Am Samstag, 27. Juli 2013 15:57:45 UTC+2 schrieb Randy Baxley:
>
> Is anyone working through The Django Book that would like to form a fb 
> page just for that or knows of a good tutorial where questions will get 
> answers?
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: .filter() and .exclude() don't add up

[akaariai]

On Sunday, July 28, 2013 10:44:49 AM UTC+3, Daniele Procida wrote:
>
> On Sat, Jul 27, 2013, Steve McConville > 
> wrote: 
>
> >Perhaps I'm not sure exactly what you mean by "more general", but I 
> >was recommending something like 
> > 
> >red_things = queryset.filter(Q(color="red")) 
> >non_red_things = queryset.filter(~Q(color="red") | Q(color__isnull=True) 
> > 
> >This will produce SQL like 
> > 
> >SELECT * FROM queryset WHERE color IS 'red'; 
> >SELECT * FROM queryset WHERE color IS NOT 'red' OR color IS NULL; 
> > 
> >The set non_red_things will be the complement of red_things. 
>
> I understood that part. But by "more general" I mean one that will work 
> for any case, without having to know where the Nulls might be. 
>
> So given queryset A, and its subset queryset B, we can place B against A 
> and obtain its complement. 
>
> Or to put it another way: give me all the items in A that are not in B. 
>

You can do this with a subquery in Django. non_red_things = 
queryset.exclude(pk__in=red_things). If this performs well is a different 
thing.

I think that in SQL one can use WHERE (original_condition) is not true; 
which will match both unknown (null comparison's result) and false in the 
original condition.

 - Anssi

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.