Swapped User logic incorrect in Django 1.7

[kevingill1966]

in permissionmodels.py there is a piece of logic to determine if the user is swapped. There are two paths through the code, one for Django 1.6 and one for other versions of Django. The wrong branch is taken in Django 1.7. The logic should, in my opinion be,

if DJANGO_1_6 or DJANGO_1_7:

and DJANGO_1_7 should be imported at the top.

[yakky]

DJANGO_1_6 means 1.6 and lower.
For Django 1.7+ we need to take the other path as we cannot pull application strings for INSTALLED_APPS due to the new application registry structure
Has this triggered any issue in your setup?

[infinite-tape]

This seems to be affecting me. When running manage.py validate and various other management commands, I get the below traceback. This only happens on Django 1.7.

I downgraded to 1.6.6 and everything is peachy. I tested with fresh databases and identical settings between both versions. Haven't had time to debug further, but thought this could be helpful for others (since I didn't see any other tickets on it).

$ python manage.py validate

/home/flyweb/www/venv/lib/python3.4/site-packages/cms/publisher/manager.py:5: RemovedInDjango18Warning: PublisherManager.get_query_set method should be renamed get_queryset.
class PublisherManager(models.Manager):

/home/flyweb/www/venv/lib/python3.4/site-packages/cms/models/managers.py:15: RemovedInDjango18Warning: PageManager.get_query_set method should be renamed get_queryset.
class PageManager(PublisherManager):

Traceback (most recent call last):
File "manage.py", line 11, in
execute_from_command_line(sys.argv)
File "/home/flyweb/www/venv/lib/python3.4/site-packages/django/core/management/init.py", line 385, in execute_from_command_line
utility.execute()
File "/home/flyweb/www/venv/lib/python3.4/site-packages/django/core/management/init.py", line 354, in execute
django.setup()
File "/home/flyweb/www/venv/lib/python3.4/site-packages/django/init.py", line 21, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/flyweb/www/venv/lib/python3.4/site-packages/django/apps/registry.py", line 108, in populate
app_config.import_models(all_models)
File "/home/flyweb/www/venv/lib/python3.4/site-packages/django/apps/config.py", line 197, in import_models
self.models_module = import_module(models_module_name)
File "/home/flyweb/www/venv/lib/python3.4/importlib/init.py", line 109, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 2231, in _gcd_import
File "", line 2214, in _find_and_load
File "", line 2203, in _find_and_load_unlocked
File "", line 1200, in _load_unlocked
File "", line 1129, in _exec
File "", line 1448, in exec_module
File "", line 321, in _call_with_frames_removed
File "/home/flyweb/www/venv/lib/python3.4/site-packages/cms/models/init.py", line 4, in
from .permissionmodels import * # nopyflakes
File "/home/flyweb/www/venv/lib/python3.4/site-packages/cms/models/permissionmodels.py", line 41, in
"in settings.INSTALLED_APPS" % (user_model_label, user_app_name)
django.core.exceptions.ImproperlyConfigured: You have defined a custom user model flyauth.FlyAuthUser, but the app flyauth is not in settings.INSTALLED_APPS

[jsma]

I got this error as well. Have you tried moving your flyauth app above the cms apps in INSTALLED_APPS? I also had to comment out the cms apps to create the initial migration for my custom user app otherwise I'd get a different error:

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'cms.PageUser'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
 in an app with no migrations; see https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for more

Once the initial migration was created, I could then re-enable the default cms apps in INSTALLED_APPS and then ./manage.py migrate worked without issue.

[yakky]

@jesselegg, @kevingill1966 As stated in http://django-cms.readthedocs.org/en/latest/basic_reference/configuration.html#custom-user-requirements the custom user model application must be declared before cms in the installed apps.
@jsma does your user app depends on CMS models in any way?
Are you using latest django CMS develop?

[jsma]

@yakky My custom user does not depend on cms models in any way. If I have the basic cms apps listed in INSTALLED_APPS, I can't create the initial migration for my custom User model (even though it is listed before 'cms'). When I do ./manage.py makemigrations accounts I get the following error (this is on an new, empty database, no other migrations have been applied yet.):

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'cms.PageUser'>]

If I temporarily comment out the cms apps from INSTALLED_SETTINGS, I can create the initial migration, then uncomment the cms apps and run the full ./manage.py migrate without any problems. I haven't had time to fully debug but I'm guessing it has something to do with the workaround code in permissionmodels.py, which is what led me to this ticket.

I am running the latest from the develop branch (no local modifications) and am running Django 1.7 (the tagged release).

[yakky]

Not really: that error is generated by the migrations code when it cannot find a migrated model related to the errored model.
Could you paste your custom user model? fields are enough: in my experience, the above error is mostly related to the unability for the migration code to correctly resolve all the model dependencies.

[jsma]

It's a fairly standard custom user which uses email instead of username, here's a gist. I totally get why there would be an error if I tried to apply the CMS migrations without migrating the custom user first since there is an obvious dependency there, it's just unclear why I can't ./manage.py makemigrations account to create the initial migration.

[yakky]

Thanks for the gist.
I'll try to replicate

[jsma]

I've created a minimal app to reproduce https://github.com/jsma/cmstest

[yakky]

Awesome!

[yakky]

The provided example has an empty migrations directory which prevents migrations to be created for the accounts application.
By removing the directory I've been able to create the migrations and run the migrate command.
Tested against latest develop and released Django 1.7

[jsma]

It works as you say. Strange to me that the presence of the folder but no actual migration files would make it break. But I guess that's an issue to take upstream. Thanks for looking into it.

[jsma]

Actually, if I comment out all CMS related stuff from settings, I can create the initial migration just fine, so this does not appear to be an upstream issue. In fact, django-admin startapp accounts created the empty migrations folder to begin with. If I have time I'll try to trace down what is triggering this error but dealing with lots of other fun bugs at the moment.

[yakky]

In the end it all depends on this behavior: https://github.com/django/django/blob/stable/1.7.x/django/db/migrations/loader.py#L71
To check if an application has migrations or not, Django tries to import the module, which will succeed with an empty migration directory with __init__.py in it; this will mark the application with "has migration" and thus the migration state machine expect it to have some migration information and the it goes on examining other applications (like the CMS) which in turn depends on it to work.
Due to the way the new migration system treats dependencies this results in a deadlock and it skips.
By removing cms no application depends on the custom user module and then the state machine can go over examining actual models and thus it generates the missing migrations for the acounts application.
Same goes if no migration module exists thus triggering a different code path that can resolve the custom user dependency.
CMS cannot do much in this respect, so I'm closing this.
I'll try to push this issue on Django, though, and I'll update this issue with further information

[yakky]

Opened on Django tracker: https://code.djangoproject.com/ticket/23599

[yakky]

As stated at https://code.djangoproject.com/ticket/23599#comment:6 and at https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model creating migration for custom user models should be done in isolation before dependent applications step in to avoid dependency issues.
This has nothing to do with the CMS in the end

[SalahAdDin]

Well, until now, i have this issue and i can't continue with my develop.
Maybe if i create an app this will be solved?

Good, first i migrated all apps without cms, them, cms, and works.

[linix-mod]

Moved mentioned migration-models

"PageUserGroup" and "PagePermission"

from original origin in file

cms/migrations/0002_auto_20140816_1918.py

to initial file:

cms/migrations/0001_initial.py

and did a sqlmigrate on both files (sqlmigrate cms 0001_initial & sqlmigrate cms 0002_auto_20140816_1918).

Works like a charm without any more modifications!

At https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model its described that:

"AUTH_USER_MODEL is created in the first migration of its app (usually called 0001_initial); otherwise, you will have dependency issues"

"PageUserGroup" and "PagePermission" access "AUTH_USER_MODEL" thats the reason why they need to be moved to 0001_initial.py file.