We Keep Coding

How to Replace Entire default Djnago Admin with custom Admin

I want to replace the default Django Admin templates with a completely revamped bootstrap version. The data in the Dashboard should be populated from the DB. How do I work with templated files ? Which files should be overriden ? In which template tag does HTML code go ?

From django docs on admin:
The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.
It's possible to change templates to do what you want, but that will be very complex - you have to basically rewrite most of the templates, get to know how it is working internally and probably change that too to your own design (after all, you are going to show specific details, like charts, data and so).
You will faster to achieve results if you going to build your own app, that will work exactly like you need without multiple fixes. Does it have to use js frameworks depends entirely on your requirements. Usually they are much more simple for admin backends, that are going to be used by owners, not clients. Anyway, if you don't have experience or knowledge in this, you will probably better off with just plain static django templates.
Django admin is just a same app as the ones you build, so limitations will be the same. Security wise, it doesn't offer much that you can't do yourself - make sure you have permissions set in models/views. Read more about security in django.
From functionality point of view, django admin just comes with CRUD access to your models, which can be done quite quickly. Once you past that, you will have much easier time adding functionality to your own app instead of overriding django admin.
Overall, I advise you to build your app for CMS-like admin panel. JS frameworks is neat, but that require burden of multiple additional tests (with api mocks), constant swapping between adding api / writing a component and much higher time consumption overall.

Design Decision Django Rest Framework - Django as Frontend

I am currently developing my first more complex Web Application and want to ask for directions from more experienced Developers.
First I want to explain the most important requirements.
I want to develop a Web App (no mobile apps or desktop apps) and want to use as much django as possible. Because I am comfortable with the ecosystem right now and don't have that much time to learn something new that is too complex. I am inexperienced in the Javascript World, but I am able to do a little bit of jQuery.
The idea is to have one database and many different Frontends that are branded differently and have different users and administrators. So my current approach is to develop a Backend with Django and use Django Rest Framework to give the specific data to the Frontends via REST. Because I have not that much time to learn a Frontend-Framework I wanted to use another Django instance to use as a Frontend, as I really like the Django Template language. This would mean one Django instance one Frontend, where there would be mainly TemplateViews. The Frontends will be served on different subdomains, while the backend exposes the API Endpoints on the top level domain.
It is not necessary to have a Single Page App. A Normal Website with mainly the normal request/response-cycle is fine.
Do you think this is a possible approach to do things? I am currently thinking about how to use the data in the frontend sites in the best way. As I am familiar with the Django template language I thought about writing a middleware that asks about the user details in every request cycle from the backend. The thought is to use a request.user as normally as possible while getting the data from the backend.
Or is ist better to ask these details via jQuery and Ajax Calls and don't use the django template language very much?
Maybe there is also a way to make different Frontends for the same database without using REST?
Or what would you think about using a database with each frontend, which changes everytime I make a change in the main database in the backend? Although I don't really like this approach due to the possibility of differences in data if I make a mistake.
Hopefully this is not to confusing for you. If there are questions I will answer them happily. Maybe I am also totally on the wrong track. Please don't hesitate to point that out, too.
I thank you very much in advance for your guiding and wish you a nice day.

as per my experience and knowledge, you are almost going towards correct direction.
my recommendation is for making backend rest api Django and django rest framework is the best option however for consuming those api you can look for the angular or react both works very well in terms of consuming API.

Thank you for your input om tripathi.
I think it really does make sense to use the modern js frameworks for consuming a REST API.
I looked a little further into my problem and found multitenancy to fit my requirements perfectly. There are also great plugins and good reads for that use case. Just for others some informations I stumbled upon:
https://djangopackages.org/grids/g/multi-tenancy/
https://www.vinta.com.br/blog/2017/multitenancy-juggling-customer-data-django/
Especially the second link gave me information about different design approaches. For myself I chose to go the way with one database for every Client and then using the site framework from django to seperate data. For the Subdomain resolving I use django-hosts.
Thank you again and have a nice day.

Django : Project consuming data from REST API, How to use external apps in this system?

I have a Django web front-end that consumes data from a REST API backend.
Even the users are made and created on the backend.
My Problem :
How to use 3rd party apps within this system, that heavily depend on django models/ORM ?
Is there something that can provide some bridge between the REST API resources and the ORM?
How can this problem be dealt with ?
Update
DRY principal seems to be failing in this situation.

Probably things have changed since this question has been originally posted. Now there are a couple of interesting related questions on StackOverflow about this topic.
To code yourself a solution as explained in this answer, you can create an external service layer (aka services.py) and write there the logic to access the external resources. Your views will consume this layer, and make the proper actions. There are other questions that provide help on how to pass information from the original request received by the django-view to the external service like this or this
There is also a django app that takes this situation into account as explained in this answer. django-roa uses the Resource Oriented Architecture paradigm to solve this.

I'm facing a similar obstacle with a new ecommerce project.
The project is a front end to a full-fledged store management software (CMS+ERP+CRM). It needs to use the master product database, but have its own entries for product reviews, ratings and so on.
The initial thought was to make a cached copy of the master database. The website will benefit from fast loading times for the cached items, but the implementation is not trivial.
After some considerations, the selected approach was updating the website's DB from the management program. This way the website's copy will always be correct, and most of the implementation doesn't need to worry about REST services (it'll still be used for user registration, shipment tracking etc.)
In your case, where you can't have the service update your own database remotely, you need to come up with a mechanism that allows you to refer to REST recourses like regular models, and that caches them in the background.
Important note: research for a way to make sure the cache is always correct (non-dirty)...

I'm not sure I completely understand your question or requirements. The way I am reading it, you have a primary back-end which is basically a black-box, and you want to use some 3rd-party apps in your project which use the Django ORM.
I am unclear as to why there would be a need for being able to have a two-way synchronization between the two data-stores. The users of your project would be returned data from your primary back-end, and from the project's ORM.
Since you are concerned about saving the "ORM" data in your primary back-end, maybe you would consider creating a Transaction Middleware that would fire any time ORM data gets updated, which could serialize the structure being saved and transmit it to your REST API. This REST API, I assume, is able to accept arbitrary data structures?
You'll probably at least want to use some form of middleware, and maybe a utility module/class to help form the "bridge".

Django Flowchart Model

Is anyone aware of a Django app for designing and storing flowcharts in a database? After searching for variations of "Django flowcharts", I've only found flowcharts of Django's internal design, not anything about authoring or storing flowcharts in a Django webapp.
As asked in a similar question, I've found several impressive Javascript and JQuery based libraries for browser-based flowchart design, but nothing for persisting these server-side.

I wrote an app that stores and controls state machines in Django 1.2:
https://bitbucket.org/canassa/zinaflow
It uses a per-object permission model for controlling the transitions and GenericForeignKeys for attaching the state machine to any model in your application. With the per-object permissions you can assign a Django user for each transition.
Depending on what you need to do, this app might be a overkill for you. But reading the source code can give you some ideias on how to implement an app yourself.

Why couldn't you do it yourself? The behavior and presentation is already implemented in the several truly impressive JavaScript libraries you've referenced, now all that's left to be done is to store the models in the database for your favorite pick you'd like to persist through Django.
There is a library that implements Modified Preorder Tree Traversal on the model level that I'm sure would be of great use to you to store the logical relations between the flowchart elements and other presentation data, such as the coordinates, shape, it's transformations and other visual properties can be easily stored alongside.
I'm sure that if you'd give it some thought you could quickly execute it; hell it's even probable that there are many people who need the same thing, which would make it even more useful if you weren't developing it just for yourself. This seems like a good candidate for an OS Django app.

I am not aware of an existing app that does this, but if you want to start developing your own a good place to start would be exploring the code for GraphModels, a command from the excellent django-command-extensions project. It is a django manage.py extension that creates database diagrams from models using graphviz.

How do you manage your Django applications?

I just wanted to try to build a project with django. Therefore I have a (basic) question on how to manage such a project. Since I cannot find any guidelines or so on how to split a project into applications.
Let's take a kind of SO as an example. Which applications would you use?
I'd say there should be the applications "users" and "questions". But what if there was a topic system with static articles, too. Maybe they also could receive votes.
How to build the apps structure then? One app for "questions", "votes" and "topics" or just one app "content"?
I have no idea what to do. Maybe it's because I know not very much about Django yet, but I'm interested either...

There aren't hard-and-fast rules, but I would say it's better to err on the side of more specialized applications. Ideally an application should handle just one functional concern: i.e. "tagging" or "commenting" or "auth/auth" or "posts." This type of design will also help you reuse available open source applications instead of reinventing the wheel (i.e. Django comes with auth and comments apps, django-tagging or django-taggable can almost certainly do what you need, etc).
Generic foreign keys can help you decouple applications such as tagging or commenting that might be applied to models from several other applications.

You should try and separate the project in as much applications as possible. For most projects an application will not contain more than 5 models. For example a project like SO would have separate applications for UsersProfiles, Questions, Tags (there's a ready one in django for this), etc. If there was a system with static pages that'd be a separate application too (there are ready ones for this purpose). You should also try and make your applications as generic as possible, so you may reuse them in other projects. There's a good presentation on reusable apps.

Just like any set of dependencies... try to find the most useful stand-alone aspects of the project and make those stand-alone apps. Other Django Apps will have higher level functionality, and reuse the parts of the lowest level apps that you have set up.
In my project, I have a calendar app with its own Event object in its models. I also have a carpool database set up, and for the departure time and the duration I use the calendar's Event object right in my RideShare tables. The carpooling database is calendar-aware, and gets all the nice .ics export and calendar views from the calendar app for 'free.'
There are some tricks to getting the Apps reusable, like naming the templates directory: project/app2/templates/app2/index.html. This lets you refer to app2/index.html from any other app, and get the right template. I picked that one up looking at the built-in reusable apps in Django itself. Pinax is a bit of a monster size-wise but it also demonstrates a nice reusable App structure.
If in doubt, forget about reusable apps for now. Put all your messages and polls in one app and get through one rev. You'll discover during the process what steps feel unnecessary, and could be broken out as something stand-alone in the future.

A good question to ask yourself when deciding whether or not to write an app is "could I use this in another project?". If you think you could, then consider what it would take to make the application as independent as possible; How can you reduce the dependancies so that the app doesn't rely on anything specific to a particular project.
Some of the ways you can do this are:
Giving each app its own urls.py
Allowing model types to be passed in as parameters rather than explicitly declaring what models are used in your views. Generic views use this principle.
Make your templates easily overridden by having some sort of template_name parameter passed in your urls.py
Make sure you can do reverse url lookups with your objects and views. This means naming your views in the urls.py and creating get_absolute_url methods on your models.
In some cases like Tagging, GenericForeignKeys can be used to associate a model in your app to any other model, regardless of whether it has ForeignKeys "looking back" at it.

I'll tell you how I am approaching such question: I usually sit with a sheet of paper and draw the boxes (functionalities) and arrows (interdependencies between functionalities). I am sure there are methodologies or other things that could help you, but my approach usually works for me (YMMV, of course).
Knowing what a site is supposed to be is basic, though. ;)