Hi Russ, Thanks for your reply. There was no particulary strong reason why I addressed the question to you, I guess the only reason I can think of is that I know of your existence :)
On the question of assigning permissions to the model: as far as I understand, the described in [1] syntax is only for saying that object of type 'USCitizen' _may_ have those permissions associated with it. But the actual association (grant of a certain permission) must happen separately, via admin or in user's code. The code snippet I listed was doing the latter - associating a certain permission with an instance of the object.Please correct me if I'm wrong here. Depending on the application logic certain instances may or may not get certain permissions assigned to them, so assignment process becomes rather routine task, and that's why I suggested it could be implemented as a helper function. On the second point - it just seemed not elegant enough and a bit ambiguous, that's why I raised that. The whole permissions thing just didn't feel quite right in comparison to the elegant, light and structured model/view/template part. Thanks for your time anyway :) On Jan 6, 10:05 pm, "Russell Keith-Magee" <freakboy3...@gmail.com> wrote: > On Tue, Jan 6, 2009 at 4:26 AM, Artem Skvira <artem.skv...@gmail.com> wrote: > > On Jan 2, 6:26 pm, Artem Skvira <artem.skv...@gmail.com> wrote: > >> Would anyone be able to comment on the issues raised? > > Can I get Russell's comment on that? > > I'm not entirely sure why I've been flagged personally on this. In > addition, it's hard to comment, because it isn't entirely clear why > you think "the issues raised" are such a big problem. As best as I can > make out, you have two complaints: > > 1) Defining permissions is too hard > 2) Permissions should formally require the > > For the first point, the method you describe for defining new > permissions is one approach. Another approach using model metadata is > also described in the documentation [1]. Between the two, I'm not sure > why you see the need for helper, especially since permission creation > is a once-off activity. > > As for the second point; the model name isn't required in the > permission name, but it isn't prohibited either. This is a matter of > convention - including the model name is often a good idea (e.g., the > default 'add_X', 'change_X' permissions), but it's easy to think of > examples where requiring the model name would be cumbersome (e.g, a > 'can_vote' permission on a Citizen model). > > You are correct that this does open a potential window for an > ambiguity where you have two models in the same app with a permission > of the same name. I'm not certain about the design decision here (the > auth module was written before I joined Django as a core contributor), > but I can see how this could be used to allow shared permissions e.g., > anyone given permission to open the house gets automatic permission to > open the car, and vice versa. > > Even if this wasn't the design intent, I can't say the problem > particularly concerns me. Having a free-form permissions string guided > by convention is easy to use, and it has been in use for over 3 years > without (to the best of my knowledge) any significant reports of > difficulty stemming from the problem you describe. In addition, there > is plenty of legacy code using the existing permissions framework that > would be onerous to change, and besides - a simple workaround exists: > "don't use ambiguous permission names", which is hardly an onerous > suggestion. > > [1]http://docs.djangoproject.com/en/dev/topics/auth/#id1 > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
