I am having some struggles how does exactly django.admin.LogEntry objects are created.
Consider the following scenario:
I have a bunch of functions which take a csv file with data that allow me to create multiple objects at one call (just iterate through the file, use the data and if data in given row is correct: create a Model instance). I want to make sure that that each of that creation will be logged.
The question is: django docs are not very descriptive on how does LogEntry works and I am not sure if such actions (not taken in the admin panel itself) will be logged there. Also: will the LogEntries be created for the related objects or I have to trigger them manually?
Does anybody got any experience with such scenarios and can share thoughts about it?
The LogEntry model is in the Admin package and only used by Django admin by default. It is used in the admin layer and not model layer when saving objects. if you want to use it outside the admin, then you will have to manually create the entries yourself. That also means the admin will likely display entries of changes made by normal users so you have to think about how you want the entries displayed
Related
We are using LogEntry/django_admin_log and recording additions, changes and deletions made from Django Admin. However we have two issues we need to address:
1.) Changes record only the field that changed. Not the old and new values. We would like to add the specific details of all changes.
2.) We would like to record an action in this log every time a page is viewed on the Django Admin panel.
How would it be best to proceed?
We are happy to do some work to extend the existing functionality of this, or we are happy to move to a completely new 3rd part module if necessary, or write our own. But would like some guidance from some experts?
We had similar requirements in terms of keeping history and track of actions done by users with a higher level of detail in terms of values changes. What we ended up doing was creating a new model called "History" which we populated with the user, the name of the model being changed, the instance id and a dictionary called changes showing the name of each field changed and values from - to.
In order to populate the new model, we overrode the save_model function in the admin file for the model we want to track. Regarding the page views, you can overrride the get_fields if "obj" is not None and create an instance of History accordingly.
The admin interface for editing (adding, deleting, changing) entries in the database is great. I am working on a system, based on HTML forms, to allow users to edit information relevant to them in the database. This will take a lot of work, and look less than professional. Is there a standard way to allow a logged in user to use an administration-interface-like page to edit their (and only their) entries in a DB/model?
You can probably do what you need by customizing django admin. In django admin you can define get_queryset method to restrict objects available for current user. See https://docs.djangoproject.com/en/2.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_queryset, example there matches pretty well to your task
One use case for overriding this method is to show objects owned by the logged-in user...
I'm working on some Django Rest Framework based project (quite expected API for some web-app). It has as traditional Django models, and some kind of model-like objects: they behave like Django models but don't store anything in DB. No tables, no content-types. When we ask them for objects, they goes to external API and forms resulting Queryset.
Now I need to build some role-based access system. To make the architecture clear and extensible, I want to make groups and permissions managable through the Django Admin interface. So, I guess, we need to put some permissions to DB and then we'll be able to add these permissions to user groups. After that, we'll check these permissions in DRF.permissions class. But since we have neither tables, nor content-types for these 'models', we can't add records to permissions table right now.
What is the right way to make this possible? Should I rebuild these 'models' through the metaclass with proxy = True? Or should I add a proxy layer above? Maybe I should add some dummy content-types by hand?
so I have multiple apps for my website; one to register, one to view a map with the users locations plotted on, and one to view the users' profiles. But those three apps need access to the same model, namely: User. (On the register page it gets created and added to DB, the map page needs its hometown in order to locate it on the map, and the profile pages also need it obviously). But whenever I add a new user on the admin page, I first have to rerun the server in order for it to appear on the map. Beforehand when the model was defined in just one app, I just needed to refresh the page to see the change. I have created the User model in the Register app and redirected to it in other apps like this:
class Meta(models.Model):
db_table = 'register_User'
Why doesnt the template retrieve the up to date data without restarting the server?
I hope u can help out
The way you are using the Django ORM is not correct.
You should not use the Meta in a models.Model class to reference a table in order to be able to access it.
If you need a model from a different app, just import it like this:
from user.models import User
And then you can use it in your views or models.
For a better understanding on how the Django ORM works, i recommend the Django tutorial or the models.Model reference pages.
Say I have an app with ModelA, ModelB, and ModelC
For my app's admin page (/admin/app), how do I hook into the display of the "App administration" page so I may hide Model types that are empty (have no instances)?
That's a big ask, because you'd have to dynamically register/unregister apps according to the results of a database/ORM query (a count(), at least) for each of the models that each of the INSTALLED_APPS contains.
Every single time you viewed the admin.
While that in itself is unpleasant enough, bear in mind that admin.py for each app is processed at server restart/reload time (IIRC), so you could't hope to hook up something cute like those DB lookups there, as it'd only get run once and not reflect the actual state of models currently have objects stored in your database.
Better move: leave it be. If there are no objects to view for a given model, then there are no objects to view for a given model.
If you're concerned about your client/user making new models in there when they shouldn't, then that's a combination of user education and admin user permissions that you can sort out.
As said in a few places: "The Admin is not your app." If the customization goes beyond the trivial, it's time to write your own views. You can still hook them in to the admin site by overriding the base admin template and even serving them from the same root path as the rest of your admin.