A generic system for filtering Django QuerySets based on user selections

Related tags

Django django-filter

Django Filter

Django-filter is a reusable Django application allowing users to declaratively add dynamic QuerySet filtering from URL parameters.

Full documentation on read the docs.


  • Python: 3.5, 3.6, 3.7, 3.8, 3.9
  • Django: 2.2, 3.0, 3.1
  • DRF: 3.10+

From Version 2.0 Django Filter is Python 3 only. If you need to support Python 2.7 use the version 1.1 release.


Install using pip:

pip install django-filter

Then add 'django_filters' to your INSTALLED_APPS.



Django-filter can be used for generating interfaces similar to the Django admin's list_filter interface. It has an API very similar to Django's ModelForms. For example, if you had a Product model you could have a filterset for it with the code:

import django_filters

class ProductFilter(django_filters.FilterSet):
    class Meta:
        model = Product
        fields = ['name', 'price', 'manufacturer']

And then in your view you could do:

def product_list(request):
    filter = ProductFilter(request.GET, queryset=Product.objects.all())
    return render(request, 'my_app/template.html', {'filter': filter})

Usage with Django REST Framework

Django-filter provides a custom FilterSet and filter backend for use with Django REST Framework.

To use this adjust your import to use django_filters.rest_framework.FilterSet.

from django_filters import rest_framework as filters

class ProductFilter(filters.FilterSet):
    class Meta:
        model = Product
        fields = ('category', 'in_stock')

For more details see the DRF integration docs.


If you have questions about usage or development you can join the mailing list.

  • filter on a field for a set of values (OR between values)

    filter on a field for a set of values (OR between values)


    i don't know if is the right place to ask, because it's not an issue, just a question.

    I'm using django-filter with Django-REST-Framework to build APIs for my app (great job by the way to both of you!)

    I would like to know if there's a way to get this filter working


    to get all products with category "clothing" OR category "shoes".

    I've tried with


    but as expected it does an AND between the filters and retrieve only the shoes products (i suppose because it's the last filter).

    opened by apelliciari 38
  • If ForeignKey relation has no matches, all results are returned

    If ForeignKey relation has no matches, all results are returned

    When filtering on a foreign key relationship, if a non-existent foreign key is specifed, the qs method in BaseFilterSet receives a ValidationError on line 259.


    This results in the queryset not getting filtered. Shouldn't one expect this case to return 0 results? The reasoning is that if no object matches the foreign key specified, then nothing in the queryset could match, so perhaps return an empty list? Maybe as simple as the following:

    def qs(self):
        if not hasattr(self, '_qs'):
            qs = self.queryset.all()
            for name, filter_ in self.filters.iteritems():
                if self.is_bound:
                    data = self.form[name].data
                    data = self.form.initial.get(name, self.form[name].field.initial)
                    val = self.form.fields[name].clean(data)
                except forms.ValidationError:
                    qs = []
                    qs = filter_.filter(qs, val)
            if self._meta.order_by:
                    value = self.form.fields[self.order_by_field].clean(self.form[self.order_by_field].data)
                    if value:
                        qs = qs.order_by(value)
                except forms.ValidationError:
            self._qs = qs
        return self._qs
    opened by whitews 36
  • Can I pass two query sets?

    Can I pass two query sets?

    Django doesn't let me pass two query sets for filtering.

    In my app, join wasn't working so my final result is generated using two query sets. How can I use two query sets?

    opened by avanibhatnagar 26
  • Adds a third option for strict to raise a Validation Error

    Adds a third option for strict to raise a Validation Error

    I supplied this third option so that Django Rest Framework could return a 400 w/ an appropriate error message.

    If this is to your liking, Alex, I'd be glad to add some unit tests before you merge.

    Note the bizarre constants True, False, "RAISE" -- I did this to support backward compatibility. If you recommend a cleaner way to manage the strict options, let me know. Someone here recommended another boolean option, but then there'd be 4 possible values of the two booleans, only three of which make sense. I think this is more robust.

    opened by wolfe 26
  • Add filter to support 1,2,3 syntax

    Add filter to support 1,2,3 syntax

    Based on discussion from https://github.com/alex/django-filter/issues/137

    Using some of @kmwenja's work from his comment, and some from the original gist I had.

    I considered using similar terms to Django for cleaning/validating the values, but I left it with the function names used in the comment where the cleaning was suggested.

    opened by zoidbergwill 24
  • Bug in get_schema_fields

    Bug in get_schema_fields

    There is an issue at get_schema_fields which prevents nested views to be processed. The problem is that url named argument contains a data that is consumed by queryset is always None since you manually setup a view.


        # some view
        def get_project(self):
           return Project.objects.get(id=self.kwargs.get('project_id'))
        def get_queryset(self):
            project = self.get_project()
            return self.queryset.filter(project=project)

    Root of a problem lays here:

    # django_filters.rest_framework.backends.DjangoFilterBackend#get_schema_fields
    filter_class = self.get_filter_class(view, view.get_queryset()) # <---- :(
    opened by pySilver 23
  • Problem with chained filters and Django ORM

    Problem with chained filters and Django ORM

    As related in the issue #537, the Django ORM generate duplicated INNER JOINS for each .filter() .

    For example: Model.objecs.filter(table1__attr1=value1).filter(table1__attr2=value2)

    The built query is:

    SELECT *
    FROM model_table
    INNER JOIN table1 ON (model_table.id = table1.model_table_id)
    INNER JOIN table1 T5 ON (model_table.id = T5.model_table_id)
    WHERE (table1.attr1=value1 AND T5.attr2=value2)

    But the correct query should be:

    SELECT *
    FROM model_table
    INNER JOIN table1 ON (model_table.id = table1.model_table_id)
    WHERE (table1.attr1=value1 AND table1.attr2=value2)

    The first query may return unwanted or unexpected results.

    Reading the code I found the method def qs(self) in class BaseFilterSet from the file filterset.py and I realized the following workflow:

    1. Get all the model objects using qs = self.queryset.all()
    2. Iterates in the list of declared filters (fields)
    3. In other words, for each field is done the same as qs = self.queryset.filter(field_n=value_n), what causes the described problem.
    4. When the iteration finishes, the queryset (qs) is returned

    The solution that I've developed for the chained filters problem is:

        def qs(self):
            kwargs = {}
            if not hasattr(self, '_qs'):
                if not self.is_bound:
                    self._qs = self.queryset.all()
                    return self._qs
                if not self.form.is_valid():
                    if self.strict == STRICTNESS.RAISE_VALIDATION_ERROR:
                        raise forms.ValidationError(self.form.errors)
                    elif self.strict == STRICTNESS.RETURN_NO_RESULTS:
                        self._qs = self.queryset.none()
                        return self._qs
                    # else STRICTNESS.IGNORE...  ignoring
                # start with all the results and filter from there
                qs = self.queryset.all()
                for name, filter_ in six.iteritems(self.filters):
                    value = self.form.cleaned_data.get(name)
                    if value is not None and value:  # valid & clean data
                        # If all o these conditions are true, it means that
                        # field (filter_) is filtering the queryset
                        # So, it must be added to the filtering dict
                        kwargs[filter_.name] = value
                # The same as qs.filter(filter_.name1=value1, filter_.name2=value2, ...)
                self._qs = qs.filter(**kwargs)
            return self._qs

    Instead of making queries for each field, all of them are stored in a dictionary and the queryset is filtered only one time using this dict.

    What do you think about this solution? Would it break other parts of the code?

    opened by eduardocalil 21
  • Rework validation, add queryset filter method

    Rework validation, add queryset filter method

    This is an evolution of #783. In short, I think the validation/strictness behavior can be improved by moving it out of the FilterSet and into the view code. The current .qs implementation is somewhat difficult to extend, and is a little confusing given that it performs both form validation and queryset filtering.

    Overall changes:

    • Expands the FilterSet API to include the following:
      • .is_valid() - proxies form.is_valid()
      • .errors - proxies form.errors
      • .filter_queryset(qs) - allows users to easily override queryset handling. Cached by .qs
      • .get_form_class() - easier overriding of the form class on a per-instance basis, cached by .form
    • FilterSet-level strictness handling is removed in favor of shifting it to the view layer
      • Generic View has a strict/non-strict attribute (previously, RETURN_NO_RESULTS/IGNORE)
      • DjangoFilterBackend has a raise/non-raise attribute (previously, RAISE_VALIDATION_ERROR/IGNORE)
    • Reworked raw_validation. Error details now include codes. However, these codes are only reachable via exc.get_full_details(), and do not automatically show up in the rendered error response.
    • Other small testing/docs changes

    Additional thoughts:

    • #136 is definitely targeting API use. Raising a forms.ValidationError in the context of a Django view does not make any sense, especially given that none of the provided view code actually handles this exception. Raising an exception has been moved to the backend, where it uses the same utility code to raise the filterset.errors.
    • The 'no results'/'ignore' handling is capable of being handled at the view layer, dependent on a FilterMixin.strict option.
    • Given that views are easily customizable, the FILTERS_STRICTNESS setting is no longer necessary.
    • This slightly changes the Meta.together handling by
      • Allowing multiple 'together' set errors to be displayed (instead of just one).
      • Removes the fields from the form.cleaned_data


    • [x] ~~Determine how much deprecation warning needs to occur (if at all)~~ no deprecation for strictness
    • [x] Add tests for FilterBackend/FilterMixin validation behavior
    • [x] Deprecate strictness in docs (remove relevant docs, add migration)
    • [x] ~~Document new public FilterSet API~~ postponing to docs overhaul

    Additionally, this resolves #740 by extending #738. Inlining the original PR comment:

    I was thinking about #740 a while back, and realized that overriding the FilterSet.qs property is slightly awkward, due to the _qs caching. In the case of #740, Prefetch calls can only occur once, as duplicate calls can raise an exception. If you want to cache the prefetch, a correct solution looks like the following:

    def qs(self):
        # ensure that we haven't already cached, as this also implies prefetching
        already_prefetched = hasattr(self, '_qs')
        if self.is_bound and not already_prefetched:
            self._qs = self._qs.prefetch_related(...)
        return self._qs

    Overriding filter_queyset() is a little more intuitive, as it would only be executed once.

    def filter_queryset(self, queryset):
        qs = super().filter_queryset(queryset)
        return qs.prefetch_related(...)
    opened by rpkilby 20
  • MultipleChoiceFilter: allow to override get_filter_predicate

    MultipleChoiceFilter: allow to override get_filter_predicate

    This allows to use an annotated field easily, without overriding filter altogether:

    class MyMultipleChoiceFilter(django_filters.ModelMultipleChoiceFilter):
        def get_filter_predicate(self, v):
            return {'annotated_field': v.annotated_field}
    foo = MyMultipleChoiceFilter(
    opened by blueyed 20
  • Document how django-filter works with django-pagination

    Document how django-filter works with django-pagination

    They both work well together, it took me a while to fiddle it out. Based on the example in the docs:

    {% block content %}
        <form action="" method="get">
            {{ f.form.as_p }}
            <input type="submit" />
        {% autopaginate f.qs 40 as filter_list %}
        {% for obj in filter_list %}
            {{ obj.name }} - ${{ obj.price }}<br />
        {% endfor %}
        {% paginate %}
    {% endblock %}

    The key is that you have to use pagination's as argument.

    opened by bartTC 20
  • (2.0) FilterView always returning empty QuerySet for unbound FilterSet.

    (2.0) FilterView always returning empty QuerySet for unbound FilterSet.

    I have the a view, AccountList, which is trying to render a django_table2 table. The view's source code:

    class AccountList(SingleTableMixin, FilterView):
        model = Account
        table_class = AccountTable
        template_name = 'accounts/account_list.html'
        context_table_name = 'object_list'
        ordering = ['vps']
        filterset_class = AccountFilter

    This view is currently using this filterset (from django_filters):

    import django_filters
    from accounts.models import Account
    class AccountFilter(django_filters.FilterSet):
        class Meta:
            model = Account
            fields = ['is_suspended', 'is_abandoned']
        is_suspended = django_filters.BooleanFilter(name='is_suspended', initial='False')
        is_abandoned = django_filters.BooleanFilter(name='is_abandoned', initial='False')
        def __init__(self, data=None, *args, **kwargs):
            # if filterset is bound, use initial values as defaults
            if data is not None:
                # get a mutable copy of the QueryDict
                data = data.copy()
                for name, f in self.base_filters.items():
                    initial = f.extra.get('initial')
                    # filter param is either missing or empty, use initial as default
                    if not data.get(name) and initial:
                        data[name] = initial
            super().__init__(data, *args, **kwargs)

    Using this template:

    {% if filter %}
        <form action="" method="get" class="form form-inline">
            {{ filter.form.as_p }}
            <input type="submit" />
    {% endif %}
    {% render_table object_list %}
    {% endblock %}

    This is my from my urls.py

    path('', login_required(AccountList.as_view())),

    When I visit my page,, I see that the filters are not set: [enter image description here]1

    But then if i do, I see the filters are initialized properly:

    [enter image description here]2

    What is causing my filters to not have default value when I don't have page=1 appended to my url?

    opened by vincentwhales 19
  • Using crispy-bootstrap5 with Django-filter and DRF

    Using crispy-bootstrap5 with Django-filter and DRF

    FilterSet in django_filters.rest_framework.filterset.py defines the template pack to use. It looks like bootstrap3 is hardcoded here:

            if compat.is_crispy():
                from crispy_forms.helper import FormHelper
                from crispy_forms.layout import Layout, Submit
                layout_components = list(form.fields.keys()) + [
                    Submit('', _('Submit'), css_class='btn-default'),
                helper = FormHelper()
                helper.form_method = 'GET'
                helper.template_pack = 'bootstrap3'
                helper.layout = Layout(*layout_components)

    This breaks crispy_bootstrap5. Would it not be nicer to do?:

    from django.conf import settings
            if hasattr(settings, 'CRISPY_TEMPLATE_PACK'):
                helper.template_pack = settings.CRISPY_TEMPLATE_PACK
                helper.template_pack = 'bootstrap3'

    Or is there an other place to set the template pack?

    opened by TTycho 0
  • Add custom filter field which is not model field

    Add custom filter field which is not model field

    Hey I was using an old version of django-filter and I added some non-model fields for filtering. for example for user I added a name filter with custom method which concats first_name and last_name and filter both of them but there is no name field in the User model. After I updated to the latest version I faced this error:

    TypeError: 'Meta.fields' must not contain non-model field names: name

    I checked the codes and I found out this error happen here. in the comment it say warn if the field doesn't exist. but it actually raise a TypeError in line 349

    I think it's better to make it a REAL warning instead a ERROR

    opened by mmd-mostafaee 3
  • PR for issue #1525

    PR for issue #1525

    Ref #1525

    Just adding a PR so you can see it failing in CI for convenience.

    Add test to show memoization of form fields may "break" ModelChoiceFilter's queryset kwarg

    opened by shangxiao 0
  • ModelChoiceFilter's queryset kwarg attached to memoized fields - which can cause issues

    ModelChoiceFilter's queryset kwarg attached to memoized fields - which can cause issues

    Given the following filterset (details omitted for brevity):

    def get_bar(request):
        return Bar.objects.filter(…) if request else Bar.objects.none()
    class FooFilterSet(FilterSet):
        bar = ModelChoiceFilter(queryset=get_bar)

    If you happen to access base_filters at module level and (or anywhere without a request) like so:


    Then the bar queryset is evaluated and returns an empty queryset. Subsequently when you process the filtering during an actual request the filtered queryset never gets attached to the form field.

    opened by shangxiao 6
  • 2.4.0(Sep 27, 2020)

    • SECURITY: Added a MaxValueValidator to the form field for NumberFilter. This prevents a potential DoS attack if numbers with very large exponents were subsequently converted to integers.

      The default limit value for the validator is 1e50.

      The new NumberFilter.get_max_validator() allows customising the used validator, and may return None to disable the validation entirely.

    • Added testing against Django 3.1 and Python 3.9.

      In addition tests against Django main development branch are now required to pass.

    Source code(tar.gz)
    Source code(zip)
  • 2.3.0(Jun 5, 2020)

  • 2.2.0(Jul 16, 2019)


    • Added DjangoFilterBackend.get_schema_operation_parameters() for DRF 3.10+ OpenAPI schema generation. (#1086)
    • Added lookup_expr to MultipleChoiceFilter (#1054)
    • Dropped support for EOL Python 3.4
    Source code(tar.gz)
    Source code(zip)
  • 2.1.0(Jan 20, 2019)

    • Fixed a regression in FilterView introduced in 2.0. An empty QuerySet was incorrectly used whenever the FilterSet was unbound (i.e. when there were no GET parameters). The correct, pre-2.0 behaviour is now restored.

      A workaround was to set strict=False on the FilterSet. This is no longer necessary, so you may restore strict behaviour as desired.

    • Added IsoDateTimeFromToRangeFilter. Allows From-To filtering using ISO-8601 formatted dates.

    Source code(tar.gz)
    Source code(zip)
  • 2.0.0(Jul 13, 2018)

    2.0 introduced a number of small changes and tidy-ups. Please see the migration guide:


    • Added testing for Python 3.7 (#944)
    • Improve exception message for invalid filter result (#943)
    • Test QueryDict against CSV filters (#937)
    • Add renderer argument to render() method of BooleanWidget (#923)
    • Fix lookups for reverse relationships (#915)
    • Refactor backend filterset instantiation (#865)
    • Improve view-related attribute name consistency (#867)
    • Fix distinct call for range filters (#855)
    • Fix empty value check for CSV range (#854)
    • Rework DateRangeFilter (#852)
    • Added testing for Django 2.1
    • Rework 'lookup types' handling into LookupChoiceFilter (#851)
    • Add linting and docs builds to CI (#850)
    • Use DRF BooleanFilter for NullBooleanField (#844)
    • Added Brazilian locale (#841)
    • List Django as a dependency in setup.py (#846)
    • Keep coverage reports files off version control. (#924)
    • Update migration docs (#866)
    • Added be, cs and uk translations. Updated de and ru (#861)
    • Slovak translation (#886)
    • Added Django 2.0 support. (#836)
    • Fix warnings build (#829)
    • Add greek translation (#827)
    • Replaced super(ClassName, self) with super() (#821)
    • Fixed doc URL in utils.deprecate(). (#820)
    • Added danish translation to django-filter (#809)
    • Rework validation, add queryset filter method (#788)
    • Fix Schema warnings (#803)
    • Update {Range,LookupType}Widgets to use suffixes (#770)
    • Method signature improvements (#800)
    • Remove more deprecations (#801)
    • Drop python 2, Django<1.11 support (#797)
    • Remove 'Meta.together' option (#791)
    • [2.x] Remove some deprecations (#795)
    Source code(tar.gz)
    Source code(zip)
  • 1.1.0(Oct 19, 2017)

    • Add Deprecations for 2.0 (#792)
    • Improve IsoDateTimeField test clarity (#790)
    • Fix form attr references in tests (#789)
    • Simplify tox config, drop python 3.3 & django 1.8 (#787)
    • Make get_filter_name a classmethod, allowing it to be overriden for each FilterClass (#775)
    • Support active timezone (#750)
    • Docs Typo: django_filters -> filters in docs (#773)
    • Add Polish translations for some messages (#771)
    • Remove support for Django 1.9 (EOL) (#752)
    • Use required attribute from field when getting schema fields (#766)
    • Prevent circular ImportError hiding for rest_framework sub-package (#741)
    • Deprecate 'extra' field attrs on Filter (#734)
    • Add SuffixedMultiWidget (#681)
    • Fix null filtering for *Choice filters (#680)
    • Use isort on imports (#761)
    • Use urlencode from django.utils.http (#760)
    • Remove OrderingFilter.help_text (#757)
    • Update DRF test dependency to 3.6 (#747)

    Version 1.1 Milestone

    Source code(tar.gz)
    Source code(zip)
  • 1.0.4(May 19, 2017)

  • 1.0.3(May 16, 2017)

  • 1.0.2(Mar 24, 2017)

  • 1.0.1(Nov 28, 2016)

    Small patch.

    Assuming DRF is installed, adds rest_framework submodule to the django_filters namespace.

    This allows usage like:

    import django_filters
    class ProductFilter(django_filters.rest_framework.FilterSet):
        # ....

    without requiring a further import.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Nov 17, 2016)

    This release removes all the deprecated code from 0.14 and 0.15 for 1.0 #480.

    Please see the Migration Notes for details of how to migrate.

    Stick with 0.15.3 and fix warnings there if you're not ready to update.

    The release also includes a number of small fixes and documentation updates. See the 1.0 Milestone for full details.

    Source code(tar.gz)
    Source code(zip)
  • 0.15.3(Oct 17, 2016)

  • 0.15.2(Sep 29, 2016)

  • 0.15.1(Sep 28, 2016)

  • 0.15.0(Sep 20, 2016)

    This is a preparatory release for a 1.0. Lots of clean-up, lots of changes, mostly backwards compatible.

    Special thanks to Ryan P Kilby (@rpkilby) for lots of hard work.

    Most changes should raise a Deprecation Warning.

    Note: if you're doing Clever Things™ with the various filter options — filter_overrides etc — you may run into an AttributeError since these are now defined on the metaclass and not on the filter itself. (See the discussion on #459)

    Summary: Highly Recommended, but take a moment to ensure everything still works.

    • Added the DRF backend. #481
    • Deprecated MethodFilter in favour of Filter.method #382
    • Move filter options to metaclass #459
    • Added get_filter_predicate hook. (Allows e.g. filtering on annotated fields) #469
    • Rework Ordering options into a filter #472
    • Hardened all deprecations for 1.0. Please do see the Migration Notes

    See also the Full Milestone Listing and the 0.14.0 to 0.15.0 comparison

    Django Filter 0.15.0 on PyPI

    Source code(tar.gz)
    Source code(zip)
  • 0.14.0(Aug 14, 2016)

  • v0.13(Mar 11, 2016)

  • 0.12.0(Jan 7, 2016)

    Improves compatibility with Django 1.8 and 1.9, adds a JavaScript friendly BooleanWidget and support for custom ORM lookup types.

    Full changes: https://github.com/alex/django-filter/compare/0.11.0...0.12.0


    Source code(tar.gz)
    Source code(zip)
  • 0.11.0(Aug 14, 2015)

    Lots of cool things:

    • Added default filter method lookup for MethodFilter #222
    • Added support for yesterday in daterangefilter #234
    • Created Filter for NumericRange. #236
    • Added Date/time range filters #215
    • Added option to raise with strict #255
    • Added Form Field and Filter to parse ISO-8601 timestamps #264


    Source code(tar.gz)
    Source code(zip)
  • v0.10.0(May 13, 2015)

Carlton Gibson
Django Fellow. Core team member on Django REST Framework. Maintainer of Django Filter, Crispy Forms and more.
Carlton Gibson
Reusable, generic mixins for Django

django-braces Mixins for Django's class-based views. Documentation Read The Docs Installation Install from PyPI with pip: pip install django-braces Bu

Brack3t 1.9k Jan 5, 2023
Generate generic activity streams from the actions on your site. Users can follow any actors' activities for personalized streams.

Django Activity Stream What is Django Activity Stream? Django Activity Stream is a way of creating activities generated by the actions on your site. I

Justin Quick 2.1k Dec 29, 2022
Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project

Django URL Shortener Django URL Shortener is a Django app to to include URL Shortening feature in your Django Project Install this package to your Dja

Rishav Sinha 4 Nov 18, 2021
A Django based shop system

django-SHOP Django-SHOP aims to be a the easy, fun and fast e-commerce counterpart to django-CMS. Here you can find the full documentation for django-

Awesto 2.9k Dec 30, 2022
A handy tool for generating Django-based backend projects without coding. On the other hand, it is a code generator of the Django framework.

Django Sage Painless The django-sage-painless is a valuable package based on Django Web Framework & Django Rest Framework for high-level and rapid web

sageteam 51 Sep 15, 2022
:couple: Multi-user accounts for Django projects

django-organizations Summary Groups and multi-user account management Author Ben Lopatin (http://benlopatin.com / https://wellfire.co) Status Separate

Ben Lopatin 1.1k Jan 1, 2023
User Authentication In Django/Ajax/Jquery

User Authentication In Django/Ajax/Jquery Demo: Authentication System Using Django/Ajax/Jquery Demo: Authentication System Using Django Overview The D

Suman Raj Khanal 10 Mar 26, 2022
✋ Auto logout a user after specific time in Django

django-auto-logout Auto logout a user after specific time in Django. Works with Python ?? ≥ 3.7, Django ?? ≥ 3.0. ✔️ Installation pip install django-a

Georgy Bazhukov 21 Dec 26, 2022
A Django app that allows visitors to interact with your site as a guest user without requiring registration.

django-guest-user A Django app that allows visitors to interact with your site as a guest user without requiring registration. Largely inspired by dja

Julian Wachholz 21 Dec 17, 2022
An example of Django project with basic user functionality and account activation.

Simple Django Login and Registration An example of Django project with basic user functionality. Screenshots Log In Create an account Authorized page

Hussein Sarea 3 Oct 19, 2022
Login System Django

Login-System-Django Login System Using Django Tech Used Django Python Html Run Locally Clone project git clone https://link-to-project Get project for

Nandini Chhajed 6 Dec 12, 2021
A Blog Management System Built with django

Blog Management System Backend use: Django Features Enhanced Ui

Vishal Goswami 1 Dec 6, 2021
AUES Student Management System Developed for laboratory works №9 Purpose using Python (Django).

AUES Student Management System (L M S ) AUES Student Management System Developed for laboratory works №9 Purpose using Python (Django). I've created t

ANAS NABIL 2 Dec 6, 2021
A task management system created using Django 4.0 and Python 3.8 for a hackathon.

Task Management System A task management app for Projects created using Django v4.0 and Python 3.8 for educational purpose. This project was created d

Harsh Agarwal 1 Dec 12, 2021
This repository contains django library management system project.

Library Management System Django ** INSTALLATION** First of all install python on your system. Then run pip install -r requirements.txt to required se

whoisdinanath 1 Dec 26, 2022
Advanced school management system written in Django :)

Advanced school management system written in Django :) ⚙️ Config the project First you should make venv for this project. So in the main root of proje

AminAli Mazarian 72 Dec 5, 2022
A visual indicator of what environment/system you're using in django

A visual indicator of what environment/system you're using in django

Mark Walker 4 Nov 26, 2022
Meta package to combine turbo-django and stimulus-django

Hotwire + Django This repository aims to help you integrate Hotwire with Django ?? Inspiration might be taken from @hotwired/hotwire-rails. We are sti

Hotwire for Django 31 Aug 9, 2022
django-reversion is an extension to the Django web framework that provides version control for model instances.

django-reversion django-reversion is an extension to the Django web framework that provides version control for model instances. Requirements Python 3

Dave Hall 2.8k Jan 2, 2023