How to debug ORM filter stacking?

[ydjango]

I am stacking filters on queryset. For some reason the second filter
in stack is not applying and it is not giving any error either. Any
way to debug what is going on?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How do you set choices in your application?

[Russell Keith-Magee]

On Sat, Sep 25, 2010 at 10:50 AM, Yo-Yo Ma  wrote:
> Anyone have any thoughts.

Yes. My thought is that you should settle down.

This is a mailing list, populated by an international audience.

You've waited less than *2 hours* before pinging the list for a
response. This is the third time in recent memory that you've done
this.

Mail isn't an instant-response mode of communication, and on top of
that, most of the audience of people that are in a position to answer
your question aren't in the same time zone as you. It's 4am in London.
5am in Western Europe. It's dinner time on the west coast of the US.
Lunch time on the east coast of Australia. Is it completely outside
the realms of possibility that people might be *busy*?

On top of that, this is a volunteer list. It's entirely possible that
nobody in the community can spare the time *right this very second* to
answer your question.

If you need an urgent response, I suggest one of two things:

 * Try IRC. IRC is an instant response forum. Anybody who is
interested in responding will respond immediately. You're still not
guaranteed a response, but you're at least going to find out if you're
going to get a response straight away.

 * Pay someone. There are plenty of for-money consultants in the
Django community who will happily provide a 2-hour turnaround on your
queries for a fee.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Since Django 1.2.3, I can't display any Form

[Karen Tracey]

2010/9/24 François Bonnefont 

> I am new to this group and not sure how to present my problem
> correctly...
>
> I was working with django 1.1 and made a very small and simple
> application with a "ContactForm" not related to any model.
>
> My forms.py :
>
> from django import forms
>
> class ContactForm(forms.Form):
>firstname = forms.CharField(max_length=50)
>lastname = forms.CharField(max_length=50)
>
>
> Recently I updated to Django 1.2.3 and since then I get :
>
> "AttributeError: 'CharField' object has no attribute 'prepare_value'"
> when I try to print this form (or any other form).
>

It sounds like your 1.2.3 update did not entirely work. Specifically the
error seems to imply you are running with a 1.2.3 level of the
django/forms/forms.py file but some earlier level of django/forms/fields.py.
I'd delete the current Django installation and re-install 1.2.3 from
scratch.

Karen
-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Python unexpectedly quit

[Axel Bock]

maybe I was a little bit out of sleep today :) . tried to get auth.User
subclassing working til 4am in the morning ... and what do you mean with
"not picky enough"?



2010/9/24 Steve Holden 

> On 9/24/2010 2:23 PM, Axel Bock wrote:
> > Anything wrong here? I must say, the framework for the people "with
> > deadlines" is giving me a *really* hard time so far :) .
>
> Maybe you aren't in enough of a hurry? And, by the way, it's
> *perfectionists* with deadlines. Maybe you aren't being picky enough?
>
> regards
>  Steve
> --
> DjangoCon US 2010 September 7-9 http://djangocon.us/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Python unexpectedly quit

[Steve Holden]

On 9/24/2010 2:23 PM, Axel Bock wrote:
> Anything wrong here? I must say, the framework for the people "with
> deadlines" is giving me a *really* hard time so far :) .

Maybe you aren't in enough of a hurry? And, by the way, it's
*perfectionists* with deadlines. Maybe you aren't being picky enough?

regards
 Steve
-- 
DjangoCon US 2010 September 7-9 http://djangocon.us/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How do you set choices in your application?

[Yo-Yo Ma]

Anyone have any thoughts.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Problem with reversing url in test

[Brandon Taylor]

So it appears to be something with django-cms' urls that are causing
issues with testing. I'm able to test any URL that isn't controlled by
dajngo-cms, like '/admin/' or whatever.

Anyone else using django-cms v2 and Django 1.1.1 experiencing these
issues?

TIA,
Brandon

On Sep 24, 6:40 am, Brandon Taylor  wrote:
> So here's something else that's weird...
>
> I can start a shell, load up the test Client and get the page in
> question:
>
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)>>> from django.test.client import Client
> >>> c = Client()
> >>> response = c.get('/categories/')
> >>> response.status_code
>
> 200
>
> Anyone have any ideas what could be wrong with the unit test?
>
> On Sep 23, 10:51 pm, Brandon Taylor  wrote:
>
>
>
> > Hi everyone,
>
> > I'm having a problem with reversing a URL in a unit test:
>
> > class ProductTestCase(TestCase):
> >     def setUp(self):
> >         self.client = Client
>
> >     def test_project_permalink(self):
> >         project = Project.approved.all()[0]
> >         url = project.get_absolute_url()
>
> > I'm using an initial_data.json fixture that I exported from my current
> > database, and I'm able to use the get_absolute_url method to navigate
> > to a project detail page without error.
>
> > When I try to reverse this url pattern in a test, I get a
> > NoReverseMatch exception. django-cms is also running on my site, but
> > disabling that app, and its url patterns doesn't make a difference.
>
> > Anyone have any ideas on why this method would fail?
>
> > TIA,
> > Brandon

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: The REAL superuser

[Karen Tracey]

On Fri, Sep 24, 2010 at 6:02 PM, aug dawg  wrote:

> Hey all,
>
> I'm currently learning how to use Django, so earlier this evening I spent
> about 30 minutes working on a blog engine. I used the admin interface and
> ran 'python manage.py syncdb'. I then run the dev server. I log in to the
> admin interface successfully, but then it says I don't have permission to
> edit anything. I even manually created a superuser. Can anyone help me out?
>
>
Admin says you don't have permission to edit anything regardless of your
superuser status when it there have been no models registered for it to
manage. So either there are no admin.py files in any of the INSTALLED_APPS
or (more likely) the admin.autodiscover() call in urls.py has been left
commented out (part of the instructions for enabling the admin include
uncommenting that line. The admin.autodiscover() call is what ensures the
registrations done in admin.py files in all installed apps are actually
executed.

Karen
-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Flatpages incorrect 302 to 404

[Josh]

I have a django project, its a satchmo store.  I have noticed that
when the flatpages middleware is in my settings.py 404s seem to be
handled incorrectly.  i.e. if a page really does not exist the server
first sends a 302 response, then a 404.  When google crawls it only
sees the 302 so it thinks that something is there even tho nothing is
there.  Because of this combined with the fact that the structure of
the site recently significantly changed google has a lot of broken
links and none of them get fixed because the initial 302 makes google
think something is there.
I think this happens because the flatpages middleware intercepts 404s
to see if there is a flatpage, but it seems incorrect.  If I remove
the flatpages middleware 404 function correctly.  Has anyone else
noticed this or does anyone know of a workaround?  I need flatpages,
but I need 404s to behave correctly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Since Django 1.2.3, I can't display any Form

[François Bonnefont]

Hi,

I am new to this group and not sure how to present my problem
correctly...

I was working with django 1.1 and made a very small and simple
application with a "ContactForm" not related to any model.

My forms.py :

from django import forms

class ContactForm(forms.Form):
firstname = forms.CharField(max_length=50)
lastname = forms.CharField(max_length=50)


Recently I updated to Django 1.2.3 and since then I get :

"AttributeError: 'CharField' object has no attribute 'prepare_value'"
when I try to print this form (or any other form).

I even tried this example, 
http://docs.djangoproject.com/en/1.2/ref/forms/api/#dynamic-initial-values,
from Django documentation, in a python shell and I always get the same
error...

Here is the full stacktrace output :

/Library/Python/2.6/site-packages/django/utils/encoding.py in
__str__(self)
 25 """
 26 def __str__(self):
---> 27 return self.__unicode__().encode('utf-8')
 28
 29 def smart_unicode(s, encoding='utf-8', strings_only=False,
errors='strict'):

/Library/Python/2.6/site-packages/django/forms/forms.py in
__unicode__(self)
 93
 94 def __unicode__(self):
---> 95 return self.as_table()
 96
 97 def __iter__(self):

/Library/Python/2.6/site-packages/django/forms/forms.py in
as_table(self)
215 row_ender = u'',
216 help_text_html = u'%s',
--> 217 errors_on_separate_row = False)
218
219 def as_ul(self):

/Library/Python/2.6/site-packages/django/forms/forms.py in
_html_output(self, normal_row, error_row, row_ender, help_text_html,
errors_on_separate_row)
178 'errors': force_unicode(bf_errors),
179 'label': force_unicode(label),
--> 180 'field': unicode(bf),
181 'help_text': help_text,
182 'html_class_attr': html_class_attr

/Library/Python/2.6/site-packages/django/forms/forms.py in
__unicode__(self)
406 if self.field.show_hidden_initial:
407 return self.as_widget() +
self.as_hidden(only_initial=True)
--> 408 return self.as_widget()
409
410 def _errors(self):

/Library/Python/2.6/site-packages/django/forms/forms.py in
as_widget(self, widget, attrs, only_initial)
442 else:
443 data = self.data
--> 444 data = self.field.prepare_value(data)
445
446 if not only_initial:

AttributeError: 'CharField' object has no attribute 'prepare_value'.

I googled "prepare_value + django" and didn't find any other person
having this problem.

What am I doing wrong?

Any clue would be a great help!

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

The REAL superuser

[aug dawg]

Hey all,

I'm currently learning how to use Django, so earlier this evening I spent
about 30 minutes working on a blog engine. I used the admin interface and
ran 'python manage.py syncdb'. I then run the dev server. I log in to the
admin interface successfully, but then it says I don't have permission to
edit anything. I even manually created a superuser. Can anyone help me out?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: mod_wsgi, apache, windows XP

[chauhonglinh]

I believe that the error
[Fri Sep 03 08:36:25 2010] [error] [client 127.0.0.1] Try using
django.db.backends.XXX, where XXX is one of:
[Fri Sep 03 08:36:25 2010] [error] [client 127.0.0.1] 'dummy',
'mysql', 'oracle', 'postgresql', 'postgresql_psycopg2', 'sqlite3'
[Fri Sep 03 08:36:25 2010] [error] [client 127.0.0.1] Error was:
cannot import name utils

is a problem in the file django/db/backends/postgresql_psycopg2/
base.py, version 2.2.2, line number 9
from django.db import utils

I don't know why it happens, because in the directory 'djtrunk/django/
db/', there is a file named 'utils.py'

Probably a privilege issue?

Anybody has any idea?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

How do you set choices in your application?

[Yo-Yo Ma]

Let's say I have a model with a field called "status". I could set the
choices in three ways:

1)   status_choices = ((1, 'Completed'), (2, 'Unfinished'), (3,
'Cancelled'))


2)  status_choices = (('COM', 'Completed'), ('UNF', 'Unfinished'),
('CAN', 'Cancelled'))


Or, 3 ):

db_choices = Choice.objects.all()
status_choices = [[choice.pk, choice.description] for choice in
db_choices]

Is there any best practice? Note: Client's won't be able to define
these choices. They'll all be defined by me (or else DB would be the
answer of course).

My thoughts:

1) Risky (data is useless without python file), 2) Slower, and risky
because it might be difficult to change later, 3) a lot of work, and
slow (because of DB).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Jason]

> Well, first I can to "if X == Student: ...", and I know the fields will be
> there.
> Second, User will have no additional properties (as I understand), but once
> I do "Model --> User" relations ALL users will have that property. So each
> user might have the .course property, AND the .subject property (which might
> be for teachers), AND the .function property, which might be for
> administrative staff (I'm making things up here :). So all properties would
> be present, they may not be mandatory, cause a teacher is never part of a
> course, so I have to ensure data consistency in the application logic. That
> sucks.
>
> Subclassing relieves me from this just nicely, AND this is the mother of all
> prototype examples of OOP - base class, specialized subclasses. The only
> thing more cliché would be "Car" -> "Van" / "Compact" / ... .

I subclass a lot of stuff in Django. It's useful, I agree. I'm ALL
about OOP.

My gut tells me to leave that stuff out of Auth.User.  If you were
extending the authorization / authentication aspects of it, I would
agree. You're adding courses though which does not at all sound like a
good idea to me.

Course should be a model and it should have a manytomany field for
users or other intermediate table if you need more attributes on the
relationship itself.

"Well, first I can to "if X == Student: ...", and I know the fields
will be there."
You can do that as well with groups by adding the information as they
are added to the group. (signals, etc).

"...but once I do "Model --> User" relations ALL users will have that
property."
Well, all users will be able to query the attribute but it will just
be null.

some_dude = Users.objects.get(username='the_dude')
courses = some_dude.course_set.all()

Anyhow - the real deal breaker for me is overlapping user types. If
that's not a problem, you'll probably be fine in making it work.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Python unexpectedly quit

[Axel Bock]

oh f...

thanks.

2010/9/24 Scott Gould 

>
> > def logout(request):
> > logout(request)
>
> Infinite loop, no?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Python unexpectedly quit

[Scott Gould]

> def logout(request):
>     logout(request)

Infinite loop, no?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Axel Bock]

2010/9/24 Jason 

>
> "Creating the relationship between User and UserInfo has some
> implications I'd like to avoid on a model-level"
>
> Specifically what are you referring to here? Because anytime you
> subclass in Django you are basically doing the exact thing in the
> database behind the scenes and as result accessing the data turns out
> to be pretty similar (just about as easy both ways).
>

Well, first I can to "if X == Student: ...", and I know the fields will be
there.
Second, User will have no additional properties (as I understand), but once
I do "Model --> User" relations ALL users will have that property. So each
user might have the .course property, AND the .subject property (which might
be for teachers), AND the .function property, which might be for
administrative staff (I'm making things up here :). So all properties would
be present, they may not be mandatory, cause a teacher is never part of a
course, so I have to ensure data consistency in the application logic. That
sucks.

Subclassing relieves me from this just nicely, AND this is the mother of all
prototype examples of OOP - base class, specialized subclasses. The only
thing more cliché would be "Car" -> "Van" / "Compact" / ... .

I might have a look into groups, but I need certain properties for the
users. Groups seem to manage the database permissions just fine, but I'm all
in for class / instance properties.

The best part is: In theory it is all VERY simple: The subclassing works
just fine. It even seems to run a feature of Django - subclassing of models,
since version IForgotWhich. Also the model behaves just as expected, the
database looks like it should. But then I run into trouble because I cannot
display ONE --CENSORED-- FIELD as of now in the admin "create" interface.
And so far no one was able to give me an answer, although I found examples
on the web - unfortunately they don't work here. And everything I try simply
does not work with the magic of that --censored-- UserAdmin manager. (Yes, I
am a bit frustrated here).

Right now I switch between two different Admin classes to create some test
users, which SUCKS.

I surely *cannot* be the only guy who does things like this, or who came up
with that idea. Can I? I mean, I posted the articles of other people,
who did just the same, right??

Although I still like Django, cause I really just started with it. But ...
well, my patience is getting a tiny little bit thin, if I don't get some
little successes out of it soon.



So --- am I right? Specifically about the "All users have that property
then" part?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Recommend a book

[Tim Johnson]

* Sandro Dutra  [100924 09:28]:
> "The Definitive Guide to Django: Web Developement Done Right", Apress,
> updated Django 1.1
> "Pratical Django Projects", Apress, updated Django 1.1
   Thanks for all the input. I know have the means to make a
   decision.

   cheers
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Jason]

Don't get me wrong - I'm not saying my way is right and I'm not saying
anyone is doing anything necessarily wrong.
I'm still a Django noob in a lot of ways.

Just things to keep in mind - if you do have multiple types of users
subclassing might be a bad idea if there are possibilities of being
classified as more than one.

"A user can be created without attaching the UserInfo information (I
did
this already, and unless I did something wrong, I could do just that).
So I
have to add application logic to make sure that a Student actually has
a
UserInfo object attached. Also because of my different system users it
would
make no sense to actually attach that to EVERY user"

I think here you're going to have about the same amount of work no
matter what method you go with. You can use save signals (or maybe
just overload save itself) to look at groups and add related info. I
have to hand it to you though - it's not going to be trivial no matter
what way you pick. The admin seems like it wouldn't be that easy to
deal with creating multiple subclasses of User.


"Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level"

Specifically what are you referring to here? Because anytime you
subclass in Django you are basically doing the exact thing in the
database behind the scenes and as result accessing the data turns out
to be pretty similar (just about as easy both ways).


You can also create managers on User - so you can do:

students = User.students.filter(...)


I'm definitely not saying you're wrong here BTW. I'm just giving an
alternative.


On Sep 24, 9:47 am, Axel Bock  wrote:
> Thanks a lot for your answers.
>
> I thought subclassing users is a nice idea, cause a Student IS a user, with
> a few extended attributes. I decided to subclass users, because ...
>
> * when adding a UserInfo -> user relationship (class UserInfo(Model): user =
> ForeignKey('User')), ALL users having a userinfo. this is bad if I have
> different kind of users (I do.), so I do not really want that.
>
> * A user can be created without attaching the UserInfo information (I did
> this already, and unless I did something wrong, I could do just that). So I
> have to add application logic to make sure that a Student actually has a
> UserInfo object attached. Also because of my different system users it would
> make no sense to actually attach that to EVERY user
>
> * I have read this 
> one:http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-mod
> Subclassing models actually seems to be the "new" way of doing things, so
> why should be User an exception to this rule?
>
> * I also have read this 
> article:http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-i...
>
> * And this 
> article:http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-c...
> the main one why I wanted this)
>
> So, all in all, if it is possible AND a common way to go, I'd prefer it that
> way. Creating the relationship between User and UserInfo has some
> implications I'd like to avoid on a model-level.
>
> If they are all wrong, I REALLY think the API should not let people do this.
> If they are right, then I still lack an anwer for my problem - the single
> f*cked up field in the create student form, which I'd like to shoot on sight
> once it's there and then burn the ashes :) . (I have had not much sleep
> tonight ...)
>
> Thanks!
> Axel.
>
> 2010/9/24 Vasil Vangelovski 
>
>
>
> > Mainly, I just don't think you're subclassing User for the right
> >> reasons. In fact, I can't really think of anytime I would subclass
> >> it.  Usually adding a related table is a better way to go (lookup
> >> django user profiles for example).
>
> >  There are times when the builtin User model is not enough, that's why
> > there is a way to specify user profiles. There are times when you want to be
> > sure that every user in the system has a profile (some filed in the profile
> > is required for the system to work properly), even for the users added from
> > the admin. This can lead people to try all kinds of hacks, like subclassing
> > user, which there is a way to implement but will lead you in all kinds of
> > trouble. Then there is the case where you want all users to be staff no
> > matter what, which makes the field superficial, but leads to extra
> > uneccessary work on the developers part to make sure it works that way.
> > These are all real world scenarios I've encountered, and I'm guilty of
> > pushing a subclassed user model in the past.
>
> > If the api leads a lot of people to try all kinds of hacks around it to
> > achieve what they want, blame the API not the people. Providing concrete
> > models for users in contrib leads to more pain than the time or trouble it
> > saves.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to 

Python unexpectedly quit

[Axel Bock]

HI all,


another problem here: On my system (MacBook Pro, OS X newest version) Python
"unexpectedly" quits when I invoke localhost:8000/logout.
The code for that looks like this:


#urls.py:

urlpatterns += patterns('webflog.flightlog',
# 
(r'^logout/',   'views.logout'),
)


# views.py

def logout(request):
logout(request)
return HttpResponseRedirect('/login')


Anything wrong here? I must say, the framework for the people "with
deadlines" is giving me a *really* hard time so far :) .


Thanks in advance!
Axel.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: fixtures and dates

[Shawn Milochik]

We need more information. Preferably the full traceback.

In short, something is trying to add a date object to a unicode text
object. Possibly the date as a date object and the time as a unicode
string. How did you convert the original data to JSON?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

fixtures and dates

[CrabbyPete]

I have a spreadsheet of football games that I wanted to get into an
sqlite3 database. I converted it to json, but when i loaded it I was
required to put the date in -MM-DD format. So I changed it. The
problem is now when I run the admin and look at the game I get this
error

TemplateSyntaxError at /admin/football/game/
Caught TypeError while rendering: unsupported operand type(s) for +:
'datetime.date' and 'unicode'

Any ideas why?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Recommend a book

[Sandro Dutra]

"The Definitive Guide to Django: Web Developement Done Right", Apress,
updated Django 1.1
"Pratical Django Projects", Apress, updated Django 1.1

2010/9/24 Shawn Milochik 

>
> On Sep 24, 2010, at 6:53 AM, Franklin Einspruch wrote:
>
> > I recommend against Beginning Django E-Commerce in favor of The
> > Definitive Guide. The project described in the former has you chasing
> > down so many details that it's hard to get a sense of the big picture.
> > As a second book it's more informative.
> >
> > Franklin
>
> I agree, not only because "The Definitive Guide" is much better, but also
> because I didn't think the other title was any good, really. I thought some
> of the SEO info was very useful, but I got the feeling that this book could
> have been written about any language or framework, almost as though the
> author picked Django by a roll of the dice. It's a poor book for learning
> Django.
>
> Shawn
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

show mail as the option instead username in admin

[Alexandre González]

Hi!

I like to show the email instead the username in the  that django
uses when you define you attrib as ForeignKey in your model.

Anybody know how can I do this?

Thanks!

-- 
@agonzalezro 
Please, don't send me files with extensions: .doc, .docx, .xls, .xlsx, .ppt
and/or .pptx

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Axel Bock]

Thanks a lot for your answers.

I thought subclassing users is a nice idea, cause a Student IS a user, with
a few extended attributes. I decided to subclass users, because ...

* when adding a UserInfo -> user relationship (class UserInfo(Model): user =
ForeignKey('User')), ALL users having a userinfo. this is bad if I have
different kind of users (I do.), so I do not really want that.

* A user can be created without attaching the UserInfo information (I did
this already, and unless I did something wrong, I could do just that). So I
have to add application logic to make sure that a Student actually has a
UserInfo object attached. Also because of my different system users it would
make no sense to actually attach that to EVERY user

* I have read this one:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/.
Subclassing models actually seems to be the "new" way of doing things, so
why should be User an exception to this rule?

* I also have read this article:
http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-in-the-Django-Admin-Site/

* And this article:
http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-change-authentication-middleware/(actually
the main one why I wanted this)

So, all in all, if it is possible AND a common way to go, I'd prefer it that
way. Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level.

If they are all wrong, I REALLY think the API should not let people do this.
If they are right, then I still lack an anwer for my problem - the single
f*cked up field in the create student form, which I'd like to shoot on sight
once it's there and then burn the ashes :) . (I have had not much sleep
tonight ...)


Thanks!
Axel.

2010/9/24 Vasil Vangelovski 

>
> Mainly, I just don't think you're subclassing User for the right
>> reasons. In fact, I can't really think of anytime I would subclass
>> it.  Usually adding a related table is a better way to go (lookup
>> django user profiles for example).
>>
>
>  There are times when the builtin User model is not enough, that's why
> there is a way to specify user profiles. There are times when you want to be
> sure that every user in the system has a profile (some filed in the profile
> is required for the system to work properly), even for the users added from
> the admin. This can lead people to try all kinds of hacks, like subclassing
> user, which there is a way to implement but will lead you in all kinds of
> trouble. Then there is the case where you want all users to be staff no
> matter what, which makes the field superficial, but leads to extra
> uneccessary work on the developers part to make sure it works that way.
> These are all real world scenarios I've encountered, and I'm guilty of
> pushing a subclassed user model in the past.
>
> If the api leads a lot of people to try all kinds of hacks around it to
> achieve what they want, blame the API not the people. Providing concrete
> models for users in contrib leads to more pain than the time or trouble it
> saves.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Vasil Vangelovski]

> Mainly, I just don't think you're subclassing User for the right
> reasons. In fact, I can't really think of anytime I would subclass
> it.  Usually adding a related table is a better way to go (lookup
> django user profiles for example).
>

 There are times when the builtin User model is not enough, that's why there
is a way to specify user profiles. There are times when you want to be sure
that every user in the system has a profile (some filed in the profile is
required for the system to work properly), even for the users added from the
admin. This can lead people to try all kinds of hacks, like subclassing
user, which there is a way to implement but will lead you in all kinds of
trouble. Then there is the case where you want all users to be staff no
matter what, which makes the field superficial, but leads to extra
uneccessary work on the developers part to make sure it works that way.
These are all real world scenarios I've encountered, and I'm guilty of
pushing a subclassed user model in the past.

If the api leads a lot of people to try all kinds of hacks around it to
achieve what they want, blame the API not the people. Providing concrete
models for users in contrib leads to more pain than the time or trouble it
saves.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Jason]

I'm not sure how to solve your exact problem but I would recommend NOT
extending the user class here.

You'll probably want to create a manytomany field on your Course model
that contains users.

And if you're going to have many different types of users you'll want
to create groups. Put students in the 'students' group.


Mainly, I just don't think you're subclassing User for the right
reasons. In fact, I can't really think of anytime I would subclass
it.  Usually adding a related table is a better way to go (lookup
django user profiles for example).

On Sep 24, 12:29 am, Axel  wrote:
> All right, I found some 
> sources.http://stackoverflow.com/questions/1061279/for-the-django-admin-how-d...http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-i...
>
> By strictly holding to these, and by experimenting, I now get this:
>
> _'StudentAdmin.fieldsets[0][1]['fields']' refers to field 'course'
> that is missing from the form._
>
> Adding a class StudentCreateForm(UserCreationForm) does not help,
> either:
>
> class StudentCreateForm(UserCreationForm):
>     course = forms.CharField()
> class StudentAdmin(UserAdmin):
>     # ...
>     add_form = StudentCreateForm
>
> Please, I am going crazy. There's probably a super-simple solution,
> but I don't seem to find it. And I feel horribly stupid right now. And
> it's several hours now, cause I can't let go - and I'm horribly tired.
>
> Thanks,
> Axel.
>
> On Sep 23, 11:29 pm, Axel Bock  wrote:
>
> > Hello all,
>
> > I must admit - I am going crazy. With something I thought should be
> > incredibly simple, but maybe I am just too f**king stupid.
>
> > All right, here comes my problem. I have subclassed "User" as "Student" and
> > added some required fields, one of them being "Course":
>
> > # models.py
> > class Student(User):
> >     course = models.ForeignKey('Course')
>
> > So far, so good. Now I couldn't create a Student with an initial password -
> > the password field was plaintext, and the "change password" form wouldn't
> > work. I dug through the code and some postings, and discovered that if I
> > used a custom admin class it would just work fine, with the advantage that I
> > could exclude some fields I don't need in the admin view of the Students.
> > That basically looks like this:
>
> > # admin.py
> > class StudentAdmin(UserAdmin):
> >     fieldsets = ( #...
> >     )
> > admin.site.register(Student, StudentAdmin)
> > *
> > Then* I got another annoyance. If I tried to create a Student now, I was
> > confronted with the "usual" User creation screen. (Huh? ... ok, dig a bit in
> > Django internals, one can only learn ...). Basically I wouldnt mind, but the
> > Student creation does not work any more - the simple add user screen will of
> > course set no "course" value in the Student model, So I dug further. I
> > discovered that the user creation was handled by a form called
> > UserCreationForm, and this form explicitly excluded alot of stuff.
>
> > But now the magic went crazy. If I look at the UserCreationForm class, I
> > see:
>
> >     class Meta:
> >         model = User
> >         fields = ("username",)
>
> > WTF? The only field which *should* be seen is "username", according to the
> > docs (according 
> > tohttp://docs.djangoproject.com/en/1.2/topics/forms/modelforms/). But there 
> > is
> > password AND username. Aha. I am pretty confused now. But not without
> > optimism. I tried subclassing the form now, which looked something like
> > this:
>
> > *class StudentCreationForm(UserCreationForm):
> >     class Meta():
> >         model = Student
> >         fields = ('course')
> > *
> > class StudentAdmin(UserAdmin):
> >     #fields = ('first_name', 'family_name', 'password', 'course', 'base')
> >     fieldsets = ( # ... cut out
> >     *add_form = StudentCreationForm*
>
> > And the result? No luck. WhatEVER I do (replacing UserCreationForm with
> > subclass of ModelForm, overriding get_form(), and some other things), the
> > form will only and inevitably show "username" and "password".
>
> > And it's about two hours now.
>
> > Help.
>
> > Please.
>
> > Thanks!
> > Axel.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Universal form

[Tran Cao Thai]

isn't it unnatural to force user go around the site before going to the
right place? Anyway, i will go around with all the ways first before making
decision

Thanks everybody

On Sat, Sep 25, 2010 at 1:30 AM, Nick Arnett  wrote:

> I was tackling this problem recently and found several approaches by
> searching for Django login form.  I ended up using a middleware solution
> that brings up a login page no matter where the user tries to go, then
> redirects them to the page they were trying to view... but that only makes
> sense if your users aren't allowed to see any page without logging in.
>
> See
> http://www.mail-archive.com/django-develop...@googlegroups.com/msg06473.html
>
> 
> Nick
>
> On Fri, Sep 24, 2010 at 8:23 AM, Tran Cao Thai  > wrote:
>
>> Hello all,
>>
>> I have a login form that should appear in every pages of the site. How can
>> i create it from the views file ? Since every form is triggered by calling a
>> function in the views file, do i have to create the form in every function?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Universal form

[Nick Arnett]

I was tackling this problem recently and found several approaches by
searching for Django login form.  I ended up using a middleware solution
that brings up a login page no matter where the user tries to go, then
redirects them to the page they were trying to view... but that only makes
sense if your users aren't allowed to see any page without logging in.

See
http://www.mail-archive.com/django-develop...@googlegroups.com/msg06473.html


Nick

On Fri, Sep 24, 2010 at 8:23 AM, Tran Cao Thai
wrote:

> Hello all,
>
> I have a login form that should appear in every pages of the site. How can
> i create it from the views file ? Since every form is triggered by calling a
> function in the views file, do i have to create the form in every function?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Universal form

[Tran Cao Thai]

a little bit search ends up with django-annoying. Is there anyone using it ?
which one is better ?

On Sat, Sep 25, 2010 at 1:25 AM, Shawn Milochik  wrote:

> Context processors will do this for you.
>
>
> http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Universal form

[Shawn Milochik]

Context processors will do this for you.

http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Universal form

[Tran Cao Thai]

Hello all,

I have a login form that should appear in every pages of the site. How can i
create it from the views file ? Since every form is triggered by calling a
function in the views file, do i have to create the form in every function?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: admin panel fieldsets for different type of users?

[Profuel]

We've faced with same and other problems linked to the same issue.
The idea is that DJango caches every object that's used in Admin.
So, when you do exclude field, you should get it back to form in other
cases.

--
if not request.user.is_superuser:
self.exclude.append('A')
else:
self.exclude.pop('A')
--

The other universal solution is to reload admin class(es) everytime
request is being processed.
This will decrease speed, but no need to reenable & repopulate all
data in admin models.

Andrey

> class CarsAdmin(admin.ModelAdmin):
>   fieldsets = (_('first group'},{'fields':(('A','B'),('C','D'),)})
>   def get_form(self,request,obj=None, **kwargs):
>     self.exclude = []
>     if not request.user.is_superuser:
>        self.exclude.append('A')
>     return super(CarAdmin,self).get_form(request, obj=None, **kwargs)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: File Upload Content Type Verification

[Federico Capoano]

Thanks.

I'm concerned about the possibility of uploading and executing a
script on the server. Just this. I think I can avoid this by hiding
the file somewhere behind the public folder so the content is not
accessible via http.



On 24 Set, 13:31, Tom Evans  wrote:
> On Fri, Sep 24, 2010 at 12:23 PM, Federico Capoano
>
>  wrote:
> > I can't trust the user because this field will be used in the
> > frontend, which will be an app similar to the django admin, but much
> > more limited.
>
> > So according to what you said, there is no standard way to do this.
> > the second solution seems interesting.
>
> > But what if I wanted to restrict to images?
>
> > What's the best way to avoid security issues? Maybe store the file
> > somewhere hidden would be safer?
>
> Depends what you mean by 'standard'. I would consider it standard to
> validate user supplied input, and that process is the same regardless
> of filetype, the only thing that changes is how you validate the
> input.
>
> For images, you can simply use a ImageField, which uses PIL to
> validate that the uploaded file is an image file supported by PIL.
>
> I don't understand what security issues you are referring to.
>
> Cheers
>
> Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Recommend a book

[Shawn Milochik]

On Sep 24, 2010, at 6:53 AM, Franklin Einspruch wrote:

> I recommend against Beginning Django E-Commerce in favor of The
> Definitive Guide. The project described in the former has you chasing
> down so many details that it's hard to get a sense of the big picture.
> As a second book it's more informative.
> 
> Franklin

I agree, not only because "The Definitive Guide" is much better, but also 
because I didn't think the other title was any good, really. I thought some of 
the SEO info was very useful, but I got the feeling that this book could have 
been written about any language or framework, almost as though the author 
picked Django by a roll of the dice. It's a poor book for learning Django.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Problem with reversing url in test

[Brandon Taylor]

So here's something else that's weird...

I can start a shell, load up the test Client and get the page in
question:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.test.client import Client
>>> c = Client()
>>> response = c.get('/categories/')
>>> response.status_code
200

Anyone have any ideas what could be wrong with the unit test?

On Sep 23, 10:51 pm, Brandon Taylor  wrote:
> Hi everyone,
>
> I'm having a problem with reversing a URL in a unit test:
>
> class ProductTestCase(TestCase):
>     def setUp(self):
>         self.client = Client
>
>     def test_project_permalink(self):
>         project = Project.approved.all()[0]
>         url = project.get_absolute_url()
>
> I'm using an initial_data.json fixture that I exported from my current
> database, and I'm able to use the get_absolute_url method to navigate
> to a project detail page without error.
>
> When I try to reverse this url pattern in a test, I get a
> NoReverseMatch exception. django-cms is also running on my site, but
> disabling that app, and its url patterns doesn't make a difference.
>
> Anyone have any ideas on why this method would fail?
>
> TIA,
> Brandon

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: File Upload Content Type Verification

[Tom Evans]

On Fri, Sep 24, 2010 at 12:23 PM, Federico Capoano
 wrote:
> I can't trust the user because this field will be used in the
> frontend, which will be an app similar to the django admin, but much
> more limited.
>
> So according to what you said, there is no standard way to do this.
> the second solution seems interesting.
>
> But what if I wanted to restrict to images?
>
> What's the best way to avoid security issues? Maybe store the file
> somewhere hidden would be safer?
>

Depends what you mean by 'standard'. I would consider it standard to
validate user supplied input, and that process is the same regardless
of filetype, the only thing that changes is how you validate the
input.

For images, you can simply use a ImageField, which uses PIL to
validate that the uploaded file is an image file supported by PIL.

I don't understand what security issues you are referring to.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

RE: Re: File Upload Content Type Verification

[Henrik Genssen]

for images PIL does the job more or less well for all the filetypes
and formats it knows (validation build in ImageField) I have recognized problems
with some image file types...

you may also do some virus scan...
we added clamav (pyclamd) to the clean method...

regards

Henrik

>reply to message:
>date: 24.09.2010 06:23:55
>from: "Federico Capoano" 
>to: "Django users" 
>subject: Re: File Upload Content Type Verification
>
>I can't trust the user because this field will be used in the
>frontend, which will be an app similar to the django admin, but much
>more limited.
>
>So according to what you said, there is no standard way to do this.
>the second solution seems interesting.
>
>But what if I wanted to restrict to images?
>
>What's the best way to avoid security issues? Maybe store the file
>somewhere hidden would be safer?
>
>
>
>
>On 24 Set, 13:08, Tom Evans  wrote:
>> On Fri, Sep 24, 2010 at 11:28 AM, Federico Capoano
>>
>>  wrote:
>> > Is there a way we can check if a certain file being uploaded is really
>> > what it claims to be?
>> > Let's say I want to restrict files to PDF only, then I take a php
>> > script and I rename it PDF I can still upload it if using the
>> > following custom FileField that I just worked out yesterday:
>>
>> If you're not willing to trust the user, then you must validate the
>> uploaded file. I can think of three straightforward ways to do so:
>>
>> 1) Use file(1) to determine the true file type. This will be just a
>> guess from the opening few bytes of the file, and could be fooled by
>> clever manipulation of the uploaded file.
>>
>> 2) Use ghostscript and it's utilities to validate the pdf file.
>> Something along these lines:
>>
>>   try:
>>       is_pdf = (subprocess.check_call(['pdf2ps', '/path/to/file.pdf',
>> '/dev/null']) == 0)
>>   except subprocessCalledProcessError:
>>       is_pdf = False
>>
>> 3) Use a pure python library like pyPdf to examine it. I wouldn't
>> recommend this, it's a bit old and crufty.
>>
>> Cheers
>>
>> Tom
>
>-- 
>You received this message because you are subscribed to the Google Groups 
>"Django users" group.
>To post to this group, send email to django-us...@googlegroups.com.
>To unsubscribe from this group, send email to 
>django-users+unsubscr...@googlegroups.com.
>For more options, visit this group at 
>http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: File Upload Content Type Verification

[Federico Capoano]

I can't trust the user because this field will be used in the
frontend, which will be an app similar to the django admin, but much
more limited.

So according to what you said, there is no standard way to do this.
the second solution seems interesting.

But what if I wanted to restrict to images?

What's the best way to avoid security issues? Maybe store the file
somewhere hidden would be safer?




On 24 Set, 13:08, Tom Evans  wrote:
> On Fri, Sep 24, 2010 at 11:28 AM, Federico Capoano
>
>  wrote:
> > Is there a way we can check if a certain file being uploaded is really
> > what it claims to be?
> > Let's say I want to restrict files to PDF only, then I take a php
> > script and I rename it PDF I can still upload it if using the
> > following custom FileField that I just worked out yesterday:
>
> If you're not willing to trust the user, then you must validate the
> uploaded file. I can think of three straightforward ways to do so:
>
> 1) Use file(1) to determine the true file type. This will be just a
> guess from the opening few bytes of the file, and could be fooled by
> clever manipulation of the uploaded file.
>
> 2) Use ghostscript and it's utilities to validate the pdf file.
> Something along these lines:
>
>   try:
>       is_pdf = (subprocess.check_call(['pdf2ps', '/path/to/file.pdf',
> '/dev/null']) == 0)
>   except subprocessCalledProcessError:
>       is_pdf = False
>
> 3) Use a pure python library like pyPdf to examine it. I wouldn't
> recommend this, it's a bit old and crufty.
>
> Cheers
>
> Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: File Upload Content Type Verification

[Tom Evans]

On Fri, Sep 24, 2010 at 11:28 AM, Federico Capoano
 wrote:
> Is there a way we can check if a certain file being uploaded is really
> what it claims to be?
> Let's say I want to restrict files to PDF only, then I take a php
> script and I rename it PDF I can still upload it if using the
> following custom FileField that I just worked out yesterday:
>


If you're not willing to trust the user, then you must validate the
uploaded file. I can think of three straightforward ways to do so:

1) Use file(1) to determine the true file type. This will be just a
guess from the opening few bytes of the file, and could be fooled by
clever manipulation of the uploaded file.

2) Use ghostscript and it's utilities to validate the pdf file.
Something along these lines:

  try:
  is_pdf = (subprocess.check_call(['pdf2ps', '/path/to/file.pdf',
'/dev/null']) == 0)
  except subprocessCalledProcessError:
  is_pdf = False

3) Use a pure python library like pyPdf to examine it. I wouldn't
recommend this, it's a bit old and crufty.


Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Problem importing model after inspectdb

[bruno desthuilliers]

On 24 sep, 02:33, Ivan  wrote:
> Hi all,
> I'm trying to build a Django project by working through the handbook
> but I'm having some problems accessing the database by referencing the
> model I've created from it (by inspectdb). When attemping to do some
> "Basic Data Access" (Chapter 5) I can't import the models I've made
> (from [app name].models import [model name]), with the console
> erroring 'ImportError: cannot import name [model name]'.

Please post the _exact_ import statement AND the _full_ traceback
(copy/paste from your shell).

> I checked the
> models.py inspectdb made with 'python manage.py validate' and 'python
> manage.py syncdb' exits with 'No fixtures found'. I would appreciate
> any help I can get. Thanks
>
> Here is my models.py from my app:http://pastebin.ca/1947921
>
> And here is my settings.pyhttp://pastebin.ca/1947922

"""
INSTALLED_APPS = (
# 'django.contrib.auth',
# 'django.contrib.contenttypes',
# 'django.contrib.sessions',
# 'django.contrib.sites',
# 'django.contrib.messages',
# Uncomment the next line to enable the admin:
# 'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',
   'SpliceProtDB.db_interface',
)
"""

Wild guesses since we lack some useful informations:

1/ Make sure that your 'db_interface' app folder has an __init__.py
file
2/ make sure your project's directory if effectively named
"SpliceProtDB", or (better) just use the app name (IOW : remove
"SpliceProdDB." from the app name)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Recommend a book

[Franklin Einspruch]

I recommend against Beginning Django E-Commerce in favor of The
Definitive Guide. The project described in the former has you chasing
down so many details that it's hard to get a sense of the big picture.
As a second book it's more informative.

Franklin

On Thu, Sep 23, 2010 at 11:21 PM, Ivan  wrote:
> Personally, I like hand on. "Practical Django Projects" is
> recommended. http://apress.com/book/view/9781590599969
>
>
>
> On Fri, Sep 24, 2010 at 12:38 PM, Tim Johnson  wrote:
>> Thank you -
>>  Shawn Milochik and Tran Cao Thai. :) thus far.
>>  I'll check back in the morning.
>>  cheers
>> --
>> Tim
>> tim at johnsons-web.com or akwebsoft.com
>> http://www.akwebsoft.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To post to this group, send email to django-us...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>



-- 
Art, writing, journal: http://einspruch.com
Comics: http://themoonfellonme.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Newbie: Operational Error 1060 Duplicate column name

[bruno desthuilliers]

On 24 sep, 05:20, Howard Wolf  wrote:
> I want the foreign key to be called taxonomy_kingdom.
>
> So would I do something like this?
>
> taxonomy_kingdom = models.ForeignKey(TaxonomyKingdom, null=True, blank=True)
> superior=taxonomy_kingdom

This will yield the exact same result as your previous code snippet.
What are you trying to do with this 'superior=taxonomy_kingdom'
statement ? (and while we're at it, what are you trying to do with the
'superior=0' statement in TaxonomyKingdom ?)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

File Upload Content Type Verification

[Federico Capoano]

Is there a way we can check if a certain file being uploaded is really
what it claims to be?
Let's say I want to restrict files to PDF only, then I take a php
script and I rename it PDF I can still upload it if using the
following custom FileField that I just worked out yesterday:

from django.db.models import FileField
from django.forms import forms
from django.template.defaultfilters import filesizeformat
from django.utils.translation import ugettext_lazy as _

class ContentTypeRestrictedFileField(FileField):
"""
Same as forms.FileField, but you can specify a content_type and
max_upload_size.
"""
def __init__(self, *args, **kwargs):
self.content_types = kwargs.pop("content_types")
self.max_upload_size = kwargs.pop("max_upload_size")

super(ContentTypeRestrictedFileField, self).__init__(*args,
**kwargs)

def clean(self, *args, **kwargs):
data = super(ContentTypeRestrictedFileField,
self).clean(*args, **kwargs)

file = data.file
content_type = file.content_type

if content_type in self.content_types:
if file._size > self.max_upload_size:
raise forms.ValidationError(_('Please keep filesize
under %s. Current filesize %s') %
(filesizeformat(self.max_upload_size), filesizeformat(file._size)))
else:
raise forms.ValidationError(_('The only filetype allowed
is PDF.'))

return data


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django Accounts - User account 'component'

[Benedict Verheyen]

On 23/09/2010 18:04, Guiga wrote:
> Hi guys,
> 
> I'd like to know if django have a "component" (or some like this) to
> create, edit and login user's accounts. I mean, some like a system
> user accounts to work with django.
> 
> Thanks.
> 

Hi,

as mentioned you can use the authentication system of Django.
Using django-registration (http://code.google.com/p/django-registration/) gives
you a whole system with signing up and activation and so on.
If you install that, you only need to make the appropriate templates and you're 
off.

Regards,
Benedict

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Relationship between multiple sites & projects, apps

[Benedict Verheyen]

Hi Brian,


2 valid points that i hadn't even considered.
I'm also leaning towards using 1 project for 1 site.

I'm interested however why you don't use several apps then in a site?
1 app might be the authentication, another a blog and so on.
Wouldn't it be more useful if you try to seperate the logic of one site
into several apps?
Then you might even be able to reuse some of it.

I've checked the documentation on Sites 
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
One thing i don't understand is that they make use of the SITE_ID in the 
settings as in this code:
==
from django.conf import settings

def article_detail(request, article_id):
try:
a = Article.objects.get(id=article_id, 
sites__id__exact=settings.SITE_ID)
except Article.DoesNotExist:
raise Http404
==

However, if you have 1 project, the SITE_ID will always be the same. That 
doesn't make sense
unless you have 1 project per site. I would really like to know how this is 
supposed to
work with 1 project.

On the standard layout of projects, you have the template and media directories 
at the first
level:
-- project
 application
 media (or static)
 templates

If you want your apps to be portable, then it would make more sense to put a 
media/static
directory and templates directory inside the application otherwise the app is 
to tied in with
the project.

It think there should be a preferred project/application layout specifying use 
cases so people
know in advance how to layout there projects & apps before they start.
For instance, if you won't be reusing your application, then there is no need 
to put the
templates and media in the application directory.

This would really help people.
Maybe something like this:

* 1 site, 1 or more non portable apps,
-- project
 application 1
 application 2
 media (or static)
 templates
-- application 1
-- application 2

* 1 or more related sites
-- project
 site 1
 site 2
 media (or static)
 templates
-- site 1
-- site 2

And so on. You can't specify all cases but a few common ones would make it far 
more
clear on how the Django concept should be used.

Greetings,
Benedict


> We've got 4 domain names which all comprise a single website.  We went with 
> the second option where each domain is its own django project
> with a single app in it.  We liked this option for two reasons.
> 
> 1)  We wanted apache virtual hosts to be handling the decision about which 
> entry point to use instead of directing all traffic to a single
> django project and letting the python (which we believe to be less 
> performance optimized than the apache method).  This was a performance
> decision.
> 
> 2)  We also wanted the ability to flexibly grow the infrastructure backing 
> different domains.  Basically it is easier for us to handle
> traffic to different areas of our site since we can always break out more 
> servers to handle different virtual hosts.  If it was all one
> django project I don't think you could allocate infrastructure this 
> granularly.
> 
> my 2 cents, but I'd love to hear what others think about these things
> 
> Brian
> 
> On Thu, Sep 23, 2010 at 5:00 AM, Benedict Verheyen 
> > wrote:
> 
> Hi,
> 
> 
> it's not exactly clear to me how the sites, projects and apps need to be 
> structured.
> 
> For instance, if you have 2 sites both with a domain name, how would you 
> structure
> this in Django?
> The Django project could be called "mysites" or whatever name.
> In the admin site, you would then have 2 sites. So far so good.
> But how would you represent the sites?
> Do you make an application per site as each site could do something 
> specific.
> Then you end up with this structure.
> Is this how it is meant to be?
> -- mysites (project)
> -- site 1 (app)
> -- site 2 (app)
> 
> The only downside might be if both sites have loads of users, they are 
> all displayed in the same list
> in the admin interface.
> Also, if you couple this with django-registration, it might not be that 
> simple to let a user register
> for site 1 as well as site 2. I have no practical experience with 
> django-registration but it seems
> like something i would use in the future.
> 
> Or is it better to split the sites over 2 projects, so you have a project 
> per site?
> -- site 1 (project)
> -- site 1 (app)
> -- site 2 (project)
> -- site 2 (app)
> 
> 
> Thanks for any insights,
> Regards,
> Benedict
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com 
> .
> To unsubscribe from this group, send email to 
> 

Re: Why Django Apps Suck

[Venkatraman S]

On Fri, Sep 24, 2010 at 12:09 PM, Klaas van Schelven <
klaasvanschel...@gmail.com> wrote:

>
> http://djangocon.eu/ is going to be in the spring of 2011. Let's see
> how many of the "best of the bunch" are going to make it to
> Amsterdam :-)
>
>
Wanted to attend this year. Missed.
How was it?

-V-
http://twitter.com/venkasub

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: subclassing UserCreationForm

[Axel]

All right, I found some sources.
http://stackoverflow.com/questions/1061279/for-the-django-admin-how-do-i-add-a-field-to-the-user-model-and-have-it-editable
http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-in-the-Django-Admin-Site/

By strictly holding to these, and by experimenting, I now get this:

_'StudentAdmin.fieldsets[0][1]['fields']' refers to field 'course'
that is missing from the form._

Adding a class StudentCreateForm(UserCreationForm) does not help,
either:

class StudentCreateForm(UserCreationForm):
course = forms.CharField()
class StudentAdmin(UserAdmin):
# ...
add_form = StudentCreateForm

Please, I am going crazy. There's probably a super-simple solution,
but I don't seem to find it. And I feel horribly stupid right now. And
it's several hours now, cause I can't let go - and I'm horribly tired.


Thanks,
Axel.

On Sep 23, 11:29 pm, Axel Bock  wrote:
> Hello all,
>
> I must admit - I am going crazy. With something I thought should be
> incredibly simple, but maybe I am just too f**king stupid.
>
> All right, here comes my problem. I have subclassed "User" as "Student" and
> added some required fields, one of them being "Course":
>
> # models.py
> class Student(User):
>     course = models.ForeignKey('Course')
>
> So far, so good. Now I couldn't create a Student with an initial password -
> the password field was plaintext, and the "change password" form wouldn't
> work. I dug through the code and some postings, and discovered that if I
> used a custom admin class it would just work fine, with the advantage that I
> could exclude some fields I don't need in the admin view of the Students.
> That basically looks like this:
>
> # admin.py
> class StudentAdmin(UserAdmin):
>     fieldsets = ( #...
>     )
> admin.site.register(Student, StudentAdmin)
> *
> Then* I got another annoyance. If I tried to create a Student now, I was
> confronted with the "usual" User creation screen. (Huh? ... ok, dig a bit in
> Django internals, one can only learn ...). Basically I wouldnt mind, but the
> Student creation does not work any more - the simple add user screen will of
> course set no "course" value in the Student model, So I dug further. I
> discovered that the user creation was handled by a form called
> UserCreationForm, and this form explicitly excluded alot of stuff.
>
> But now the magic went crazy. If I look at the UserCreationForm class, I
> see:
>
>     class Meta:
>         model = User
>         fields = ("username",)
>
> WTF? The only field which *should* be seen is "username", according to the
> docs (according 
> tohttp://docs.djangoproject.com/en/1.2/topics/forms/modelforms/). But there is
> password AND username. Aha. I am pretty confused now. But not without
> optimism. I tried subclassing the form now, which looked something like
> this:
>
> *class StudentCreationForm(UserCreationForm):
>     class Meta():
>         model = Student
>         fields = ('course')
> *
> class StudentAdmin(UserAdmin):
>     #fields = ('first_name', 'family_name', 'password', 'course', 'base')
>     fieldsets = ( # ... cut out
>     *add_form = StudentCreationForm*
>
> And the result? No luck. WhatEVER I do (replacing UserCreationForm with
> subclass of ModelForm, overriding get_form(), and some other things), the
> form will only and inevitably show "username" and "password".
>
> And it's about two hours now.
>
> Help.
>
> Please.
>
> Thanks!
> Axel.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Why Django Apps Suck

[Klaas van Schelven]

>
> Sure. However, Djangocon 2010 finished a week ago, so you're going to
> have to wait until next year before we have the next serious
> opportunity to do this.
>

http://djangocon.eu/ is going to be in the spring of 2011. Let's see
how many of the "best of the bunch" are going to make it to
Amsterdam :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.