Validation error in Slovak: question about URL language code sniffing
Hi all, I ran my project's tests today using the new beta and was surprised when one innocuous-looking test failed because the expected English validation error string didn't match the returned Slovak equivalent. It turns out that this view is accessible with URL whose path begins with "/sl/". Ticket #11585 [0] and its associated commit [1] (which are fairly old) changed django.utils.translation.get_language_from_request by adding the get_language_from_path hook. Since my site uses the LocaleMiddleware, this change activates the Slovak language for the request. Validation errors and other available translated strings end up being in a language I don't really want to use. What are people's thoughts on this? I know the URL is a poor one and luckily I'm not really affected because humans don't directly access them, but it seems like a backwards incompatible change that isn't well documented. It would be great to be able to pass a keyword argument to get_language_from_request telling it to not call get_language_from_path. That way I could override LocalMiddleware.process_request and fall back to the old language detection mechanism. Perhaps there is a simple solution I'm missing. Best, Ryan Kaskel [0] <https://code.djangoproject.com/ticket/11585> [1] <https://code.djangoproject.com/changeset/16405> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tests introduced in patch for #17327 causing errors
Hi all. I've pulled in the latest changes and it seems like ticket #17327 [1] introduces a few new tests that are raising errors when I run contrib.auth tests via my project: - auth.MultiDBChangepasswordManagementCommandTestCase.test_that_changepassword_command_with_database_option_uses_given_db - auth.MultiDBCreatesuperuserTestCase.test_createsuperuser_command_with_database_option They raise: ConnectionDoesNotExist: The connection other doesn't exist. The issue is that the tests assume there there is a database called "other," which my test settings didn't have. If I add a database "other" in my test settings, the tests pass. I've played around with override_settings but I'm not sure if that would work here. What I've tried so far doesn't. Any tips? Thanks, Ryan Kaskel [1] https://code.djangoproject.com/ticket/17327 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/WBkMgg6L_1wJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Tests introduced in patch for #17327 causing errors
In addition to the above (which I can confirm causes tests to fail in a new project), I also goofed up a patch related to a different set of auth tests. I've created #17848 (release blocker) to fix this. [1] Ticket #16366 [2] required the template context processor cache to be cleared. The code resets the cache but fails to restore it. If the auth tests run first, this causes many other test failures in my project because the newly cached template context processors only include the Django defaults. The general issue of having to reset this cache (and others) is in ticket #17787 which targets a later release. [3] I'm sorry about that error and I hope it isn't too late to include the patch. I think it will cause many headaches for other people. I know we shouldn't post about tickets we write but given 1.4 is going to be released in a few days, I think it's important to bring this up. Best, Ryan Kaskel [1] https://code.djangoproject.com/ticket/17848 [2] https://code.djangoproject.com/ticket/16366 [3] https://code.djangoproject.com/ticket/17787 On Wednesday, 7 March 2012 08:40:56 UTC, Ryan Kaskel wrote: > > Hi all. > > I've pulled in the latest changes and it seems like ticket #17327 [1] > introduces a few new tests that are raising errors when I run contrib.auth > tests via my project: > > - > auth.MultiDBChangepasswordManagementCommandTestCase.test_that_changepassword_command_with_database_option_uses_given_db > - > auth.MultiDBCreatesuperuserTestCase.test_createsuperuser_command_with_database_option > > They raise: ConnectionDoesNotExist: The connection other doesn't exist. > > The issue is that the tests assume there there is a database called > "other," which my test settings didn't have. If I add a database "other" in > my test settings, the tests pass. > > I've played around with override_settings but I'm not sure if that would > work here. What I've tried so far doesn't. > > Any tips? > > Thanks, > Ryan Kaskel > > [1] https://code.djangoproject.com/ticket/17327 > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Kf3GUTSNUvYJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Migrating to 1.4
My project has about half as many tests but boy did the run slowly on my Django 1.4 upgrade branch. On Monday, 16 April 2012 15:33:31 UTC+1, Dan Fairs wrote: > > > The first big regression for us was that our test suite took 20% longer to > run. I traced this down to the new default password hasher. This is clearly > by design - and we'll just use the PASSWORD_HASHERS setting to use a faster > (and much less secure) hasher for test runs. > > ... and now I know why! After changing the setting, my tests run just a tad slower on 1.4. You've cleared the path for our upgrade which will happen in the next few weeks or so. Thanks! Best, Ryan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/z6LVJ0lBakoJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Custom user models in 1.5, not flexible/dry enough?
I implemented a custom User model in my new project so I can sympathize with Ionel a bit. I wanted to change a few fields on User and have an admin with the same functionality as the 1.4 auth.User. This necessitated some copying and pasting to define the User's relations to auth.Group and auth.Permission (as well as adding is_staff, is_superuser, and a few help methods related to perms such as get_group_permissions). I also had to "re-implement" (i.e. copy, paste, and change a few fields) auth.User's ModelAdmin to get the admin interface looking similar (this included some related forms). Still though, the benefit of Russ's additions far outweigh some of these minor conveniences, which, to be fair, he mentioned in his draft branch release notes (June 4 - https://groups.google.com/d/msg/django-developers/YwEZUIMuIkE/g9-tAZ15RxMJ): """ * The auth forms are bound to User, and don't adapt to MyUser. * You need to roll your own admin registration for MyUser * The admin template still asks for "username", even if the email address is the identity field. * A full audit of admin to formally establish the "admin User" interface. * Possibly factor out the fields on User that relate to Permissions, so it's easy to add the full set of admin permission bits to a custom User model. I know Alex Ogier's branch has done some work on these last two points, so that's probably where I'll start (or if someone wants to beat me to it…) """ Looks like someone needs to take the helm and implement some mixins. Maybe start it as a reusable app and grandmother it into Django? Or use Alex's work ( https://github.com/ogier/django/blob/auth-mixins/django/contrib/auth/mixins.py#L120 )? -- Ryan On Tuesday, 6 November 2012 02:19:47 UTC, donarb wrote: > > I think it's basically a bit of an ambiguous reading of that section of > the documentation: > > *"If you want your custom User model to also work with Admin, your User > model must define some additional attributes and methods. These methods > allow the admin to control access of the User to admin content:"* > > It's saying that the admin app uses those attributes and methods to > determine access. What this means is that they are already defined in > AbstractUser, but you can override them if your user has a different > definition of is_staff or is_active or the permissions. If you look at the > source for AbstractUser, it uses the built-in groups and permissions, just > as the old User did. > > Don > > On Monday, November 5, 2012 5:22:51 PM UTC-8, Ionel Cristian Mărieș wrote: >> >> I think you are referring to >> >> https://docs.djangoproject.com/en/dev/topics/auth/#custom-users-and-django-contrib-admin >> >> But I don't want to re-implement those if they already exist on >> AbstractUser. I want exactly the same permission granularity as with >> non-custom User so I have to pull in the groups and permission >> relations. >> >> Maybe there should be a mixin with those ? >> >> And I'm not saying the admin doesn't work with AbstractBaseUser, I'm >> just implying that's too much code needed to get the equivalent admin >> features on a custom user. Maybe my usecase is not that common and I >> need to accept the fact, but then again, maybe not. I'm just putting >> it on the table. >> >> Thanks, >> -- ionel >> >> On Nov 6, 3:04 am, Russell Keith-Magee >> wrote: >> > On Tue, Nov 6, 2012 at 7:59 AM, ionel wrote: >> > > Hello, >> > >> > > I'm trying to make a custom user model so I can login and register >> > > with the email (instead of username). This means the email must >> become >> > > unique and I don't need the username fields. I don't want to fill it >> > > with random data, unique ids, hashes or whatnot. >> > >> > > Also, I need to have the admin working. Because of this I'm forced to >> > > use the AbstractUser instead of AbstractBaseUser. >> > >> > Incorrect. I've got several examples -- and the documentation contains >> a >> > fully worked example -- of a User model extending AbstractBaseUser, >> using >> > email address for a login, that works with admin. I'm also using an >> example >> > of a User model that uses email address as a login on a site I'm >> currently >> > developing, and so far, it's working fine. >> > >> > > It seems to me that >> > > this abstract is concerned with two purposes: fields and methods for >> > > the admin and display fluff like username, email, first_name, >> > > last_name. This seems wrong to me, there should be two abstract >> > > models: BaseAbstractAdminUser and AbstractUser. >> > >> > > The other alternative would be allowing abstract model subclasses to >> > > override fields. Not sure about this tho, why is this disallowed in >> > > the first place? >> > >> > > What do you think ? >> > >> > It's not clear to me what exactly your proposing, and how much of that >> > stems from a mistake in your original premise. >> > >> > Like I said -- admin
Class based view version of FormPreview
I used the FormPreview class in contrib.formtools for the first time
on Monday and having worked with class based views, wished it used
FormMixin.
I refactored the FormPreview class to inherit from FormView so Django
provides a more consistent API like its sister tool FormWizard which
recently got an update.
It is 100% backwards compatible though at the expense of clarity. The
old FormPreview class based view used get_context whereas newer CBVs
use get_context_data. I discussed this and other issues in the ticket.
Overall, the mechanisms aren't any different but the code has been
moved around to act more like the other CBVs.
I created a ticket in Trac (https://code.djangoproject.com/ticket/
16174) and you can view the diff on my Github branch of the Django
mirror (https://github.com/ryankask/django/commit/
d92e4f03e81a0648bb7755fe6e43e1309b91f08a).
If this patch isn't acceptable, there a test in contrib.formtools that
should be fixed ("test_form_submit_bad_hash"). The last assertion in
the test will always be true because the request it tests 404s. I
commented on that in the ticket too.
If it is okay, I'd like to test it in the browser a little more and
write better documentation.
Best,
Ryan Kaskel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
