The login cookie isn’t being set correctly, because the domain of the cookie\nsent out by Django doesn’t match the domain in your browser. Try setting the\nSESSION_COOKIE_DOMAIN setting to match your domain. For example, if\nyou’re going to “https://www.example.com/admin/” in your browser, set\nSESSION_COOKIE_DOMAIN = 'www.example.com'.
If you’re sure your username and password are correct, make sure your user\naccount has is_active and\nis_staff set to True. The admin site\nonly allows access to users with those two fields both set to True.
The ModelAdmin class provides customization\nhooks that allow you to transform an object as it saved, using details from the\nrequest. By extracting the current user from the request, and customizing the\nsave_model() hook, you can update an\nobject to reflect the user that edited it. See the documentation on\nModelAdmin methods for an example.
The ModelAdmin class also provides customization\nhooks that allow you to control the visibility and editability of objects in\nthe admin. Using the same trick of extracting the user from the request, the\nget_queryset() and\nhas_change_permission() can be used to\ncontrol the visibility and editability of objects in the admin.
See serving the admin files\nin the “How to use Django with mod_wsgi” documentation.
\nDjango won’t bother displaying the filter for a ManyToManyField if there\nare no related objects.
For example, if your list_filter\nincludes sites, and there are no sites in your\ndatabase, it won’t display a “Site” filter. In that case, filtering by site\nwould be meaningless.
Inconsistent row counts may be caused by missing foreign key values or a\nforeign key field incorrectly set to null=False. If you have a record with a\nForeignKey pointing to a nonexistent object and\nthat foreign key is included is\nlist_display, the record will not be\nshown in the admin changelist because the Django model is declaring an\nintegrity constraint that is not implemented at the database level.
You’ve got several options. If you want to piggyback on top of an add/change\nform that Django automatically generates, you can attach arbitrary JavaScript\nmodules to the page via the model’s class Admin js parameter. That parameter is a list of URLs, as strings,\npointing to JavaScript modules that will be included within the admin form via\na <script> tag.
If you want more flexibility than is feasible by tweaking the auto-generated\nforms, feel free to write custom views for the admin. The admin is powered by\nDjango itself, and you can write custom views that hook into the authentication\nsystem, check permissions and do whatever else they need to do.
\nIf you want to customize the look-and-feel of the admin interface, read the\nnext question.
\nWe like it, but if you don’t agree, you can modify the admin site’s\npresentation by editing the CSS stylesheet and/or associated image files. The\nsite is built using semantic HTML and plenty of CSS hooks, so any changes you’d\nlike to make should be possible by editing the stylesheet.
\nThe admin provides a fully-functional experience to the recent versions of\nmodern, web standards compliant browsers. On desktop this means Chrome, Edge,\nFirefox, Opera, Safari, and others.
\nOn mobile and tablet devices, the admin provides a responsive experience for\nweb standards compliant browsers. This includes the major browsers on both\nAndroid and iOS.
\nDepending on feature support, there may be minor stylistic differences\nbetween browsers. These are considered acceptable variations in rendering.
\nThe admin is intended to be compatible with a wide range of assistive\ntechnologies, but there are currently many blockers. The support target is all\nlatest versions of major assistive technologies, including Dragon, JAWS, NVDA,\nOrca, TalkBack, Voice Control, VoiceOver iOS, VoiceOver macOS, Windows Contrast\nThemes, ZoomText, and screen magnifiers.
\n