so i'm using the admin LogEntry object/table to log events in my app. I have a view where i'd like to display each LogEntry.
It would be really great if i could join the LogEntry with the actual objects they represent (so i can display attributes of the object inline with the log entry)
In theory this should be easy as we have the model type and id from the LogEntry but i can't figure out how to join them using a queryset.
i thought i could just grab all the ids of the different objects and make another dictionary for each object type and then join them somehow (maybe zip the lists together?) but that seems dumb and not very djano-ish/pythonic.
does anybody have better suggestions?
** edit **
just want to clarify am not looking to use admin, but roll a custom view and template.
As I know Django uses contenttypes framework to perform logging in admin. So you should create generic relation inside your model and then to show inlines in admin use GenericTabularInline and GenericStackedInline. Please consult with the article.
from django.contrib import admin
from django.contrib.admin.models import LogEntry
from django.contrib.contenttypes.generic import GenericTabularInline
from django import forms
from some_app import models
from some_app.models import Item
class LogForm(forms.ModelForm):
class Meta:
model = LogEntry
class LogInline(GenericTabularInline):
ct_field = 'content_type'
ct_fk_field = 'object_id'
model = LogEntry
extra = 0
class ItemForm(forms.ModelForm):
class Meta:
model = Item
class ItemAdmin(admin.ModelAdmin):
form = ItemForm
inlines = [LogInline,]
admin.site.register(models.Item, ItemAdmin)
and you add to Item:
class Item(models.Model):
name = models.CharField(max_length=100)
logs = generic.GenericRelation(LogEntry)
this change won't create anything in your database, so there is no need to sync
Recent Django versions require to create a proxy for LogEntry:
from django.contrib import admin
from django.contrib.admin.models import LogEntry
from django.contrib.contenttypes.generic import GenericTabularInline
class LogEntryProxy(LogEntry):
content_object = GenericForeignKey('content_type', 'object_id')
class Meta:
proxy = True
class LogInline(GenericTabularInline):
model = LogEntry
extra = 0
class ItemAdmin(admin.ModelAdmin):
inlines = [LogInline,]
admin.site.register(models.Item, ItemAdmin)
Related
THE DESCRIPTION
I'm writing an API on a Django project that will get all the LogEntry on a specific model and filter them by the specific model's field.
So my model looks like this:
from django.contrib.admin.models import ContentType, LogEntry
from django.contrib.auth.models import Group
from django.contrib.contenttypes.fields import GenericForeignKey, GenericRelation
from django.db import models
class LogEntryProxy(LogEntry):
content_object = GenericForeignKey()
class Meta:
proxy = True
class HomeItem(models.Model):
# Some Fields
groups = models.ManyToManyField(Group, related_name="home_item_group")
log_entry_relation = GenericRelation(LogEntryProxy, related_query_name='log_homeitem')
In the view I need to be able to make queries that fetch LogEntryProxy items that refer to HomeItem and filter them by the groups that have access to it and serialize the results. so something like this:
log_entry_queryset = LogEntryProxy.objects.filter(log_homeitem__groups__in=user.groups.all()).distinct()
My serializer looks like this (using "djangorestframework"):
from rest_framework import serializers
class LogEntryHomeItemSerializer(serializers.ModelSerializer):
content_object = HomeItemSerializer(many=False)
object_id = serializers.IntegerField()
class Meta:
model = LogEntryProxy
fields = ('object_id', 'action_flag', 'content_object', )
And it works!
THE PROBLEM
So what's the problem you may ask!
The Problem is that LogEntry actions like create and edit work! and the API will give you the results, but when you delete a HomeItem object all the LogEntry objects pointing to it will be deleted as well, thus no delete action will be given by the api (plus all the create and edit ones pointing to that object will be deleted as well). and that's all because Django's GenericRelation doesn't support on_delete. If I delete the GenericRelatin field this doesn't happen but then I have to be able to filter the HomeItem by groups in the LogEntryProxy queryset and it can't be done without the GenericRelation.
I was wondering if anyone could tell me what to do in this situation?
Should I implement a custom logging system? or there's another way that I haven't seen it yet!
try:
homeids = HomeItem.objects.filter(groups__in=user.groups.all()).values_list('id',flat=True)
log_entry_queryset = LogEntryProxy.objects.filter(object_id__in=homeids,content_type_id=ContentType.objects.get_for_model(HomeItem).id).distinct()
If you query this way you don't need GenericRelation
Update:
The above query will not fetch logentries of delete action.
It can be done like:
from django.db.models import Q
from django.contrib.admin.models import DELETION
log_entry_queryset = LogEntryProxy.objects.filter(Q(object_id__in=home_ids,content_type_id=ContentType.objects.get_for_model(HomeItem).id) | Q(action_flag=DELETION,content_type_id=ContentType.objects.get_for_model(HomeItem).id)).distinct()
My model looks like this:
class Search(models.Model):
user = models.ForeignKey(User)
regions = models.ManyToManyField(Region)
class Region(models.Model):
name = models.CharField(max_length=100")
In my admin when I register Search model and Region model,
I want to see the User data in the Search model and search and user data in Region model.
both in the list_display and inlines of the admin. Since one is a ForeignKey and one is ManytoManyField, I am not clear how to get this working.
some help will be much appreciated
Thanks
You aren't going to be able to get the User data visible on the inline on the Region admin screen easily. Below is a decent starting spot.
from django.contrib import admin
from django.contrib.auth.models import User
from .models import Search, Region
class UserInline(admin.TabularInline):
model = User
class SearchAdmin(admin.ModelAdmin):
inlines = [
UserInline,
]
class SearchInline(admin.TabularInline):
model = Search
class SearchRegionsInline(admin.TabularInline):
model = Search.regions.through
class RegionAdmin(admin.ModelAdmin):
inlines = [
SearchRegionsInline,
SearchInline,
]
If you're set on editing the user information from the Region admin screen, then you will want to create a custom form for the SearchInline so it has the fields from the User model and then populate the values in the __init__ if an instance is passed in.
I want my models to have order field, which will contain order of an item among all items of its kind.
And I want to use choices within that IntegerField, which would contain all the numbers of currently existing items in that table.
So it would need to be dynamic choices.
How do I load all existing "order" values of all existing items in a table, and use this list for choices?
It sounds like you want to build a manager for your model:
models.py
from django.db import models
class OrderManager(models.Manager):
def order_choices(self):
return [(i, i) for i in OrderModel.objects.values_list('order', flat=True)]
class OrderModel(models.Model):
objects = OrderManager()
order = models.IntegerField()
class Meta:
ordering = ['order']
def __unicode__(self):
return '%i' % self.order
forms.py
from django import forms
from yourapp.models import OrderModel
class OrderModelForm(forms.ModelForm):
order = forms.ChoiceField(choices=OrderModel.objects.order_choices())
class Meta:
model = OrderModel
admin.py
from django.contrib import admin
from yourapp.forms import OrderModelForm
from yourapp.models import OrderModel
class OrderModelAdmin(admin.ModelAdmin):
form = OrderModelForm
admin.site.register(OrderModel, OrderModelAdmin)
Edit
Managers are use to make general model queries without having an instance of a model object. If you don't understand the concept of managers, you can still refactor the code out of the manager class, stick it somewhere else and import that function across your code. Managers allow you to abstract custom general queryset that you can reuse. See more details https://docs.djangoproject.com/en/dev/topics/db/managers/
The code without the manager will look like
views.py or some other file
from app.models import OrderModel
def order_choices():
return [(i, i) for i in OrderModel.objects.values_list('order', flat=True)]
From anywhere in your code, if you want to reuse the above multiple times:
from app.views import oder_choices
order_choices()
as opposed to:
from app.models import OderModel
OrderModel.objects.order_choices()
If you only want to use the above once, you can leave it in the forms.py as shown in the other answer. It's really up to you on how you want to refactor your code.
Dont add the choices directly to the model, add them to a form represnting the model later, by overriding the field with a set of choices.
than, do something like:
class MyForm(..):
myfield_order_field = IntegerField(choices = [(i,i) for range(MyModel.objects.count)])
class Meta():
model = MyModel
if you want to use it in the admin, add to your Admin Class:
class MyModelAdmin(admin.ModelAdmin):
...
form = MyForm
it will override this field in the admin too.
I have a Django application with some fairly common models in it: UserProfile and Organization. A UserProfile or an Organization can both have 0 to n emails, so I have an Email model that has a GenericForeignKey. UserProfile and Organization Models both have a GenericRelation called emails that points back to the Email model (summary code provided below).
The question: what is the best way to provide an Organization form that allows a user to enter organization details including 0 to n email addresses?
My Organization create view is a Django class-based view. I'm leaning towards creating a dynamic form and an enabling it with Javascript to allow the user to add as many email addresses as necessary. I will render the form with django-crispy-forms and django-floppyforms for display on a site using Twitter Bootstrap.
I've thought about doing this with a BaseGenericInlineFormset embedded within the form, but this seems like overkill for email addresses. Embedding a formset in a form delivered by a class-based view is cumbersome too.
Note that the same issue occurs with the Organization fields phone_numbers and locations.
Code
emails.py:
from django.db import models
from parent_mixins import Parent_Mixin
class Email(Parent_Mixin,models.Model):
email_type = models.CharField(blank=True,max_length=100,null=True,default=None,verbose_name='Email Type')
email = models.EmailField()
class Meta:
app_label = 'core'
organizations.py:
from emails import Email
from locations import Location
from phone_numbers import Phone_Number
from django.contrib.contenttypes import generic
from django.db import models
class Organization(models.Model):
active = models.BooleanField()
duns_number = models.CharField(blank=True,default=None,null=True,max_length=9) # need to validate this
emails = generic.GenericRelation(Email,content_type_field='parent_type',object_id_field='parent_id')
legal_name = models.CharField(blank=True,default=None,null=True,max_length=200)
locations = generic.GenericRelation(Location,content_type_field='parent_type',object_id_field='parent_id')
name = models.CharField(blank=True,default=None,null=True,max_length=200)
organization_group = models.CharField(blank=True,default=None,null=True,max_length=200)
organization_type = models.CharField(blank=True,default=None,null=True,max_length=200)
phone_numbers = generic.GenericRelation(Phone_Number,content_type_field='parent_type',object_id_field='parent_id')
taxpayer_id_number = models.CharField(blank=True,default=None,null=True,max_length=9) # need to validate this
class Meta:
app_label = 'core'
parent_mixins.py
from django.contrib.contenttypes.models import ContentType
from django.contrib.contenttypes import generic
from django.db import models
class Parent_Mixin(models.Model):
parent_type = models.ForeignKey(ContentType,blank=True,null=True)
parent_id = models.PositiveIntegerField(blank=True,null=True)
parent = generic.GenericForeignKey('parent_type', 'parent_id')
class Meta:
abstract = True
app_label = 'core'
you can try using .split(), with this your form would look easier and users wont have to keep on adding text fields.
What you can do is, make one textbox where user can add multiple emails and separate them by a coma. and then in your views you can do this
email = emails.split(',')
for i in emails:
#assign email and save.
in case of having an email type
it might still be a good idea to build a system like that. what you can do is
abc#gmail.com-work,xyz#k.com-school
and then you can split them like this
email-type=email.split(',')
for i in email-type:
email=i.split('-')[0]
if i.split('-')[1]:
type=i.split('-')[1]
else:
#give it a default type
I have a model that has a ForeignKey to the built-in user model in django.contrib.auth and I'm frustrated by the fact the select box in the admin always sorts by the user's primary key.
I'd much rather have it sort by username alphabetically, and while it's my instinct not to want to fiddle with the innards of Django, I can't seem to find a simpler way to reorder the users.
The most straightforward way I can think of would be to dip into my Django install and add
ordering = ('username',)
to the Meta class of the User model.
Is there some kind of monkeypatching that I could do or any other less invasive way to modify the ordering of the User model?
Alternatively, can anyone thing of anything that could break by making this change?
There is a way using ModelAdmin objects to specify your own form. By specifying your own form, you have complete control over the form's composition and validation.
Say that the model which has an FK to User is Foo.
Your myapp/models.py might look like this:
from django.db import models
from django.contrib.auth.models import User
class Foo(models.Model):
user = models.ForeignKey(User)
some_val = models.IntegerField()
You would then create a myapp/admin.py file containing something like this:
from django.contrib.auth.models import User
from django import forms
from django.contrib import admin
class FooAdminForm(forms.ModelForm):
user = forms.ModelChoiceField(queryset=User.objects.order_by('username'))
class Meta:
model = Foo
class FooAdmin(admin.ModelAdmin):
form = FooAdminForm
admin.site.register(Foo, FooAdmin)
Once you've done this, the <select> dropdown will order the user objects according to username. No need to worry about to other fields on Foo... you only need to specify the overrides in your FooAdminForm class. Unfortunately, you'll need to provide this custom form definition for every model having an FK to User that you wish to present in the admin site.
Jarret's answer above should actually read:
from django.contrib.auth.models import User
from django.contrib import admin
from django import forms
from yourapp.models import Foo
class FooAdminForm(forms.ModelForm):
class Meta:
model = Foo
def __init__(self, *args, **kwds):
super(FooAdminForm, self).__init__(*args, **kwds)
self.fields['user'].queryset = User.objects.order_by(...)
class FooAdmin(admin.ModelAdmin):
# other stuff here
form = FooAdminForm
admin.site.register(Foo, FooAdmin)
so the queryset gets re-evaluated each time you create the form, as opposed to once, when the module containing the form is imported.