If you want to update the initially selected value (but still allow the user to select a different site)I think you're on the right track with ModelAdmin.get_form
If you want to completely restrict them to their current session's site you'll want to use a combination of ModelAdmin.get_form (to exclude the field from the form or maybe make it read only) and ModelAdmin.save_model (to set the site to the session site before calling save). In case you've never used either method this is a decent starting point to see some examples: http://stackoverflow.com/questions/687829/django-overriding-get-form-to-customize-admin-forms-based-on-request Note that get_form can pass back a form class which which can be handy but you can also set ModelAdmin options and call super() - you'll see examples of both there. On Friday, June 21, 2013 9:03:22 AM UTC-7, Richard E. Cooke wrote: > > I'm trying to pass the request object, which includes the session object, > to a chunk of Django 1.5 code that is tied to the model (model.clean). When > running the Admin app, it does not have access to the request object. > > So I tried stashing it in RAM using thread.local(), only to get a crash > course in how "shared" RAM is between active sessions! > > I have several choices I'm trying to figure out the one with the least > amount of work. I would not be working in Automation if I weren't lazy..... > > My goal is to auto-fill the company division the current session belongs > to. This allows us to use the same business software for multiple > divisions. Django 1.4 and 1.5 Admin has a lovely built-in easy method to > filter records before they are displayed (ModelAdmin.queryset), the example > given in the docs shows how to limit records to the user that "owns" them. > I just changed that to "company division" (the list is stored in Site > database), and presto! All data displayed anyplace inside the admin is > restricted and the operation is totally transparent to the user. > > What I need to do now is have an automatic method to populate each > record's "site" field with the "site" value inside the current session. > Note that this is different from how the "site" framework and "SITE_ID" > field are used. > > 1. I can copy the admin view and make changes to it. Since it is > passed the request, I can access the session object to get the seed value. > This would be the "best practice" when I (eventually) get approval to > replace the admin with our own task-based system. But I suspect its a lot > of work to try it inside of the admin framework, It might have a domino > effect resulting in the editing of a lot more related files. The html > templates, for example. > 2. Which brings me to copying just the templates and changing them, > since I think they are sent the session data as part of the request > object. > I have not learned how to work with templates, so I cannot judge how much > effort this represents. > 3. Find some other mechanism within the admin framework. Find a place > where I have access to both the data instance and the session data. Or a > way I can pass one or the other to some code where I can make use of it. > > Its the 3rd possibility I'm trolling for here. Since I don't have time to > do choice #1 - at least the full custom version. And I dunno about #2. > > There is another Django 1.4/1.5 feature I might be able to use: > ModelAdmin.get_form. This is called to "get" the add, change or delete > form. And it is passed the request object. I just have to learn if it also > has access to the data instance. Or maybe I can pass "default" values as a > keyword argument? I have a vague memory reading something about that. Have > to dig back into the Admin docs and/or read the source code.... > > As always, any input, thoughts, or suggestions welcome! > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
