Joseph Kocherhans wrote: > So I should probably get started on the generic-auth and > per-object-permissions (hereafter pop) integration soon. I've had > problems trying to merge changes from the trunk into the generic-auth > branch, so I'd just assume call that branch dead. The actual > generic-auth code is just a patch to the trunk [1] The easiest way > integrate the two would probably be for me to patch the > per-object-permissions branch. > > I suppose the other option, for the anal-rentively inclined, (which > very often includes me ;) would be to start a new-auth branch, merge > the pop changes to it (or even copy the existing pop branch, yeah, > ick.), and apply the generic-auth patch to it. This sounds like a > total pain in the ass to me. >
Probably the better option, we can merge the latest trunk into POP branch then copy it over to another branch and work on that to merge the two together. Might be easier to do testing, especially since I'm still adding features to the POP branch (mostly to do w/ the admin interface) but I want to refactor a lot of my code in the user model for checking permissions. > /me grumbles something about his love/hate relationship with svn, > specifically merge > > I am presupposing that gen-auth and pop should be merged together > before they get merged to the trunk. If you disagree, let me know. Agreed. > > So there's the logistics. Here are the rest of the plans for getting > this into the trunk. > > After the two codebases (gen-auth/pop) are integrated, I plan to > refactor out a couple of functions from the > django.contrib.models.User.has_perm method in the pop branch. After > that, the has_perm method should die. (Some other User methods may > suffer a similar fate) I'll put in some backwards compatibility code > (that *doesn't* support pop), but I think it should be gone by 1.0. I > also want to take a look at how the Meta attributes work for > activating this stuff. I'd like to make it a little more generic, but > I'll bring it up again after I've taken a look at the code. > Sounds good to me. There are a few methods, as I said, I want to refactor in the user model and probably rewrite or remove. The current user has_perm method is fairly backwards compatible, I'm making sure to always make the object parameter for any perm checking to be optional. Also saves on some time if you know you don't want any POP checking for an object. Once I've redone some of my permission code, we can figure out what goes where, etc. Let me know how you think we should rewrite the meta attributes. I'm also considering changing the admin attributes and POPs. After you've had a look at the code maybe we can have another IRC conversation about what should be changed, etc. I'm finishing off some other work this week and starting school right after that, but hoping to get some time this week or next week to work on the POP branch, just depends on how efficient I am. ;) Sorry if the above doesn't make sense, had a long week and last night was a bit hectic...suffering for it today. Cheers, Chris --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
