I really like StreamFields, but I don't want the baggage of Wagtail's Publishing system.
For example, consider a Forum community site. Instead of using CK Editor or BBCode, Markdown etc form input. I want to give users the option of StreamField based input to construct posts or replies
Is this possible? If yes, what steps would I need to take or edits to Wagtail do I need to do?
I'm guessing using a permission system while keeping the user as a limited admin would be the thing to do, since removing the user from admin doesn't seem to be possible since Wagtail is heavily reliant on Django Admin.
I'm guessing using a permission system while keeping the user as a
limited admin would be the thing to do, since removing the user from
admin doesn't seem to be possible since Wagtail is heavily reliant on
Django Admin.
If you want to reuse StreamFields, you probably want to use the Wagtail admin interface; doing otherwise is likely to be quite a bit of work. So users will need to be able to log in and have the wagtail_admin permission so they can access the admin interface. If you tried to use Page models for your forum, you are going to end up crossways of the way Wagtail's page permissions cascade. You could probably write your own admin views for regular users to add certain kinds of content.
But honestly, unless you have quite a bit of experience with Wagtail in its normal content management mode, I wouldn't suggest you try using it for this use case.
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
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've been successfully using Django's admin panel for internal users for a while but I recently hit a brick wall while trying to customize it and I'm curious if I'm spending too much time on it. So, my question is:
Is Django's admin panel intended to just be temporary scaffolding, that is, to be used only during the initial development of the application and to be replaced by custom code similar to Rails' scaffolding?
Obviously by using the admin panel I get a lot of functionality for free and as new features are added I get those for free too. What do other people do?
I wouldn't say the admin is meant to be temporary scaffolding but it might not be the best choice for many cases. I've worked with a very large and well known media company that used the admin as the basis for the entire workflow interface for its producers and editors. Unfortunately, your decision making process about when or when not to use the admin will benefit largely from your overall knowledge about the internals of Django; you'll probably get stuck a few times before you gain the experience to know when not to get stuck. :p
The "customizability" of the admin can be somewhat subjective. I've seen teams bend it to their will but it also requires a pretty good working knowledge of the lower level-details of Models, Forms (and naturally things like ModelForms and FormSets), and templates. I think a lot of the conventional wisdom and best practices hasn't yet surfaced into organized documentation. Be prepared to do a lot of digging around in the source code. The good news is that you'll probably come away with a much deeper understanding of how to take advantage of some of the first-class entities in the framework. The bad news is your boss probably won't be happy that it took you most of a day to change single input on a form.
Recent enhancements have made it easier to place your own views under the admin URL space so you might consider an approach of writing your own views to suit your needs and sprinkling in links in appropriate places within the standard admin pages. I generally advise people who are newer to Django or who are just getting into admin customization to strongly consider just rolling your own administrative views. After all, Django already makes it ridiculously easy to create CRUD style apps and you won't have to feel like you're fighting against a rigid system whenever you want to change presentation or behaviors.
Django Admin is for things where there's no value in doing anything more than the default add/change/delete processing it offers.
Databases are full of lookup and administrative tables. The zip-code to state mapping, for example, that no end-user should see. The log of background batch job executions.
Your app will probably have some tables which are these sort of more-or-less "administrative" -- someone maintains them, but not the large community of users.
Your app will probably have some tables which are for end-users to add/change/delete. You might want to provide extensive customized pages for this activity.
Django grew up in the news business. Writers and editors prepare data (using the admin interface). Customers read the data through customized web pages.
We have administrative staff that use the admin pages. We have customized pages for our customers. We use both.
We provide default admin pages on almost everything to our internal admins. We provide default admin on selected tables to customer-side admins. And we provide carefully crafted application-specific pages for our customers.
I asked a similar question about 6 months ago when I was first starting out in Django.
Is it worth it using the built-in Django admin for a decent sized project?
For that particular application I opted not to use Django admin, and that was a very smart decision in hindsight. Since then, I've generally not used it, but sometimes there are situations when it's great. For me, it really depends on the users. If we are building a custom data-driven app for a client and are working off a feature set provided by them, I would never want to use the Django admin. In those cases, almost certainly they will have changes that could be a real pain to try to get working in the admin. And if it's an evolving project, these changes will become more and more of a hack and you'd probably end up having to start ripping out pieces into non-Django admin parts of the site, at which point there are now two interfaces for doing stuff.
However, if the clients are more of the mindset of accepting the way the app works, then the Django admin would be fine, assuming there's generally a 1:1 correspondence between your tables and the data they're dealing with.
As Brian Luft said, it's really easy to create interfaces for CRUD apps, so if you sense you'll need any customization in the future, it might be easiest just to write your own from the start. You can always keep the django admin around for your own needs as a super-user. That's usually what I do, so I can easily have table-level access to change fields that might not be shown in the normal user admin.
No, I wouldn't compare it to Rails' scaffolding. It's not clear from your question what kind of issues you are running into-- can you provide an example?
There's a lot of customization you can do to the admin by adding custom ModelAdmin classes: hide fields, show additional fields, allow for editing of related-items on the same page or limit/ filter the options that appear in a foreign key field. You can also make things easier for users to find by adding sorting, filters to the front page, search fields. Newer versions of Django also let you create your own custom commands that can be applied to multiple objects at once.
But if the problem isn't with the basic change list and edit form, you can completely customize those by creating model-specific templates and overriding the default admin templates.
No, you can for sure use it for administrating your site, but as Django says; only for trusted users. So if you create a cms, its great. Because (hopefully) the back end users will be trusted users!
Is there an application for django which tracks CRUD for objects inside a project?
If you mean an audit trail for model changes, you could start with AuditTrail. It's a little rough around the edges but I'm not aware of anything else in this area.
I do this by using signals provided by Django.
Check out django-reversion.
It keeps a detailed log of who did what that is viewable from the admin. It also lets you go back and see any older version, and also to restore deleted versions of models. It includes a middleware component to let any model change be logged, even if it wasn't done by the admin tool. It has pretty decent documetnation as well.