Re: Can't sync DB
Since you have already created the table using syncdb, you need to instruct
South to fake the initial migration. Try the command ./manage.py migrate
auth --fake and see if that works. You only need to run this once and then
all future migrations don't need the --fake flag.
Cheers,
Nick
On Tue, Jan 8, 2013 at 9:21 AM, galgal wrote:
> I try to use new User model. I made my custom model, attached it
> by: AUTH_USER_MODEL = 'account.Account'
> Model:
>
> class Account(AbstractBaseUser, PermissionsMixin):
> email = models.EmailField(
> verbose_name=_('email address'),
> max_length=255,
> unique=True,
> db_index=True,
> )
> username = models.CharField(
> _('username'),
> max_length=75,
> unique=True,
> help_text=_('Required. 75 characters or fewer. Letters, numbers
> and @/./+/-/_ characters'),
> validators=[
> validators.RegexValidator(re.compile('^[\w.@+-]+$'), _('Enter
> a valid username.'),
> 'invalid')
> ])
> is_staff = models.BooleanField(
> _('staff status'), default=False,
> help_text=_('Designates whether the user can log into this admin
> site.'))
> is_active = models.BooleanField(default=True)
> is_admin = models.BooleanField(default=False)
> date_joined = models.DateTimeField(_('date joined'),
> default=timezone.now)
>
> objects = AccountManager()
>
> USERNAME_FIELD = 'email'
> REQUIRED_FIELDS = ['username']
>
> def get_full_name(self):
> # The user is identified by their email address
> return self.email
>
> def get_short_name(self):
> # The user is identified by their email address
> return self.email
>
> def __unicode__(self):
> return self.email
>
>
> I can't sync my DB, when south is added. When I turn South off, run
> syncdb, all is ok. Then when I turn South on and try to make migrate, I
> get:
>
> ./manage.py migrate
>> Running migrations for auth:
>> - Migrating forwards to 0001_initial.
>> > auth:0001_initial
>> FATAL ERROR - The following SQL query failed: CREATE TABLE
>> `auth_permission` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `name`
>> varchar(50) NOT NULL, `content_type_id` integer NOT NULL, `codename`
>> varchar(100) NOT NULL);
>> The error was: (1050, "Table 'auth_permission' already exists")
>> ! Error found during real run of migration! Aborting.
>> ! Since you have a database that does not support running
>> ! schema-altering statements in transactions, we have had
>> ! to leave it in an interim state between migrations.
>> ! You *might* be able to recover with: - no dry run output for
>> delete_unique_column() due to dynamic DDL, sorry
>>= DROP TABLE `auth_permission` CASCADE; []
>>= DROP TABLE `auth_group` CASCADE; []
>>= DROP TABLE `auth_group_permissions` CASCADE; []
>>= DROP TABLE `auth_user` CASCADE; []
>>= DROP TABLE `auth_user_groups` CASCADE; []
>>= DROP TABLE `auth_user_user_permissions` CASCADE; []
>> ! The South developers regret this has happened, and would
>> ! like to gently persuade you to consider a slightly
>> ! easier-to-deal-with DBMS (one that supports DDL transactions)
>> ! NOTE: The error which caused the migration to fail is further up.
>> Error in migration: auth:0001_initial
>> DatabaseError: (1050, "Table 'auth_permission' already exists")
>>
>> Any ideas what do I do wrong?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/WR_xxyrJGusJ.
> To post to this group, send email to django-users@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-users@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: Named URLs for Flatpages?
On Wed, Oct 22, 2008 at 6:14 AM, erikcw wrote:
>
> Hi all,
>
> I'm working on a project that uses flatpages pretty heavily. I was
> wondering if there was a way to use named urls with flatpages so that
> I can use reverse() in my other views and {% url flat_privacy_policy
> %} in my templates.
>
> I haven't been able to find anything helpful in the docs so far. Any
> ideas?
It's definitely possible to do. It depends how you want to approach it
but I find that removing the
django.contrib.flatpages.middleware.FlatpageFallbackMiddleware from
the MIDDLEWARE_CLASSES and manually specifying the flatpages you want
via urlconfs easier to handle (since you can use {% url foo %} in
templates).
In your urlconf you want to have something like:
url(r'^about/$',
'django.contrib.flatpages.views.flatpage',
{ 'url': '/about/' },
name='about'),
and then in your templates you can say {% url about %} and it should
work as advertised. Hope this helps!
Cheers,
Nick
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Multiple selects for ForeignKey in admin
Just wondering how easy it would be to implement something like this: class Foo(models.Model): name = models.CharField(max_length=200) bar = models.ForeignKey(Bar) class Bar(models.Model): name = models.CharField(max_length=200) category = models.CharField(max_length=200) def __unicode__(self): return self.name Then, in the admin have multiple select boxes to choose a Bar while creating a new Foo object: one to chose the category of the Bar object and one to chose the Bar object itself. When you select a category, the select to chose the Bar filters based on the category chosen. Would be useful for having lots of Bar objects to chose from and not having to use raw_id_fields Any ideas? Cheers, Nick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Displaying ManyToMany relations in Admin
Hi all, I currently have a site setup to manage students, teachers and classrooms. In the classroom admin interface I have a horizontal filter to select the students and teachers in a classroom. The only problem is, I have roughly 1400 students and 400 teachers to select from. From what I can see, the admin is not showing all the teachers and students when I try to use the admin interface to edit a classroom. I get a list of students and teachers that isn't complete. Is there some kind of limit the admin imposes on the number of items it will show in a or the horizontal filter list? If so, can I change it? Also, is there any better way to do this? I'm not too fussed about it since generally I don't have to edit the information, but it would be nice to be able to. Thanks in advance, Nick. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: testing login problem
On Thu, Jul 3, 2008 at 2:18 PM, laspal <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Thanks for the help but still I am not able to login in my test
> client..
>
> here is the code:
>
> from django.test import TestCase
> from django.test.client import Client
>
> class IndustryTest(TestCase):
>fixtures = ['/fixtures/initial_data.xml']
>
>
>def setUp(self):
>self.client = Client()
>response =self.client.post('/ibms/login/',
> {'username':'laspal', 'passwords':'abcd'})
>print response
did you spell password wrong? passwords != password
Cheers,
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: auth context processor setup
On Sun, Jun 22, 2008 at 10:20 PM, mcordes <[EMAIL PROTECTED]> wrote:
>
> I seem to already have the auth middleware enabled too. From what I'm
> seeing, generic views _do_ have the user object available in their
> templates. It's just my custom views that don't automatically have
> this. It's easy enough for me to pass in the request.user object from
> each of my templates, but I really thought I wouldn't need to do this.
render_to_response doesn't use a RequestContext whereas the generic views do.
To enable this in render_to_response try:
from django.template import RequestContext
...
render_to_response('some/template.html',
context_instance=RequestContext(request))
Hope this helps,
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
