neulab/docprompting-conala huggingface dataset:
ModelAdmin.get_autocomplete_fields(request)  
The get_autocomplete_fields() method is given the HttpRequest and is expected to return a list or tuple of field names that will be displayed with an autocomplete widget as described above in the ModelAdmin.autocomplete_fields section.
ModelAdmin.get_changeform_initial_data(request)  
A hook for the initial data on admin change forms. By default, fields are given initial values from GET parameters. For instance, ?name=initial_value will set the name field’s initial value to be initial_value. This method should return a dictionary in the form {'fieldname': 'fieldval'}: def get_changeform_initial_data(self, request):
    return {'name': 'custom_initial_value'}
ModelAdmin.get_changelist(request, **kwargs)  
Returns the Changelist class to be used for listing. By default, django.contrib.admin.views.main.ChangeList is used. By inheriting this class you can change the behavior of the listing.
ModelAdmin.get_changelist_form(request, **kwargs)  
Returns a ModelForm class for use in the Formset on the changelist page. To use a custom form, for example: from django import forms

class MyForm(forms.ModelForm):
    pass

class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_form(self, request, **kwargs):
        return MyForm
  Note If you define the Meta.model attribute on a ModelForm, you must also define the Meta.fields attribute (or the Meta.exclude attribute). However, ModelAdmin ignores this value, overriding it with the ModelAdmin.list_editable attribute. The easiest solution is to omit the Meta.model attribute, since ModelAdmin will provide the correct model to use.
ModelAdmin.get_changelist_formset(request, **kwargs)  
Returns a ModelFormSet class for use on the changelist page if list_editable is used. To use a custom formset, for example: from django.forms import BaseModelFormSet

class MyAdminFormSet(BaseModelFormSet):
    pass

class MyModelAdmin(admin.ModelAdmin):
    def get_changelist_formset(self, request, **kwargs):
        kwargs['formset'] = MyAdminFormSet
        return super().get_changelist_formset(request, **kwargs)
ModelAdmin.get_deleted_objects(objs, request)  
A hook for customizing the deletion process of the delete_view() and the “delete selected” action. The objs argument is a homogeneous iterable of objects (a QuerySet or a list of model instances) to be deleted, and request is the HttpRequest. This method must return a 4-tuple of (deleted_objects, model_count, perms_needed, protected). deleted_objects is a list of strings representing all the objects that will be deleted. If there are any related objects to be deleted, the list is nested and includes those related objects. The list is formatted in the template using the unordered_list filter. model_count is a dictionary mapping each model’s verbose_name_plural to the number of objects that will be deleted. perms_needed is a set of verbose_names of the models that the user doesn’t have permission to delete. protected is a list of strings representing of all the protected related objects that can’t be deleted. The list is displayed in the template.
ModelAdmin.get_exclude(request, obj=None)  
The get_exclude method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a list of fields, as described in ModelAdmin.exclude.
ModelAdmin.get_fields(request, obj=None)  
The get_fields method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a list of fields, as described above in the ModelAdmin.fields section.
ModelAdmin.get_fieldsets(request, obj=None)  
The get_fieldsets method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a list of two-tuples, in which each two-tuple represents a <fieldset> on the admin form page, as described above in the ModelAdmin.fieldsets section.
ModelAdmin.get_form(request, obj=None, **kwargs)  
Returns a ModelForm class for use in the admin add and change views, see add_view() and change_view(). The base implementation uses modelform_factory() to subclass form, modified by attributes such as fields and exclude. So, for example, if you wanted to offer additional fields to superusers, you could swap in a different base form like so: class MyModelAdmin(admin.ModelAdmin):
    def get_form(self, request, obj=None, **kwargs):
        if request.user.is_superuser:
            kwargs['form'] = MySuperuserForm
        return super().get_form(request, obj, **kwargs)
 You may also return a custom ModelForm class directly.
ModelAdmin.get_formset_kwargs(request, obj, inline, prefix)  
 New in Django 4.0.  A hook for customizing the keyword arguments passed to the constructor of a formset. For example, to pass request to formset forms: class MyModelAdmin(admin.ModelAdmin):
    def get_formset_kwargs(self, request, obj, inline, prefix):
        return {
            **super().get_formset_kwargs(request, obj, inline, prefix),
            'form_kwargs': {'request': request},
        }
 You can also used it to set initial for formset forms.
ModelAdmin.get_formsets_with_inlines(request, obj=None)  
Yields (FormSet, InlineModelAdmin) pairs for use in admin add and change views. For example if you wanted to display a particular inline only in the change view, you could override get_formsets_with_inlines as follows: class MyModelAdmin(admin.ModelAdmin):
    inlines = [MyInline, SomeOtherInline]

    def get_formsets_with_inlines(self, request, obj=None):
        for inline in self.get_inline_instances(request, obj):
            # hide MyInline in the add view
            if not isinstance(inline, MyInline) or obj is not None:
                yield inline.get_formset(request, obj), inline
ModelAdmin.get_inline_instances(request, obj=None)  
The get_inline_instances method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a list or tuple of InlineModelAdmin objects, as described below in the InlineModelAdmin section. For example, the following would return inlines without the default filtering based on add, change, delete, and view permissions: class MyModelAdmin(admin.ModelAdmin):
    inlines = (MyInline,)

    def get_inline_instances(self, request, obj=None):
        return [inline(self.model, self.admin_site) for inline in self.inlines]
 If you override this method, make sure that the returned inlines are instances of the classes defined in inlines or you might encounter a “Bad Request” error when adding related objects.
ModelAdmin.get_inlines(request, obj)  
The get_inlines method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return an iterable of inlines. You can override this method to dynamically add inlines based on the request or model instance instead of specifying them in ModelAdmin.inlines.
ModelAdmin.get_list_display(request)  
The get_list_display method is given the HttpRequest and is expected to return a list or tuple of field names that will be displayed on the changelist view as described above in the ModelAdmin.list_display section.
ModelAdmin.get_list_display_links(request, list_display)  
The get_list_display_links method is given the HttpRequest and the list or tuple returned by ModelAdmin.get_list_display(). It is expected to return either None or a list or tuple of field names on the changelist that will be linked to the change view, as described in the ModelAdmin.list_display_links section.
ModelAdmin.get_list_filter(request)  
The get_list_filter method is given the HttpRequest and is expected to return the same kind of sequence type as for the list_filter attribute.
ModelAdmin.get_list_select_related(request)  
The get_list_select_related method is given the HttpRequest and should return a boolean or list as ModelAdmin.list_select_related does.
ModelAdmin.get_ordering(request)  
The get_ordering method takes a request as parameter and is expected to return a list or tuple for ordering similar to the ordering attribute. For example: class PersonAdmin(admin.ModelAdmin):

    def get_ordering(self, request):
        if request.user.is_superuser:
            return ['name', 'rank']
        else:
            return ['name']
ModelAdmin.get_paginator(request, queryset, per_page, orphans=0, allow_empty_first_page=True)  
Returns an instance of the paginator to use for this view. By default, instantiates an instance of paginator.
ModelAdmin.get_prepopulated_fields(request, obj=None)  
The get_prepopulated_fields method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a dictionary, as described above in the ModelAdmin.prepopulated_fields section.
ModelAdmin.get_queryset(request)  
The get_queryset method on a ModelAdmin returns a QuerySet of all model instances that can be edited by the admin site. One use case for overriding this method is to show objects owned by the logged-in user: class MyModelAdmin(admin.ModelAdmin):
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        if request.user.is_superuser:
            return qs
        return qs.filter(author=request.user)
ModelAdmin.get_readonly_fields(request, obj=None)  
The get_readonly_fields method is given the HttpRequest and the obj being edited (or None on an add form) and is expected to return a list or tuple of field names that will be displayed as read-only, as described above in the ModelAdmin.readonly_fields section.
ModelAdmin.get_search_fields(request)  
The get_search_fields method is given the HttpRequest and is expected to return the same kind of sequence type as for the search_fields attribute.
ModelAdmin.get_search_results(request, queryset, search_term)  
The get_search_results method modifies the list of objects displayed into those that match the provided search term. It accepts the request, a queryset that applies the current filters, and the user-provided search term. It returns a tuple containing a queryset modified to implement the search, and a boolean indicating if the results may contain duplicates. The default implementation searches the fields named in ModelAdmin.search_fields. This method may be overridden with your own custom search method. For example, you might wish to search by an integer field, or use an external tool such as Solr or Haystack. You must establish if the queryset changes implemented by your search method may introduce duplicates into the results, and return True in the second element of the return value. For example, to search by name and age, you could use: class PersonAdmin(admin.ModelAdmin):
    list_display = ('name', 'age')
    search_fields = ('name',)

    def get_search_results(self, request, queryset, search_term):
        queryset, may_have_duplicates = super().get_search_results(
            request, queryset, search_term,
        )
        try:
            search_term_as_int = int(search_term)
        except ValueError:
            pass
        else:
            queryset |= self.model.objects.filter(age=search_term_as_int)
        return queryset, may_have_duplicates
 This implementation is more efficient than search_fields =
('name', '=age') which results in a string comparison for the numeric field, for example ... OR UPPER("polls_choice"."votes"::text) = UPPER('4') on PostgreSQL.
ModelAdmin.get_sortable_by(request)  
The get_sortable_by() method is passed the HttpRequest and is expected to return a collection (e.g. list, tuple, or set) of field names that will be sortable in the change list page. Its default implementation returns sortable_by if it’s set, otherwise it defers to get_list_display(). For example, to prevent one or more columns from being sortable: class PersonAdmin(admin.ModelAdmin):

    def get_sortable_by(self, request):
        return {*self.get_list_display(request)} - {'rank'}
ModelAdmin.get_urls()  
The get_urls method on a ModelAdmin returns the URLs to be used for that ModelAdmin in the same way as a URLconf. Therefore you can extend them as documented in URL dispatcher: from django.contrib import admin
from django.template.response import TemplateResponse
from django.urls import path

class MyModelAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super().get_urls()
        my_urls = [
            path('my_view/', self.my_view),
        ]
        return my_urls + urls

    def my_view(self, request):
        # ...
        context = dict(
           # Include common variables for rendering the admin template.
           self.admin_site.each_context(request),
           # Anything else you want in the context...
           key=value,
        )
        return TemplateResponse(request, "sometemplate.html", context)
 If you want to use the admin layout, extend from admin/base_site.html: {% extends "admin/base_site.html" %}
{% block content %}
...
{% endblock %}
  Note Notice that the custom patterns are included before the regular admin URLs: the admin URL patterns are very permissive and will match nearly anything, so you’ll usually want to prepend your custom URLs to the built-in ones. In this example, my_view will be accessed at /admin/myapp/mymodel/my_view/ (assuming the admin URLs are included at /admin/.)  However, the self.my_view function registered above suffers from two problems:  It will not perform any permission checks, so it will be accessible to the general public. It will not provide any header details to prevent caching. This means if the page retrieves data from the database, and caching middleware is active, the page could show outdated information.  Since this is usually not what you want, Django provides a convenience wrapper to check permissions and mark the view as non-cacheable. This wrapper is AdminSite.admin_view() (i.e. self.admin_site.admin_view inside a ModelAdmin instance); use it like so: class MyModelAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super().get_urls()
        my_urls = [
            path('my_view/', self.admin_site.admin_view(self.my_view))
        ]
        return my_urls + urls
 Notice the wrapped view in the fifth line above: path('my_view/', self.admin_site.admin_view(self.my_view))
 This wrapping will protect self.my_view from unauthorized access and will apply the django.views.decorators.cache.never_cache() decorator to make sure it is not cached if the cache middleware is active. If the page is cacheable, but you still want the permission check to be performed, you can pass a cacheable=True argument to AdminSite.admin_view(): path('my_view/', self.admin_site.admin_view(self.my_view, cacheable=True))
 ModelAdmin views have model_admin attributes. Other AdminSite views have admin_site attributes.
ModelAdmin.has_add_permission(request)  
Should return True if adding an object is permitted, False otherwise.
ModelAdmin.has_change_permission(request, obj=None)  
Should return True if editing obj is permitted, False otherwise. If obj is None, should return True or False to indicate whether editing of objects of this type is permitted in general (e.g., False will be interpreted as meaning that the current user is not permitted to edit any object of this type).
ModelAdmin.has_delete_permission(request, obj=None)  
Should return True if deleting obj is permitted, False otherwise. If obj is None, should return True or False to indicate whether deleting objects of this type is permitted in general (e.g., False will be interpreted as meaning that the current user is not permitted to delete any object of this type).
ModelAdmin.has_module_permission(request)  
Should return True if displaying the module on the admin index page and accessing the module’s index page is permitted, False otherwise. Uses User.has_module_perms() by default. Overriding it does not restrict access to the view, add, change, or delete views, has_view_permission(), has_add_permission(), has_change_permission(), and has_delete_permission() should be used for that.
ModelAdmin.has_view_permission(request, obj=None)  
Should return True if viewing obj is permitted, False otherwise. If obj is None, should return True or False to indicate whether viewing of objects of this type is permitted in general (e.g., False will be interpreted as meaning that the current user is not permitted to view any object of this type). The default implementation returns True if the user has either the “change” or “view” permission.
ModelAdmin.history_view(request, object_id, extra_context=None)  
Django view for the page that shows the modification history for a given model instance.
ModelAdmin.inlines  
See InlineModelAdmin objects below as well as ModelAdmin.get_formsets_with_inlines().
ModelAdmin.list_display_links  
Use list_display_links to control if and which fields in list_display should be linked to the “change” page for an object. By default, the change list page will link the first column – the first field specified in list_display – to the change page for each item. But list_display_links lets you change this:  Set it to None to get no links at all.  
Set it to a list or tuple of fields (in the same format as list_display) whose columns you want converted to links. You can specify one or many fields. As long as the fields appear in list_display, Django doesn’t care how many (or how few) fields are linked. The only requirement is that if you want to use list_display_links in this fashion, you must define list_display.   In this example, the first_name and last_name fields will be linked on the change list page: class PersonAdmin(admin.ModelAdmin):
    list_display = ('first_name', 'last_name', 'birthday')
    list_display_links = ('first_name', 'last_name')
 In this example, the change list page grid will have no links: class AuditEntryAdmin(admin.ModelAdmin):
    list_display = ('timestamp', 'message')
    list_display_links = None
ModelAdmin.list_editable  
Set list_editable to a list of field names on the model which will allow editing on the change list page. That is, fields listed in list_editable will be displayed as form widgets on the change list page, allowing users to edit and save multiple rows at once.  Note list_editable interacts with a couple of other options in particular ways; you should note the following rules:  Any field in list_editable must also be in list_display. You can’t edit a field that’s not displayed! The same field can’t be listed in both list_editable and list_display_links – a field can’t be both a form and a link.  You’ll get a validation error if either of these rules are broken.
ModelAdmin.list_max_show_all  
Set list_max_show_all to control how many items can appear on a “Show all” admin change list page. The admin will display a “Show all” link on the change list only if the total result count is less than or equal to this setting. By default, this is set to 200.
ModelAdmin.list_per_page  
Set list_per_page to control how many items appear on each paginated admin change list page. By default, this is set to 100.
ModelAdmin.list_select_related  
Set list_select_related to tell Django to use select_related() in retrieving the list of objects on the admin change list page. This can save you a bunch of database queries. The value should be either a boolean, a list or a tuple. Default is False. When value is True, select_related() will always be called. When value is set to False, Django will look at list_display and call select_related() if any ForeignKey is present. If you need more fine-grained control, use a tuple (or list) as value for list_select_related. Empty tuple will prevent Django from calling select_related at all. Any other tuple will be passed directly to select_related as parameters. For example: class ArticleAdmin(admin.ModelAdmin):
    list_select_related = ('author', 'category')
 will call select_related('author', 'category'). If you need to specify a dynamic value based on the request, you can implement a get_list_select_related() method.  Note ModelAdmin ignores this attribute when select_related() was already called on the changelist’s QuerySet.
ModelAdmin.lookup_allowed(lookup, value)  
The objects in the changelist page can be filtered with lookups from the URL’s query string. This is how list_filter works, for example. The lookups are similar to what’s used in QuerySet.filter() (e.g. user__email=user@example.com). Since the lookups in the query string can be manipulated by the user, they must be sanitized to prevent unauthorized data exposure. The lookup_allowed() method is given a lookup path from the query string (e.g. 'user__email') and the corresponding value (e.g. 'user@example.com'), and returns a boolean indicating whether filtering the changelist’s QuerySet using the parameters is permitted. If lookup_allowed() returns False, DisallowedModelAdminLookup (subclass of SuspiciousOperation) is raised. By default, lookup_allowed() allows access to a model’s local fields, field paths used in list_filter (but not paths from get_list_filter()), and lookups required for limit_choices_to to function correctly in raw_id_fields. Override this method to customize the lookups permitted for your ModelAdmin subclass.
ModelAdmin.message_user(request, message, level=messages.INFO, extra_tags='', fail_silently=False)  
Sends a message to the user using the django.contrib.messages backend. See the custom ModelAdmin example. Keyword arguments allow you to change the message level, add extra CSS tags, or fail silently if the contrib.messages framework is not installed. These keyword arguments match those for django.contrib.messages.add_message(), see that function’s documentation for more details. One difference is that the level may be passed as a string label in addition to integer/constant.
ModelAdmin.object_history_template  
Path to a custom template, used by history_view().
ModelAdmin.ordering  
Set ordering to specify how lists of objects should be ordered in the Django admin views. This should be a list or tuple in the same format as a model’s ordering parameter. If this isn’t provided, the Django admin will use the model’s default ordering. If you need to specify a dynamic order (for example depending on user or language) you can implement a get_ordering() method.  Performance considerations with ordering and sorting To ensure a deterministic ordering of results, the changelist adds pk to the ordering if it can’t find a single or unique together set of fields that provide total ordering. For example, if the default ordering is by a non-unique name field, then the changelist is sorted by name and pk. This could perform poorly if you have a lot of rows and don’t have an index on name and pk.
ModelAdmin.paginator  
The paginator class to be used for pagination. By default, django.core.paginator.Paginator is used. If the custom paginator class doesn’t have the same constructor interface as django.core.paginator.Paginator, you will also need to provide an implementation for ModelAdmin.get_paginator().
ModelAdmin.popup_response_template  
Path to a custom template, used by response_add(), response_change(), and response_delete().
ModelAdmin.prepopulated_fields  
Set prepopulated_fields to a dictionary mapping field names to the fields it should prepopulate from: class ArticleAdmin(admin.ModelAdmin):
    prepopulated_fields = {"slug": ("title",)}
 When set, the given fields will use a bit of JavaScript to populate from the fields assigned. The main use for this functionality is to automatically generate the value for SlugField fields from one or more other fields. The generated value is produced by concatenating the values of the source fields, and then by transforming that result into a valid slug (e.g. substituting dashes for spaces and lowercasing ASCII letters). Prepopulated fields aren’t modified by JavaScript after a value has been saved. It’s usually undesired that slugs change (which would cause an object’s URL to change if the slug is used in it). prepopulated_fields doesn’t accept DateTimeField, ForeignKey, OneToOneField, and ManyToManyField fields.  Changed in Django 3.2: In older versions, various English stop words are removed from generated values.
ModelAdmin.preserve_filters  
By default, applied filters are preserved on the list view after creating, editing, or deleting an object. You can have filters cleared by setting this attribute to False.