neulab/docprompting-conala huggingface dataset:
ModelAdmin.radio_fields  
By default, Django’s admin uses a select-box interface (<select>) for fields that are ForeignKey or have choices set. If a field is present in radio_fields, Django will use a radio-button interface instead. Assuming group is a ForeignKey on the Person model: class PersonAdmin(admin.ModelAdmin):
    radio_fields = {"group": admin.VERTICAL}
 You have the choice of using HORIZONTAL or VERTICAL from the django.contrib.admin module. Don’t include a field in radio_fields unless it’s a ForeignKey or has choices set.
ModelAdmin.raw_id_fields  
By default, Django’s admin uses a select-box interface (<select>) for fields that are ForeignKey. Sometimes you don’t want to incur the overhead of having to select all the related instances to display in the drop-down. raw_id_fields is a list of fields you would like to change into an Input widget for either a ForeignKey or ManyToManyField: class ArticleAdmin(admin.ModelAdmin):
    raw_id_fields = ("newspaper",)
 The raw_id_fields Input widget should contain a primary key if the field is a ForeignKey or a comma separated list of values if the field is a ManyToManyField. The raw_id_fields widget shows a magnifying glass button next to the field which allows users to search for and select a value:
ModelAdmin.readonly_fields  
By default the admin shows all fields as editable. Any fields in this option (which should be a list or tuple) will display its data as-is and non-editable; they are also excluded from the ModelForm used for creating and editing. Note that when specifying ModelAdmin.fields or ModelAdmin.fieldsets the read-only fields must be present to be shown (they are ignored otherwise). If readonly_fields is used without defining explicit ordering through ModelAdmin.fields or ModelAdmin.fieldsets they will be added last after all editable fields. A read-only field can not only display data from a model’s field, it can also display the output of a model’s method or a method of the ModelAdmin class itself. This is very similar to the way ModelAdmin.list_display behaves. This provides a way to use the admin interface to provide feedback on the status of the objects being edited, for example: from django.contrib import admin
from django.utils.html import format_html_join
from django.utils.safestring import mark_safe

class PersonAdmin(admin.ModelAdmin):
    readonly_fields = ('address_report',)

    # description functions like a model field's verbose_name
    @admin.display(description='Address')
    def address_report(self, instance):
        # assuming get_full_address() returns a list of strings
        # for each line of the address and you want to separate each
        # line by a linebreak
        return format_html_join(
            mark_safe('<br>'),
            '{}',
            ((line,) for line in instance.get_full_address()),
        ) or mark_safe("<span class='errors'>I can't determine this address.</span>")
ModelAdmin.response_add(request, obj, post_url_continue=None)  
Determines the HttpResponse for the add_view() stage. response_add is called after the admin form is submitted and just after the object and all the related instances have been created and saved. You can override it to change the default behavior after the object has been created.
ModelAdmin.response_change(request, obj)  
Determines the HttpResponse for the change_view() stage. response_change is called after the admin form is submitted and just after the object and all the related instances have been saved. You can override it to change the default behavior after the object has been changed.
ModelAdmin.response_delete(request, obj_display, obj_id)  
Determines the HttpResponse for the delete_view() stage. response_delete is called after the object has been deleted. You can override it to change the default behavior after the object has been deleted. obj_display is a string with the name of the deleted object. obj_id is the serialized identifier used to retrieve the object to be deleted.
ModelAdmin.save_as  
Set save_as to enable a “save as new” feature on admin change forms. Normally, objects have three save options: “Save”, “Save and continue editing”, and “Save and add another”. If save_as is True, “Save and add another” will be replaced by a “Save as new” button that creates a new object (with a new ID) rather than updating the existing object. By default, save_as is set to False.
ModelAdmin.save_as_continue  
When save_as=True, the default redirect after saving the new object is to the change view for that object. If you set save_as_continue=False, the redirect will be to the changelist view. By default, save_as_continue is set to True.
ModelAdmin.save_formset(request, form, formset, change)  
The save_formset method is given the HttpRequest, the parent ModelForm instance and a boolean value based on whether it is adding or changing the parent object. For example, to attach request.user to each changed formset model instance: class ArticleAdmin(admin.ModelAdmin):
    def save_formset(self, request, form, formset, change):
        instances = formset.save(commit=False)
        for obj in formset.deleted_objects:
            obj.delete()
        for instance in instances:
            instance.user = request.user
            instance.save()
        formset.save_m2m()
 See also Saving objects in the formset.
ModelAdmin.save_model(request, obj, form, change)  
The save_model method is given the HttpRequest, a model instance, a ModelForm instance, and a boolean value based on whether it is adding or changing the object. Overriding this method allows doing pre- or post-save operations. Call super().save_model() to save the object using Model.save(). For example to attach request.user to the object prior to saving: from django.contrib import admin

class ArticleAdmin(admin.ModelAdmin):
    def save_model(self, request, obj, form, change):
        obj.user = request.user
        super().save_model(request, obj, form, change)
ModelAdmin.save_on_top  
Set save_on_top to add save buttons across the top of your admin change forms. Normally, the save buttons appear only at the bottom of the forms. If you set save_on_top, the buttons will appear both on the top and the bottom. By default, save_on_top is set to False.
ModelAdmin.save_related(request, form, formsets, change)  
The save_related method is given the HttpRequest, the parent ModelForm instance, the list of inline formsets and a boolean value based on whether the parent is being added or changed. Here you can do any pre- or post-save operations for objects related to the parent. Note that at this point the parent object and its form have already been saved.
ModelAdmin.search_fields  
Set search_fields to enable a search box on the admin change list page. This should be set to a list of field names that will be searched whenever somebody submits a search query in that text box. These fields should be some kind of text field, such as CharField or TextField. You can also perform a related lookup on a ForeignKey or ManyToManyField with the lookup API “follow” notation: search_fields = ['foreign_key__related_fieldname']
 For example, if you have a blog entry with an author, the following definition would enable searching blog entries by the email address of the author: search_fields = ['user__email']
 When somebody does a search in the admin search box, Django splits the search query into words and returns all objects that contain each of the words, case-insensitive (using the icontains lookup), where each word must be in at least one of search_fields. For example, if search_fields is set to ['first_name', 'last_name'] and a user searches for john lennon, Django will do the equivalent of this SQL WHERE clause: WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
 The search query can contain quoted phrases with spaces. For example, if a user searches for "john winston" or 'john winston', Django will do the equivalent of this SQL WHERE clause: WHERE (first_name ILIKE '%john winston%' OR last_name ILIKE '%john winston%')
 If you don’t want to use icontains as the lookup, you can use any lookup by appending it the field. For example, you could use exact by setting search_fields to ['first_name__exact']. Some (older) shortcuts for specifying a field lookup are also available. You can prefix a field in search_fields with the following characters and it’s equivalent to adding __<lookup> to the field:   
Prefix Lookup   
^ startswith  
= iexact  
@ search  
None icontains   If you need to customize search you can use ModelAdmin.get_search_results() to provide additional or alternate search behavior.  Changed in Django 3.2: Support for searching against quoted phrases with spaces was added.
ModelAdmin.search_help_text  
 New in Django 4.0.  Set search_help_text to specify a descriptive text for the search box which will be displayed below it.
ModelAdmin.show_full_result_count  
Set show_full_result_count to control whether the full count of objects should be displayed on a filtered admin page (e.g. 99 results (103 total)). If this option is set to False, a text like 99 results (Show all) is displayed instead. The default of show_full_result_count=True generates a query to perform a full count on the table which can be expensive if the table contains a large number of rows.
ModelAdmin.sortable_by  
By default, the change list page allows sorting by all model fields (and callables that use the ordering argument to the display() decorator or have the admin_order_field attribute) specified in list_display. If you want to disable sorting for some columns, set sortable_by to a collection (e.g. list, tuple, or set) of the subset of list_display that you want to be sortable. An empty collection disables sorting for all columns. If you need to specify this list dynamically, implement a get_sortable_by() method instead.
ModelAdmin.view_on_site  
Set view_on_site to control whether or not to display the “View on site” link. This link should bring you to a URL where you can display the saved object. This value can be either a boolean flag or a callable. If True (the default), the object’s get_absolute_url() method will be used to generate the url. If your model has a get_absolute_url() method but you don’t want the “View on site” button to appear, you only need to set view_on_site to False: from django.contrib import admin

class PersonAdmin(admin.ModelAdmin):
    view_on_site = False
 In case it is a callable, it accepts the model instance as a parameter. For example: from django.contrib import admin
from django.urls import reverse

class PersonAdmin(admin.ModelAdmin):
    def view_on_site(self, obj):
        url = reverse('person-detail', kwargs={'slug': obj.slug})
        return 'https://example.com' + url
class models.LogEntry  
The LogEntry class tracks additions, changes, and deletions of objects done through the admin interface.
LogEntry.action_flag  
The type of action logged: ADDITION, CHANGE, DELETION. For example, to get a list of all additions done through the admin: from django.contrib.admin.models import ADDITION, LogEntry

LogEntry.objects.filter(action_flag=ADDITION)
LogEntry.change_message  
The detailed description of the modification. In the case of an edit, for example, the message contains a list of the edited fields. The Django admin site formats this content as a JSON structure, so that get_change_message() can recompose a message translated in the current user language. Custom code might set this as a plain string though. You are advised to use the get_change_message() method to retrieve this value instead of accessing it directly.
LogEntry.get_change_message()  
Formats and translates change_message into the current user language. Messages created before Django 1.10 will always be displayed in the language in which they were logged.
LogEntry.user  
The user (an AUTH_USER_MODEL instance) who performed the action.
register(*models, site=django.contrib.admin.sites.site)  
There is also a decorator for registering your ModelAdmin classes: from django.contrib import admin
from .models import Author

@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    pass
 It’s given one or more model classes to register with the ModelAdmin. If you’re using a custom AdminSite, pass it using the site keyword argument: from django.contrib import admin
from .models import Author, Editor, Reader
from myproject.admin_site import custom_admin_site

@admin.register(Author, Reader, Editor, site=custom_admin_site)
class PersonAdmin(admin.ModelAdmin):
    pass
 You can’t use this decorator if you have to reference your model admin class in its __init__() method, e.g. super(PersonAdmin, self).__init__(*args, **kwargs). You can use super().__init__(*args, **kwargs).
class StackedInline  
The admin interface has the ability to edit models on the same page as a parent model. These are called inlines. Suppose you have these two models: from django.db import models

class Author(models.Model):
   name = models.CharField(max_length=100)

class Book(models.Model):
   author = models.ForeignKey(Author, on_delete=models.CASCADE)
   title = models.CharField(max_length=100)
 You can edit the books authored by an author on the author page. You add inlines to a model by specifying them in a ModelAdmin.inlines: from django.contrib import admin

class BookInline(admin.TabularInline):
    model = Book

class AuthorAdmin(admin.ModelAdmin):
    inlines = [
        BookInline,
    ]
 Django provides two subclasses of InlineModelAdmin and they are:  TabularInline StackedInline  The difference between these two is merely the template used to render them.
staff_member_required(redirect_field_name='next', login_url='admin:login')  
This decorator is used on the admin views that require authorization. A view decorated with this function will have the following behavior:  If the user is logged in, is a staff member (User.is_staff=True), and is active (User.is_active=True), execute the view normally. Otherwise, the request will be redirected to the URL specified by the login_url parameter, with the originally requested path in a query string variable specified by redirect_field_name. For example: /admin/login/?next=/admin/polls/question/3/.  Example usage: from django.contrib.admin.views.decorators import staff_member_required

@staff_member_required
def my_view(request):
    ...
class AppConfig  
Application configuration objects store metadata for an application. Some attributes can be configured in AppConfig subclasses. Others are set by Django and read-only.
AppConfig.default  
 New in Django 3.2.  Set this attribute to False to prevent Django from selecting a configuration class automatically. This is useful when apps.py defines only one AppConfig subclass but you don’t want Django to use it by default. Set this attribute to True to tell Django to select a configuration class automatically. This is useful when apps.py defines more than one AppConfig subclass and you want Django to use one of them by default. By default, this attribute isn’t set.
AppConfig.default_auto_field  
 New in Django 3.2.  The implicit primary key type to add to models within this app. You can use this to keep AutoField as the primary key type for third party applications. By default, this is the value of DEFAULT_AUTO_FIELD.
AppConfig.get_model(model_name, require_ready=True)  
Returns the Model with the given model_name. model_name is case-insensitive. Raises LookupError if no such model exists in this application. Requires the app registry to be fully populated unless the require_ready argument is set to False. require_ready behaves exactly as in apps.get_model().
AppConfig.get_models()  
Returns an iterable of Model classes for this application. Requires the app registry to be fully populated.
AppConfig.label  
Short name for the application, e.g. 'admin' This attribute allows relabeling an application when two applications have conflicting labels. It defaults to the last component of name. It should be a valid Python identifier. It must be unique across a Django project.
AppConfig.models_module  
Module containing the models, e.g. <module 'django.contrib.admin.models'
from 'django/contrib/admin/models.py'>. It may be None if the application doesn’t contain a models module. Note that the database related signals such as pre_migrate and post_migrate are only emitted for applications that have a models module.
AppConfig.module  
Root module for the application, e.g. <module 'django.contrib.admin' from
'django/contrib/admin/__init__.py'>.
AppConfig.name  
Full Python path to the application, e.g. 'django.contrib.admin'. This attribute defines which application the configuration applies to. It must be set in all AppConfig subclasses. It must be unique across a Django project.
AppConfig.path  
Filesystem path to the application directory, e.g. '/usr/lib/pythonX.Y/dist-packages/django/contrib/admin'. In most cases, Django can automatically detect and set this, but you can also provide an explicit override as a class attribute on your AppConfig subclass. In a few situations this is required; for instance if the app package is a namespace package with multiple paths.
AppConfig.ready()  
Subclasses can override this method to perform initialization tasks such as registering signals. It is called as soon as the registry is fully populated. Although you can’t import models at the module-level where AppConfig classes are defined, you can import them in ready(), using either an import statement or get_model(). If you’re registering model signals, you can refer to the sender by its string label instead of using the model class itself. Example: from django.apps import AppConfig
from django.db.models.signals import pre_save


class RockNRollConfig(AppConfig):
    # ...

    def ready(self):
        # importing model classes
        from .models import MyModel  # or...
        MyModel = self.get_model('MyModel')

        # registering signals with the model's string label
        pre_save.connect(receiver, sender='app_label.MyModel')
  Warning Although you can access model classes as described above, avoid interacting with the database in your ready() implementation. This includes model methods that execute queries (save(), delete(), manager methods etc.), and also raw SQL queries via django.db.connection. Your ready() method will run during startup of every management command. For example, even though the test database configuration is separate from the production settings, manage.py test would still execute some queries against your production database!   Note In the usual initialization process, the ready method is only called once by Django. But in some corner cases, particularly in tests which are fiddling with installed applications, ready might be called more than once. In that case, either write idempotent methods, or put a flag on your AppConfig classes to prevent re-running code which should be executed exactly one time.
AppConfig.verbose_name  
Human-readable name for the application, e.g. “Administration”. This attribute defaults to label.title().
apps  
The application registry provides the following public API. Methods that aren’t listed below are considered private and may change without notice.
apps.get_app_config(app_label)  
Returns an AppConfig for the application with the given app_label. Raises LookupError if no such application exists.
apps.get_model(app_label, model_name, require_ready=True)  
Returns the Model with the given app_label and model_name. As a shortcut, this method also accepts a single argument in the form app_label.model_name. model_name is case-insensitive. Raises LookupError if no such application or model exists. Raises ValueError when called with a single argument that doesn’t contain exactly one dot. Requires the app registry to be fully populated unless the require_ready argument is set to False. Setting require_ready to False allows looking up models while the app registry is being populated, specifically during the second phase where it imports models. Then get_model() has the same effect as importing the model. The main use case is to configure model classes with settings, such as AUTH_USER_MODEL. When require_ready is False, get_model() returns a model class that may not be fully functional (reverse accessors may be missing, for example) until the app registry is fully populated. For this reason, it’s best to leave require_ready to the default value of True whenever possible.
apps.is_installed(app_name)  
Checks whether an application with the given name exists in the registry. app_name is the full name of the app, e.g. 'django.contrib.admin'.
apps.ready  
Boolean attribute that is set to True after the registry is fully populated and all AppConfig.ready() methods are called.
authenticate(request=None, **credentials)  
Use authenticate() to verify a set of credentials. It takes credentials as keyword arguments, username and password for the default case, checks them against each authentication backend, and returns a User object if the credentials are valid for a backend. If the credentials aren’t valid for any backend or if a backend raises PermissionDenied, it returns None. For example: from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials
 request is an optional HttpRequest which is passed on the authenticate() method of the authentication backends.  Note This is a low level way to authenticate a set of credentials; for example, it’s used by the RemoteUserMiddleware. Unless you are writing your own authentication system, you probably won’t use this. Rather if you’re looking for a way to login a user, use the LoginView.
class AllowAllUsersModelBackend  
Same as ModelBackend except that it doesn’t reject inactive users because user_can_authenticate() always returns True. When using this backend, you’ll likely want to customize the AuthenticationForm used by the LoginView by overriding the confirm_login_allowed() method as it rejects inactive users.
class AllowAllUsersRemoteUserBackend  
Same as RemoteUserBackend except that it doesn’t reject inactive users because user_can_authenticate always returns True.
class BaseBackend  
A base class that provides default implementations for all required methods. By default, it will reject any user and provide no permissions.  
get_user_permissions(user_obj, obj=None)  
Returns an empty set. 
  
get_group_permissions(user_obj, obj=None)  
Returns an empty set. 
  
get_all_permissions(user_obj, obj=None)  
Uses get_user_permissions() and get_group_permissions() to get the set of permission strings the user_obj has. 
  
has_perm(user_obj, perm, obj=None)  
Uses get_all_permissions() to check if user_obj has the permission string perm.
get_all_permissions(user_obj, obj=None)  
Uses get_user_permissions() and get_group_permissions() to get the set of permission strings the user_obj has.
get_group_permissions(user_obj, obj=None)  
Returns an empty set.
get_user_permissions(user_obj, obj=None)  
Returns an empty set.
has_perm(user_obj, perm, obj=None)  
Uses get_all_permissions() to check if user_obj has the permission string perm.