According to the 1.4 documentation on using Admin with multiple databases, you only need to implement 5 methods in your ModelAdmin subclass. I've overridden all 5 in the recommended way. Browsing the database works with no problems.
However, attempt to save an existing record and I get an error claiming that the table doesn't exist in the database - the default database for the project, not the one I've specified in the method implementations. In fact, save_model() doesn't get called before the error is thrown, so somewhere before it gets that far there's a reference somewhere that isn't successfully getting the "using" for the right database.
Anyone know what's missing? Here's my ModelAdmin class:
class TransactionAdmin(admin.ModelAdmin):
using = "salesdb"
def save_model(self, request, obj, form, change):
# Tell Django to save objects to the 'other' database.
obj.save(using=self.using)
def delete_model(self, request, obj):
# Tell Django to delete objects from the 'other' database
obj.delete(using=self.using)
def queryset(self, request):
# Tell Django to look for objects on the 'other' database.
return super(TransactionAdmin, self).queryset(request).using(self.using)
def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
# Tell Django to populate ForeignKey widgets using a query
# on the 'other' database.
return super(TransactionAdmin, self).formfield_for_foreignkey(db_field, request=request, using=self.using, **kwargs)
def formfield_for_manytomany(self, db_field, request=None, **kwargs):
# Tell Django to populate ManyToMany widgets using a query
# on the 'other' database.
return super(TransactionAdmin, self).formfield_for_manytomany(db_field, request=request, using=self.using, **kwargs)
And the error I'm getting is:
(1146, "Table 'django_dev._Transactions' doesn't exist")
django_dev is the default database, not the sales database.
It is apparently a bug.
https://code.djangoproject.com/ticket/19747
The bug has been accepted so I guess that means they confirmed it.
Related
For a long time we've been overriding our ModelAdmin's formfield_for_foreignkey to limit the queryset the field can choose from. Here's a simplified version of what I mean:
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == "site":
if not request.user.is_superuser:
kwargs["queryset"] = request.user.site
But I recently added this field to the autocomplete_fields definition (to get some Select2 gravy). The result was I now see no suggestions as a non-superuser account.
Is there a more right way to limit the queryset, or is this a simple bug in Django?
This needs a patch that's still in dev. You can be patient, or you can monkey-patch AutocompleteJsonView.has_perm as I am below. I just stuck this in settings.
If you're also stuck on 2.0.x (as I currently am shakes fist at Wagtail) you'll also need to make sure your ModelAdmins define a has_view_permission.
from django.contrib.admin.views.autocomplete import AutocompleteJsonView
def ac_has_perm(self, request, obj=None):
return self.model_admin.has_view_permission(request, obj=obj)
AutocompleteJsonView.has_perm = ac_has_perm
I've been trying to make the GenericTabularInline class work in a two-admin two-databases setup by inheriting from it and overriding some methods in the BaseModelAdmin class, as is done in the Django docs (https://docs.djangoproject.com/en/dev/topics/db/multi-db/), but if a child model is edited in the inline form, it always writes to the default database (I want the second admin to deal exclusively with a secondary database, models are the same for both), so I must not be overriding some method(s) or doing something wrong. Here's the class I have so far:
class MultiDBGenericTabularInline(generic.GenericTabularInline):
using = settings.SECONDARY_DATABASE
def save_model(self, request, obj, form, change):
# Tell Django to save objects to the 'other' database.
obj.save(using=self.using)
def delete_model(self, request, obj):
# Tell Django to delete objects from the 'other' database
obj.delete(using=self.using)
def queryset(self, request):
# Tell Django to look for objects on the 'other' database.
return super(MultiDBGenericTabularInline, self).queryset(request).using(self.using)
def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
# Tell Django to populate ForeignKey widgets using a query
# on the 'other' database.
return super(MultiDBGenericTabularInline, self).formfield_for_foreignkey(db_field, request=request, using=self.using, **kwargs)
def formfield_for_manytomany(self, db_field, request=None, **kwargs):
# Tell Django to populate ManyToMany widgets using a query
# on the 'other' database.
return super(MultiDBGenericTabularInline, self).formfield_for_manytomany(db_field, request=request, using=self.using, **kwargs)
#Override these three methods; otherwise the log manager attempts
#to write to the main db and raises an exception.
def log_addition(self, request, object):
pass
def log_change(self, request, object, message):
pass
def log_deletion(self, request, object, object_repr):
pass
Any help or hints are appreciated.
I realize this is an old question, but I've stumbled across a very similar thing recently. The trick is to override the parent Model Admin's save_formset method. In my case, the solution is to do something like this:
class SomeTabularInline(admin.TabularInline):
# stuff
class MyModelAdmin(admin.ModelAdmin):
using = 'something'
inlines = (SomeTabularInline,)
def save_formset(self, request, form, formset, change):
instances = formset.save(commit=False)
for obj in formset.deleted_objects:
obj.delete(using=self.using)
for instance in instances:
instance.save(using=self.using)
formset.save_m2m()
Note: I'm using a TabularInline instance, and not a GenericTabularInline but they both descend from InlineModelAdmin; so I'm hopeful that this would work in your case.
Source: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/#django.contrib.admin.ModelAdmin.save_formset
In other words, I would like to disallow users from editing or viewing anything but their own inputted data, throughout all applications.
I read here that this may be impossible with the built in admin application. If so is there an extension available?
Thanks
It can be done.
You need to create the appropriate modelAdmin in your admin.py first.
For list "display" filtering modify the queryset method:
class MyModelAdmin(admin.ModelAdmin):
def queryset(self, request):
return Entry.objects.filter(owner=request.user)
For field filtering, depending on the field type you want to limit you override the appropriate method.
Related django documentation is here:
https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_for_foreignkey
To limit foreignkey field output you can do something like this:
(from the django documentation)
class MyModelAdmin(admin.ModelAdmin):
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == "car": # The name of the field you want to limit
kwargs["queryset"] = Car.objects.filter(owner=request.user)
return super(MyModelAdmin, self).formfield_for_foreignkey(db_field, request, **kwargs)
Let's say I have a site where Users can add Entries through admin panel. Each User has his own Category he is responsible for (each Category has an Editor assigned through ForeingKey/ManyToManyField).
When User adds Entry, I limit the choices by using EntryAdmin like this:
class EntryAdmin(admin.ModelAdmin):
(...)
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == 'category':
if request.user.is_superuser:
kwargs['queryset'] = Category.objects.all()
else:
kwargs['queryset'] = Category.objects.filter(editors=request.user)
return db_field.formfield(**kwargs)
return super(EntryAdmin, self).formfield_for_foreignkey(db_field, request, **kwargs)
This way I can limit the categories to which a User can add Entry and it works perfect.
Now the tricky part: On the Entry changelist/action page I want to show only those Entries which belong to current User's Category. I tried to do this using this method:
def changelist_view(self, request, extra_context=None):
if not request.user.is_superuser:
self.queryset = self.queryset.filter(editors=request.user)
But I get this error:
AttributeError: 'function' object has no attribute 'filter'
This is strange, because I thought it should be a typical QuerySet. Basically such methods are not well documented and digging through tons of Django code is not my favourite sport.
Any ideas how can I achieve my goal?
Warning: This answer is from 2010, and is not useful for Django >= 1.8.
queryset is a method on ModelAdmin which returns a queryset. You need to override it on your EntryAdmin class.
def queryset(self, request):
qs = super(EntryAdmin, self).queryset(request)
if request.user.is_superuser:
return qs
else:
return qs.filter(editors=request.user)
Changing the queryset will limit the Entries shown in the list view. You also need to override has_change_permission to ensure that the user has permission to edit the object on the individual object editing page. See the following blog post by James Bennett for further details:
http://www.b-list.org/weblog/2008/dec/24/admin/
I have a booking model that needs to check if the item being booked out is available. I would like to have the logic behind figuring out if the item is available centralised so that no matter where I save the instance this code validates that it can be saved.
At the moment I have this code in a custom save function of my model class:
def save(self):
if self.is_available(): # my custom check availability function
super(MyObj, self).save()
else:
# this is the bit I'm stuck with..
raise forms.ValidationError('Item already booked for those dates')
This works fine - the error is raised if the item is unavailable, and my item is not saved. I can capture the exception from my front end form code, but what about the Django admin site? How can I get my exception to be displayed like any other validation error in the admin site?
In django 1.2, model validation has been added.
You can now add a "clean" method to your models which raise ValidationError exceptions, and it will be called automatically when using the django admin.
The clean() method is called when using the django admin, but NOT called on save().
If you need to use the clean() method outside of the admin, you will need to explicitly call clean() yourself.
http://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs#validating-objects
So your clean method could be something like this:
from django.core.exceptions import ValidationError
class MyModel(models.Model):
def is_available(self):
#do check here
return result
def clean(self):
if not self.is_available():
raise ValidationError('Item already booked for those dates')
I haven't made use of it extensively, but seems like much less code than having to create a ModelForm, and then link that form in the admin.py file for use in django admin.
Pretty old post, but I think "use custom cleaning" is still the accepted answer. But it is not satisfactory. You can do as much pre checking as you want you still may get an exception in Model.save(), and you may want to show a message to the user in a fashion consistent with a form validation error.
The solution I found was to override ModelAdmin.changeform_view(). In this case I'm catching an integrity error generated somewhere down in the SQL driver:
from django.contrib import messages
from django.http import HttpResponseRedirect
def changeform_view(self, request, object_id=None, form_url='', extra_context=None):
try:
return super(MyModelAdmin, self).changeform_view(request, object_id, form_url, extra_context)
except IntegrityError as e:
self.message_user(request, e, level=messages.ERROR)
return HttpResponseRedirect(form_url)
The best way is put the validation one field is use the ModelForm... [ forms.py]
class FormProduct(forms.ModelForm):
class Meta:
model = Product
def clean_photo(self):
if self.cleaned_data["photo"] is None:
raise forms.ValidationError(u"You need set some imagem.")
And set the FORM that you create in respective model admin [ admin.py ]
class ProductAdmin(admin.ModelAdmin):
form = FormProduct
I've also tried to solve this and there is my solution- in my case i needed to deny any changes in related_objects if the main_object is locked for editing.
1) custom Exception
class Error(Exception):
"""Base class for errors in this module."""
pass
class EditNotAllowedError(Error):
def __init__(self, msg):
Exception.__init__(self, msg)
2) metaclass with custom save method- all my related_data models will be based on this:
class RelatedModel(models.Model):
main_object = models.ForeignKey("Main")
class Meta:
abstract = True
def save(self, *args, **kwargs):
if self.main_object.is_editable():
super(RelatedModel, self).save(*args, **kwargs)
else:
raise EditNotAllowedError, "Closed for editing"
3) metaform - all my related_data admin forms will be based on this (it will ensure that admin interface will inform user without admin interface error):
from django.forms import ModelForm, ValidationError
...
class RelatedModelForm(ModelForm):
def clean(self):
cleaned_data = self.cleaned_data
if not cleaned_data.get("main_object")
raise ValidationError("Closed for editing")
super(RelatedModelForm, self).clean() # important- let admin do its work on data!
return cleaned_data
To my mind it is not so much overhead and still pretty straightforward and maintainable.
from django.db import models
from django.core.exceptions import ValidationError
class Post(models.Model):
is_cleaned = False
title = models.CharField(max_length=255)
def clean(self):
self.is_cleaned = True
if something():
raise ValidationError("my error message")
super(Post, self).clean()
def save(self, *args, **kwargs):
if not self.is_cleaned:
self.full_clean()
super(Post, self).save(*args, **kwargs)