The only real reason given in the article is that it can be set up so that the admin page for User will show both the fields in User and UserProfile. This can be replicated with a OneToOneField with a little elbow grease, so unless you’re addicted to showing it in the admin page with … Read more
I think one password field is enough. If you want to check the user’s twice password input is same, do it in the front-end. You can override a create method from serializer like following. from rest_framework import serializers class UserSerializer(serializers.ModelSerializer): password = serializers.CharField(write_only=True) class Meta: model = User fields = (‘first_name’, ‘last_name’, ’email’, ‘mobile’, ‘password’) … Read more
swappable is an “intentionally undocumented” feature which is currently under development / in-test. It’s used to handle “I have a base abstract model which has some foreign-key relationships.” Slightly more detail is available from Django’s ticketing system and github. Because it’s a “stealth alpha” feature, it’s not guaranteed to work (for anything other than User), … Read more
The documentation explains this fully. AbstractUser is a full User model, complete with fields, as an abstract class so that you can inherit from it and add your own profile fields and methods. AbstractBaseUser only contains the authentication functionality, but no actual fields: you have to supply them when you subclass.
The least painful and indeed Django-recommended way of doing this is through a OneToOneField(User) property. Extending the existing User model … If you wish to store information related to User, you can use a one-to-one relationship to a model containing the fields for additional information. This one-to-one model is often called a profile model, as … Read more
I found the way 🙂 Write a __init__ method on the form : def __init__(self, user, *args, **kwargs): self.user = user super(RSVPForm, self).__init__(*args, **kwargs) Change view function, and pass request.user to the form def event_view(request, slug, model_class=Event, form_class=RSVPForm, template_name=”rsvp/event_view.html”): event = get_object_or_404(model_class, slug=slug) if request.POST: form = form_class(request.user, request.POST) if form.is_valid(): guest = form.save() return … Read more
Exactly in Django 1.5 the AUTH_USER_MODEL setting was introduced, allowing using a custom user model with auth system. If you’re writing an app that’s intended to work with projects on Django 1.5 through 1.10 and later, this is the proper way to reference user model (which can now be different from django.contrib.auth.models.User): class UserProfile(models.Model): user … Read more
I finally did like this in my admin.py file : from django.contrib.auth.admin import UserAdmin from django.contrib.auth.models import User UserAdmin.list_display = (’email’, ‘first_name’, ‘last_name’, ‘is_active’, ‘date_joined’, ‘is_staff’) admin.site.unregister(User) admin.site.register(User, UserAdmin)
Check out is_superuser on the User object: {% if request.user.is_superuser %} … <button>…</button> … {% else %} … {% endif %} EDIT: after @mustafa-0x comments The above assumes that you have django.core.context_processors.request included in your TEMPLATE_CONTEXT_PROCESSORS setting which isn’t the default. The default setting for TEMPLATE_CONTEXT_PROCESSORS: TEMPLATE_CONTEXT_PROCESSORS = ( ‘django.contrib.auth.context_processors.auth’, ‘django.core.context_processors.debug’, ‘django.core.context_processors.i18n’, ‘django.core.context_processors.media’, ‘django.core.context_processors.static’, ‘django.core.context_processors.tz’, … Read more
See my answer on a similar question. Django lazy loads request.user so that it can be either User or AnonymousUser depending on the authentication state. It only “wakes up” and returns the appropriate class when an attribute is accessed on it. Unfortunately, __class__ doesn’t count because that’s a primitive class attribute. There’s occasions where you … Read more