Hey, I pushed out a slightly modified version of your fixed up test data and modified the auth backend so it doesn't freak out about non model objects.
There is a general caveat when making fixtures that reference certain types of funky objects that django creates on the fly (and, as a result, do not have reliable primary keys). Permissions and Content Types are the primary offenders I think. Luckily, you can make references to what django calls their 'natural' key. In the case of a content type it looks like [<app_label>, <model>] eg ['maps', 'map'] These also make for slightly more readable fixtures. ObjectRoles can also be referenced similarly, so I changed those as well to be a bit more flexible wrt to the form of the initial_data fixtures. These look like [<codename>, <content_type_applabel>, <model>] eg ["map_readonly", "maps", "map"] I wasn't entirely sure how you had permissions set up, but the tests are passing for me. You may need to specify use_natural_keys=True (--natural on dumpdata command) to get things to come out like this. I'm uncertain of why this is not the default. for some additional background, see: http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys - Luke On Tue, Aug 3, 2010 at 12:26 PM, David Winslow <[email protected]> wrote: > On 08/03/2010 11:45 AM, David Winslow wrote: > > On 07/30/2010 02:52 PM, Luke Tucker wrote: > > > >> Okay, well please feel free to ask followup questions or point out > >> anything that I've missed. > >> > > Several of the automated tests for the Django app fail or error on > > master, post-security-merge. I'm investigating, but I imagine you could > > take care of these more quickly than I can. > > > > -d > > > investigation results - > * Django's auth system tests conveniently use our project's > configuration to run, so when they dummy up a model like this: > > class TestObj(object): > pass > > our auth system that actually expects the models passed into it to be, > well, models has some hiccups. I guess we can just turn this off > (although some actual unit tests for our auth module would be good.) > > * Our test fixtures don't have any permissions set, so every test that > accesses a page for any potentially restricted data gets a 401 instead > of the expected page. > > -d >
