Re: Advanced Admin Customization
Either that, or use a custom manipulator and override the save method there. Depends on if the processing will always need to be done when saving or just done with the form data. If it's the form data, probably best to put it in a manipulator. If you want, just create a manipulator and override it in the model, and only override the save method of the manipulator, the rest can probably be normal. Chris --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
mthorley: I think you just need to override the save() method of your model. You can do all the processing you need before it's saved. Corey On Sep 5, 2006, at 10:21 AM, mthorley wrote: > > Thanks for the tip Nate! > > Does any one know what method receives the data from the form when it > is submitted? I tried models.Field.get_db_prep_save but that doesn't > seem to be working. I need to process the form data before it is > passed > off to the database for saving. > > -- > mthorley > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
Thanks for the tip Nate! Does any one know what method receives the data from the form when it is submitted? I tried models.Field.get_db_prep_save but that doesn't seem to be working. I need to process the form data before it is passed off to the database for saving. -- mthorley --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
On Fri, Sep 01, 2006 at 10:21:38AM -0700, mthorley wrote: > Table creation is handled by core.management. In it, a lookup is > preformed where it loads the dict DATA_TYPES (or something like that) > from db.backends..creation. Then it attempts a key matching the > field class name of each field in your model. So in order to create > your own fields, whether you subclass an existing one or not, you must > either overwrite the class name, or add your fieldtype to the list. This thread has peaked my interest so I did some code digging. I was thinking that overriding the class name didn't seem like a smart choice. I thought it would be nice if the creation code would check the parent class's name if it couldn't find the current class name in DATA_TYPES. Upon inspection of the code I found it was calling get_internal_type() for each field. If you look in db/models/fields/__init__.py you'll find that this is used in EmailField which subclasses CharField. class EmailField(CharField): ... def get_internal_type(self): return "CharField" Now I'll have to try creating some custom fields myself. :) Nate --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
I found it! There is a mapping of Field types in db.backends..creation where yourdb is mysql or postgres or what ever. I found it by grepping for CREATE in the django source. Table creation is handled by core.management. In it, a lookup is preformed where it loads the dict DATA_TYPES (or something like that) from db.backends..creation. Then it attempts a key matching the field class name of each field in your model. So in order to create your own fields, whether you subclass an existing one or not, you must either overwrite the class name, or add your fieldtype to the list. The easiest option, (if you're using a column type already defined by django) is to overwrite the class name. The second option is a maintenance nightmare to be avoided if at all possible. Here's a snip of my custom Field, I hope to write up a tutorial on this later. I'll write back when I get it online. class MyField(models.Field): def __new__(cls): cls.__name__ = 'IntegerField' return models.Field.__new__(cls) You set cls.__name__ to the string name of field type in db.backends..creation that corresponds to the type of db column you want to use. Thanks again Chris! Your comments really helped me work out the thought process. I'll try that template/model/management permisions enforcement just as soon as I get this custom Field complete. Also thanks to all the django devs, your excellent code, and comments lended a great hand in solving this mystery. -- mthorley --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
> Oh, I see where you're going with it. Just hide the interface from the > user. That's a great idea, I still need a way though to enforce it so > that carefully crafted POST requests don't allow unauthorized users > from breaking things. That's true, maybe using the custom manipulator would handle that, but I'm not so sure. Possible a combination of the two methods would work, either save and template or manipulator and template. Either method works, more just style then anything else. > > That was my first pass. I subclassed models.IntegerField and overroad > get_manipulator_field_objs, and return my custom Form. However, when > running syncdb I still got a KeyError. > > I think that there is a dict somewhere that maps models to their sql > implementation and that my model doesn't exist in that dict, hence a > KeyError. But that's really just a guess. I'd love to hear from an > authority about where the sql structure of a model is defined. When I get a moment later this evening, I'll dive into the DB code and see what else I can find. From the top of my head, I don't think there is anything, but I might be wrong...when I've been exploring the DB code I haven't looked for anything along those lines. Maybe pastebin the code and the trace and I can offer some more help. Chris --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
Chris Long wrote: > Maybe, but if you do it in the template then it won't even show the > option to the user and you'll avoid the trouble of getting the error > from the save method to be displayed to the user. Oh, I see where you're going with it. Just hide the interface from the user. That's a great idea, I still need a way though to enforce it so that carefully crafted POST requests don't allow unauthorized users from breaking things. > If all you're using is an Integer, then I'd suggest just subclass the > integer field and leave most of it the same as it is and only override > the part where it returns the form field. Should avoid a lot of > trouble. That was my first pass. I subclassed models.IntegerField and overroad get_manipulator_field_objs, and return my custom Form. However, when running syncdb I still got a KeyError. I think that there is a dict somewhere that maps models to their sql implementation and that my model doesn't exist in that dict, hence a KeyError. But that's really just a guess. I'd love to hear from an authority about where the sql structure of a model is defined. Thanks again Chris, you're thoughts have really helped -- mthorley --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
> Thanks, that's a neat trick, though from the surface I'm not 100% sure > it will do what I'm thinking. I'll have to investigate further. My > intuition tells me I need to do the checks in the model, maybe with a > save hook, not in the template; but I may be off on that. Maybe, but if you do it in the template then it won't even show the option to the user and you'll avoid the trouble of getting the error from the save method to be displayed to the user. > > I am currently trying option 2, which is not as difficult as I thought > it might be, thought I have gotten stuck. > > I've created a new field that subclasses models.Field, and a new form > that subclasses forms.formField, both seem correct (at lest the models > doesn't throw any errors when starting the server), however when I try > manage.py syncdb appname, the manager errors: KeyError: "MyBitField" > > Does any one know where you include that code does the db creation > stuff? > If all you're using is an Integer, then I'd suggest just subclass the integer field and leave most of it the same as it is and only override the part where it returns the form field. Should avoid a lot of trouble. Cheers, Chris --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
Chris Long wrote: > For the permission checking, See: > http://code.djangoproject.com/wiki/ExtendingAdminTemplates for more Thanks, that's a neat trick, though from the surface I'm not 100% sure it will do what I'm thinking. I'll have to investigate further. My intuition tells me I need to do the checks in the model, maybe with a save hook, not in the template; but I may be off on that. > As for the second part, there are two possible routes... > 1) Override the default change/add manipulator for the model... > 2) Create a new field in the model that replaces the integer field you > are currently using... I am currently trying option 2, which is not as difficult as I thought it might be, thought I have gotten stuck. I've created a new field that subclasses models.Field, and a new form that subclasses forms.formField, both seem correct (at lest the models doesn't throw any errors when starting the server), however when I try manage.py syncdb appname, the manager errors: KeyError: "MyBitField" Does any one know where you include that code does the db creation stuff? Thanks again Chris. -- mthorley --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Advanced Admin Customization
Howdy, For the permission checking, you could override the admin template and add auth checking in there for the various permissions you want to check for. See: http://code.djangoproject.com/wiki/ExtendingAdminTemplates for more details on this. And in the auth documents there is info on how to access permissions in the templates. As for the second part, there are two possible routes off the top of my head. Neither of which I have tried or have any idea if they will work, maybe someone else can validate these. From experience, they both should work. 1) Override the default change/add manipulator for the model. E.g. Class Object(Models): ChangeManipulator = NewAddManipulator Therefore you can select the fields you want and how you want them. Including any processing of the data. I guess you could also do the permission checking for fields here, but it might not be the best spot. 2) Create a new field in the model that replaces the integer field you are currently using, in this new field you can override the method get_manipulator_field_objs to return the field object you want for this. See django.db.models.fields for the existing fields. Hope that helps, Chris --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Advanced Admin Customization
Greetings, I am trying to do a few advanced (from my point of view) customizations to the built in admin. I have searched around but haven't found the answers I'm looking for. If any one can help, or point me to a resource that can, I'd be forever greatful. (or at least really grateful ;) More Elaborate Permissions Handling == I've already setup and customized the basic permisions, but now I need to be more elaborate. Rather than allowning read/write to whole records, I need to limit access to specific attributes. For example: any user can add a new blog post, but only users in group X can toggle the 'publish' bit on any blog post and only users in group Z can delete a post. Are there hooks for individual fields, or at least saving, that will allow me to enforce my own permission checks? Custom fields === I also need to create my own custom field. In one of my models I have a integer where each bit stands for an action. Similar to the unix permissions system. i.e. chmod 640 user: r/w, group r, other 0 Rather than display this as a text box. I want to create a field with a series of check boxes to turn each bit on or off. I dug around in the source but got stuck. It would be nice too, if I can do this with add modifying the orginal source. Thanks much for anythoughts or help on these. -- mthorley --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
