GitHub PushEvent at 2014-08-27 17:24:24
Repository: django-oscar
Actor: maikhoepfel
Payload: {"shas":[["c0dd0df221ccddf3919b241b89a3aee3396228ba","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Bump version to 0.8-beta-1","Maik Hoepfel",false],["64e21b1eb88e888ad59073c44997b6fc5101da25","dec8f46e5aaadf92533ab7852e92d1b2d980fab9@lukkien.com","Add robots meta tag to dashboard to disallow indexing","Michael van Tellingen",false],["bb5dfea47f7f2be4b7dac81d7096f1658c771610","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Add hook to optimise order line query count\n\nIt was requested to factor the get() call out into a separate\nmethod because it makes it hard to optimise the method call.\n\nThis is one of the changes related to #1467.\n\nCloses #1470.","Maik Hoepfel",false],["4b239ac3575aa8f66db42416664616fb108b48a1","23b9e7a22968f8e4a53f13cb5937d56843a368de@monokro.me","Avoid `select_related` in property.\n\nAs further described in https://github.com/tangentlabs/django-oscar/issues/1467\n\nCloses #1469.","Brandon R. Stoner",false],["48654d9aa29a4e274ca34a824de3e5002f4369a6","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Correctly handle invalid parent products\n\nThe ProductCreateUpdateView had untested logic to handle invalid parent\nproducts. Unfortunately, it didn't work; the check returned a redirect,\nwhich later was tried to access like a product.\n\nThe only place to issue a redirect for invalid products is the dispatch\nmethod, so an altered check has been moved there.\n\nThis time with tests...","Maik Hoepfel",false],["f8a7c1b937f67811e852b20a79acc1b83d0e9e37","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Parent/child products aren't supported in permission-based dashboard\n\nCurrently, a product's stockrecords are used to decide if a user is\nallowed to edit a product or not. That doesn't work for parent products,\nbecause they don't have stockrecords. So it's not possible to decide\nwhether a user is allowed to edit a parent product (and e.g. create\nchildren) for it.\n\nAs far as I'm aware, this is not a regression of the\npermission-dashboard; I don't think it ever worked. It just hasn't been\nspotted because nobody needed it.\n\nThis commit also adds some tests to ensure this is enforced.","Maik Hoepfel",false],["7ca0551a93612d673fc0d18b5460364f2f23f1be","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Normalise verbose_names on catalogue models\n\nI'm just about to re-do migrations. As changes like this require a\nnew-style migration, I thought it's sensible to do this beforehand.\n\nI'll push those changes to Transifex.","Maik Hoepfel",false],["f171967bcf503c8e9885a2914c85e76e5e9870c9","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Redo new-style migrations\n\nWhen adding a migration on master, I discovered that the new-style\nmigrations were strongly out of sync; Django wanted to create new\nmigrations for almost every app. That was surprising given that no model\nchanges were made since building that set of migrations.\n\nThe issue is that they were built with Django 1.7 RC2, and we've since\nswitchted to RC3. If I'd have to guess, I'd say the following issue is\nresponsible for it:\nhttps://github.com/django/django/commit/2da20379c0dd0171eb11c188909096f708dd6095\n\nAs beta 1 is only a day old and it doesn't cause major headaches, it was\ndecided that it's easiest to release a new set of migrations. And pray\nto the gods of Python that we won't have a similar situation again\nbefore the Django migrations framework stabilises.","Maik Hoepfel",false],["80c54a924b75d922ab2bd309aa63bbb9d0681de4","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Bump version to 0.8-beta-2","Maik Hoepfel",false],["3ef710095fbef137f5bc732283f194fe2c5876ba","6b0d31c0d563223024da45691584643ac78c96e8@maikhoepfel.de","Merge branch 'releases/0.8'","Maik Hoepfel",true]],"size":10,"ref":"refs/heads/master","head":"3ef710095fbef137f5bc732283f194fe2c5876ba"}