Re: When to use admin, and when not to.
2009/5/27 Andy Mikhailenko > > User behaviour can be formalized as actions + objects. Some actions > span multiple objects. > Admin is a great tool that corresponds the *structure* of data. It > allows to view and edit all your base for great justice. Err, all your > database for zero cost. Out of the box. Nice! > However, "editing an object" is only a part of functionality required > to implement possible *user actions*. You can implement some of > actions spanning multiple objects using "admin actions" (many items of > the same type) or inlines, but generally the admin is simply > unsuitable for implementing complex actions. It's your task to > (easily, btw) write views and templates for domain-specific or site- > specific actions. Many domain-specific sets of actions are available > as 3rd-party applications. Thanks for this take on the issue, Andy! I'm starting to feel consensus here... :) Sam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
User behaviour can be formalized as actions + objects. Some actions span multiple objects. Admin is a great tool that corresponds the *structure* of data. It allows to view and edit all your base for great justice. Err, all your database for zero cost. Out of the box. Nice! However, "editing an object" is only a part of functionality required to implement possible *user actions*. You can implement some of actions spanning multiple objects using "admin actions" (many items of the same type) or inlines, but generally the admin is simply unsuitable for implementing complex actions. It's your task to (easily, btw) write views and templates for domain-specific or site- specific actions. Many domain-specific sets of actions are available as 3rd-party applications. On May 26, 6:51 am, Sam Kuper wrote: > Suppose you were re-writing Facebook in Django. > > Would you handle the complex profile and privacy settings pages by: > > A) exposing the relevant admin pages to users, with careful auth to stop > users from being able to access admin pages they shouldn't be able to. > Obviously this would require much custom templating in order to achieve the > desired visual appearance (instead of the default Django admin appearance), > but it would have the advantage of not requiring new views and forms to be > written. > > B) creating forms and views as needed for the profile and privacy settings, > keeping the users out of the admin app entirely, and reserving the latter > only for Facebook staff. > > Or would you take some other approach? > > Please explain your answer, and link to documentation where relevant. > > Many thanks! > > Sam -- Cheers, Andy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
On 26 May 2009, at 15:44 , Sieker Adi Jörg wrote: > On 26.05.2009, at 14:28, Sam Kuper wrote: > Also to actually get access to the > admin views, the user needs be flagged as a superuser (I as far as I > remember). > Staff, actually, superuser is another user class (one that gets all admin rights even without manually activating them). Staff status -> can log into the admin Superuser -> can do any and everything into the admin regardless of the actual permission assignments --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
Thanks so much for the comprehensive reply! All best, Sam 2009/5/26 Sieker Adi Jörg > > On 26.05.2009, at 14:28, Sam Kuper wrote: > > > 2009/5/26 Sieker Adi Jörg > > In my humble opinion. As soon as you mention users, the admin is the > > wrong tool. > > contrib.admin is for admin's and not for users. > > > > Another take on it is: > > - Anyone that creates an account on your site, doesn't get to ses the > > admin > > - Anyone that you create an account for, might be a user to get to see > > the admin. > > > > Hi Adi, > > > > Thanks for your take on this, and for the demarcation criterion > > you've provided. This is helpful for my understanding of perceptions > > of the admin's purpose. > > > > What are the reasons why you have chosen to draw the line where you > > have? > > First and foremost the admin is designed and advertised as an internal > tool for trusted administrators (I'm consciously not using user here), > that's what it's there for and that's where focus will be put. I don't > think a lot of thought goes in the direction "but how do we handle > this is the logged in user is a normal user". > > Second what happens when you update and the admin suddenly supplies > functionality that you don't want your users to have? > Also the admin needs a specific set of js, css and images. I could > override all that, but why override all that stuff if I don't need it. > > One of the things that the admin doesn't care about at all is data > ownership. As soon as you have edit permissions for a model you can > edit all records of that model. Also to actually get access to the > admin views, the user needs be flagged as a superuser (I as far as I > remember). > > Almost all of the above points (ownership, js, css etc.) can be > accomplished by overriding certain method in your admin classes. > But doing that doesn't feel right for me. > > If I'm developing a website like, picking up your example, facebook. I > want total control over the functionality. The admin doesn't give me > that. A third party decides on the functionality and if I'm lucky I > can disable it if I don't want it. > > > > You see, given that so much great CRUD functionality comes for free > > with the admin, it strikes me as not being very DRY to manually > > create a whole other set of forms/views/etc for users unless you > > really need to provide the users with a very different look and feel > > to that offered to the site's administrators. > > > > Does anyone else share my feelings? > > There are the generic views [1] which make simple CRUD stuff a breeze > and it's all under your control. > > The admin is designed as a complete application not as a reusable app, > although it's trying to be perceived as such a lots of the times (I > hope I'm not leaning out the window too far with this statement as I'm > in no way involved in the development of the admin). > > Also DRY, is "don't repeat yourself", not "don't repeat others". :) > > > Is there a third way? E.g. subclassing the admin's functionality for > > front end users? > > Nope, not that I know of. > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
On 26.05.2009, at 14:28, Sam Kuper wrote: > 2009/5/26 Sieker Adi Jörg > In my humble opinion. As soon as you mention users, the admin is the > wrong tool. > contrib.admin is for admin's and not for users. > > Another take on it is: > - Anyone that creates an account on your site, doesn't get to ses the > admin > - Anyone that you create an account for, might be a user to get to see > the admin. > > Hi Adi, > > Thanks for your take on this, and for the demarcation criterion > you've provided. This is helpful for my understanding of perceptions > of the admin's purpose. > > What are the reasons why you have chosen to draw the line where you > have? First and foremost the admin is designed and advertised as an internal tool for trusted administrators (I'm consciously not using user here), that's what it's there for and that's where focus will be put. I don't think a lot of thought goes in the direction "but how do we handle this is the logged in user is a normal user". Second what happens when you update and the admin suddenly supplies functionality that you don't want your users to have? Also the admin needs a specific set of js, css and images. I could override all that, but why override all that stuff if I don't need it. One of the things that the admin doesn't care about at all is data ownership. As soon as you have edit permissions for a model you can edit all records of that model. Also to actually get access to the admin views, the user needs be flagged as a superuser (I as far as I remember). Almost all of the above points (ownership, js, css etc.) can be accomplished by overriding certain method in your admin classes. But doing that doesn't feel right for me. If I'm developing a website like, picking up your example, facebook. I want total control over the functionality. The admin doesn't give me that. A third party decides on the functionality and if I'm lucky I can disable it if I don't want it. > You see, given that so much great CRUD functionality comes for free > with the admin, it strikes me as not being very DRY to manually > create a whole other set of forms/views/etc for users unless you > really need to provide the users with a very different look and feel > to that offered to the site's administrators. > > Does anyone else share my feelings? There are the generic views [1] which make simple CRUD stuff a breeze and it's all under your control. The admin is designed as a complete application not as a reusable app, although it's trying to be perceived as such a lots of the times (I hope I'm not leaning out the window too far with this statement as I'm in no way involved in the development of the admin). Also DRY, is "don't repeat yourself", not "don't repeat others". :) > Is there a third way? E.g. subclassing the admin's functionality for > front end users? Nope, not that I know of. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
2009/5/26 Sieker Adi Jörg > In my humble opinion. As soon as you mention users, the admin is the > wrong tool. > contrib.admin is for admin's and not for users. > > Another take on it is: > - Anyone that creates an account on your site, doesn't get to ses the > admin > - Anyone that you create an account for, might be a user to get to see > the admin. > Hi Adi, Thanks for your take on this, and for the demarcation criterion you've provided. This is helpful for my understanding of perceptions of the admin's purpose. What are the reasons why you have chosen to draw the line where you have? You see, given that so much great CRUD functionality comes for free with the admin, it strikes me as not being very DRY to manually create a whole other set of forms/views/etc for users unless you really need to provide the users with a very different look and feel to that offered to the site's administrators. Does anyone else share my feelings? Is there a third way? E.g. subclassing the admin's functionality for front end users? Thanks, Sam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
Hi, On 26.05.2009, at 12:17, Sam Kuper wrote: > 2009/5/26 Alex Gaynor >> It's not even an authorisation issue, it's that I'd be overiding >> nearly every method to make sure the behavior was what I wanted, >> and then I'd replace all the templates since I want everything the >> user sees to be similarly themed, and at this point I've already >> rewritten a ton of code. > > OK, so is the trust issue you mentioned in your first email more to > do with being able to trust your admin users not to mind the default > admin presentation? > > Sorry if I'm asking basic questions, but I do want to gain a really > thorough understanding of when it is appropriate to give users > access to (parts of) the admin, and when it isn't. In my humble opinion. As soon as you mention users, the admin is the wrong tool. contrib.admin is for admin's and not for users. Another take on it is: - Anyone that creates an account on your site, doesn't get to ses the admin - Anyone that you create an account for, might be a user to get to see the admin. Regards adi --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
2009/5/26 Alex Gaynor > It's not even an authorisation issue, it's that I'd be overiding nearly > every method to make sure the behavior was what I wanted, and then I'd > replace all the templates since I want everything the user sees to be > similarly themed, and at this point I've already rewritten a ton of code. > OK, so is the trust issue you mentioned in your first email more to do with being able to trust your admin users not to mind the default admin presentation? Sorry if I'm asking basic questions, but I do want to gain a really thorough understanding of when it is appropriate to give users access to (parts of) the admin, and when it isn't. Many thanks, Sam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
On Mon, May 25, 2009 at 8:25 PM, Sam Kuper wrote: > 2009/5/26 Alex Gaynor > >> On Mon, May 25, 2009 at 7:51 PM, Sam Kuper >> wrote: >> >>> Suppose you were re-writing Facebook in Django. >>> >>> Would you handle the complex profile and privacy settings pages by: >>> >>> A) exposing the relevant admin pages to users, with careful auth to stop >>> users from being able to access admin pages they shouldn't be able to. >>> Obviously this would require much custom templating in order to achieve the >>> desired visual appearance (instead of the default Django admin appearance), >>> but it would have the advantage of not requiring new views and forms to be >>> written. >>> >>> B) creating forms and views as needed for the profile and privacy >>> settings, keeping the users out of the admin app entirely, and reserving the >>> latter only for Facebook staff. >>> [...] >>> >> >> B). The admin is designed really for use with fully trusted >> administrators only, the extra hooks that have been placed in for more find >> grained control notwithstanding. >> > > Thanks Alex. It sounds like your reason for choosing B is based on security > concerns - specifically that authorisation within the admin may not be as > strong as authorisation that prevents users from accessing the admin. Is > that correct? If so, is this the case because the former involves only one > layer of security (user must be authorised in order to access specific admin > functionality) whereas the latter involves two layers (same as above AND > user must be authorised to use the admin at all)? > > Thanks for your help, > > Sam > > PS. If anyone else also has opinions about this, I'd be glad to hear them! > > > > > It's not even an authorisation issue, it's that I'd be overiding nearly every method to make sure the behavior was what I wanted, and then I'd replace all the templates since I want everything the user sees to be similarly themed, and at this point I've already rewritten a ton of code. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
2009/5/26 Alex Gaynor > On Mon, May 25, 2009 at 7:51 PM, Sam Kuper > wrote: > >> Suppose you were re-writing Facebook in Django. >> >> Would you handle the complex profile and privacy settings pages by: >> >> A) exposing the relevant admin pages to users, with careful auth to stop >> users from being able to access admin pages they shouldn't be able to. >> Obviously this would require much custom templating in order to achieve the >> desired visual appearance (instead of the default Django admin appearance), >> but it would have the advantage of not requiring new views and forms to be >> written. >> >> B) creating forms and views as needed for the profile and privacy >> settings, keeping the users out of the admin app entirely, and reserving the >> latter only for Facebook staff. >> [...] >> > > B). The admin is designed really for use with fully trusted administrators > only, the extra hooks that have been placed in for more find grained control > notwithstanding. Thanks Alex. It sounds like your reason for choosing B is based on security concerns - specifically that authorisation within the admin may not be as strong as authorisation that prevents users from accessing the admin. Is that correct? If so, is this the case because the former involves only one layer of security (user must be authorised in order to access specific admin functionality) whereas the latter involves two layers (same as above AND user must be authorised to use the admin at all)? Thanks for your help, Sam PS. If anyone else also has opinions about this, I'd be glad to hear them! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: When to use admin, and when not to.
On Mon, May 25, 2009 at 7:51 PM, Sam Kuper wrote: > Suppose you were re-writing Facebook in Django. > > Would you handle the complex profile and privacy settings pages by: > > A) exposing the relevant admin pages to users, with careful auth to stop > users from being able to access admin pages they shouldn't be able to. > Obviously this would require much custom templating in order to achieve the > desired visual appearance (instead of the default Django admin appearance), > but it would have the advantage of not requiring new views and forms to be > written. > > B) creating forms and views as needed for the profile and privacy settings, > keeping the users out of the admin app entirely, and reserving the latter > only for Facebook staff. > > Or would you take some other approach? > > Please explain your answer, and link to documentation where relevant. > > Many thanks! > > Sam > > > > B). The admin is designed really for use with fully trusted administrators only, the extra hooks that have been placed in for more find grained control notwithstanding. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
