Create user groups and assign permissions on post_syncdb signal

[ana-balica]

The following change is dependent on #9 and makes assumptions about model class names, since default permissions are created using those.

This PR will be changed accordingly and rebased against merged models. The manual testing was done using dummy models, but doesn't include those, nor the app __init__.pyor updates in base.py settings.

The user groups define 4 different levels of access. The admin level is not included, since this is the Systers Keeper and by becoming Django superuser she has access to everything via admin panel.

I have written a test for the following change, but it fails, because the order of running syncdb handlers is different in test mode. By running python manage.py syncdb the order is the following:

• Running post-sync handlers for application dashboard
• Adding permission 'dashboard | model name | Can add/change/delete model name'
• Initializing data post_syncdb

When running python manage.py test:

• Running post-sync handlers for application dashboard
• Initializing data post_syncdb
• Exception raised because create_user_groups tries to get permission objects from the database, but those were not yet inserted

Is it possible to force a specific order on syncdb execution in test mode? Or maybe there is a better way to solve the issue?

[econchick]

Hmm I could not immediately figure out how to address this. The only thing that popped out at me that could possibly work is instead of saving it as systers_portal/dashboard/management.py, save it as systers_portal/dashboard/management/__init__.py. If this doesn't help, I guess you and I will need to search further. I'd also suggest hanging out in #django on freenode if I'm not immediately available. They're quite nice.

[ana-balica]

It worked. Thanks a million!
I will update the PR and add tests.

[ana-balica]

@econchick updated

[econchick]

Is the Travis error, 'i18n_patterns' imported but unused left over from Chitra's commit? I know it shouldn't be in there, and I know in pr/9, she removes it. I assume that once pr/9 is merged, and your code/commit is updated, there would be no travis failures, correct?

[econchick]

Also - SO happy you could get this to work!! \o/

[ana-balica]

@econchick the Travis error is indeed from Chitra's commit. It has a cascading effect.
But no worries, as soon as the fixes and the models will be on master, I will rebase.

[ana-balica]

@econchick rebased