Best practices? Two independent models for user and admin, Django 1.11.x?

Question

Django

Good time of the year everyone!
After the shock months of supporting various APIs and small sites on Flask/Bottle/Sanic, friends threw a zero project on Django 1.11.x (and literally “zero”: a couple of models were created, settings were divided by environment, initial tests were written, etc.). I only know Djanga with the bearded 1.6 version (later I was sucked into the abyss of Laravel), and I didn’t do anything more serious than “Hello World” on it, but I have a desire to participate in the project (including to get to know Django better) :(
[ lyrics]The theme of the project: a site-blog for owners of dogs, cats, hamsters, etc., with donations for the treatment of animals from shelters in St. Petersburg (yes, it’s time to make a plus in karma, a non-profit project). Accordingly, there should be a personal account where all these transactions are written, because it is planned to connect an online cash desk with OFD (so as not to violate 54-FZ). What for? Well, in general, the law must be observed, and then it will be easier to report to the tax office, they say, it will be easier (raising funds for animals, and not your own profit - everything should be white). [/lyrics]
So, the question itself. Are there any proven and working best practices for implementing a system like this:

1. There is a standard superuser + site moderators (model User, which is out of the box);
   
2. There is a model for users-philanthropists CustomUser(with fields for personal information, phone, etc);
   
3. These two models should not intersect, that is, be inherited or work through proxy(two different database tables);
   
4. There must be both a standard authorization for the model Userand a separate authorization for the model CustomUser;
   
5. Only the model CustomUseris visible in the public part of the site (ala "helped the most this month [...] by sending [...]";
   
6. Must have CustomUsera (private) personal account (outside the admin area), with all transactions and editing;
   

[note] The CustomUser model itself is something like a “donation buyer” (hard, but I can’t explain it in another way). That is, it is planned to make some fixed “bundles” with branded trinkets from partners (such as “1000 rubles = a magnet”, “5000 rubles = a T-shirt”, and so on), so that you can’t donate an arbitrary amount + something left as a keepsake :) [/remark]
Actually, I will be glad to sensible comments and suggestions! Thanks in advance.
PS I understand that no one will give here “ready-made code on a silver platter”, but the algorithm for building such a system is already bread: D

Answer 1

I have seen many attempts to separate users by class in Django projects. I don’t know why everyone immediately chooses a solution that brings nothing but pain in the long run.
The easiest way is to go the standard way: inherit the user from django.contrib.auth.models.AbstractUser, and define the difference between users either by group / permissions, or add a field to your type model is_moderator. It will be many times (an order of magnitude) easier to implement and maintain, will be compatible with all standard Django code and third-party libraries, it will be easy for anyone to enter the project and make changes.
The division into two different models does not give any absolutely advantages, except for a ton of garbage code and smut with the support of this hydra.
TLDR:
1) It's not clear from your question why separation across different classes is required. This is the craziest option for separating permissions, and Django already has separation of user permissions by default
2) Maintained a couple of projects with different classes for different user classes. Believe me, this is just horror, horror in support, and most importantly, that it is not justified by anything.

Answer 2

You make one model, add a role field to it, for example. And then you give access to it.

Answer 3

Dividing users into two tables is not worth it, if only because many libraries will not immediately be able to work with such a system, or you will have to write crutches.
I think it's easiest to use the default model User+ your model Profileconnected via OneToOneField. In it, you can collect all the necessary properties. What prevents the site moderator from being a T-shirt buyer at the same time? Actually nothing.
And now for the checks for is_staff. Look django-braces. You just need to use class based views and include the necessary mixins, and you will forget about these checks: most of them will be performed in mixins, and not in the domain business logic. You can write your own classes for this.