A generic system for filtering Django QuerySets based on user selections

Related tags

Djangodjango-filter
Overview

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.

Requirements

  • 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.

Installation

Install using pip:

pip install django-filter

Then add 'django_filters' to your INSTALLED_APPS.

INSTALLED_APPS = [
    ...
    'django_filters',
]

Usage

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.

Support

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

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

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

    Hi,

    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

    http://example.com/api/products?category=clothing,shoes

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

    I've tried with

    http://example.com/api/products?category=clothing&category=shoes

    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.

    https://github.com/alex/django-filter/blob/master/django_filters/filterset.py#L259

    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:

    @property
    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
                else:
                    data = self.form.initial.get(name, self.form[name].field.initial)
                try:
                    val = self.form.fields[name].clean(data)
                except forms.ValidationError:
                    qs = []
                else:
                    qs = filter_.filter(qs, val)
            if self._meta.order_by:
                try:
                    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:
                    pass
            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.

    Example

        # 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

    TODO:

    • [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:

    @property
    def qs(self):
        # ensure that we haven't already cached, as this also implies prefetching
        already_prefetched = hasattr(self, '_qs')
        super().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(
        to_field_name='annotated_field',
        queryset=Model.objects.qs_with_annotated_field(),
    )
    
    Improvement/Feature 
    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" />
        </form>
    
        {% 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" />
        </form>
    {% endif %}
    
    {% render_table object_list %}
    
    {% endblock %}
    

    This is my from my urls.py

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

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

    But then if i do 127.0.0.1:8000?page=1, 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?

    Bug 
    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
            else:
                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:

    FooFilterSet.base_filters['bar'].field
    

    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
Releases(22.1)
  • 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)

    Highlights:

    • 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:

    https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0

    • 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

    Recommended.

    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

    Enjoy

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

Owner
Carlton Gibson
Django Fellow. Core team member on Django REST Framework. Maintainer of Django Filter, Crispy Forms and more.
Carlton Gibson
Django API creation with signed requests utilizing forms for validation.

django-formapi Create JSON API:s with HMAC authentication and Django form-validation. Version compatibility See Travis-CI page for actual test results

5 Monkeys 34 Apr 04, 2022
This is a basic Todo Application API using Django Rest Framework

Todo Application This is a basic Todo Application API using Django Rest Framework. Todo Section - User can View his previously added todo items, creat

Atharva Parkhe 1 Aug 09, 2022
Stream Framework is a Python library, which allows you to build news feed, activity streams and notification systems using Cassandra and/or Redis. The authors of Stream-Framework also provide a cloud service for feed technology:

Stream Framework Activity Streams & Newsfeeds Stream Framework is a Python library which allows you to build activity streams & newsfeeds using Cassan

Thierry Schellenbach 4.7k Jan 02, 2023
A simple demonstration of integrating a sentiment analysis tool in a django project

sentiment-analysis A simple demonstration of integrating a sentiment analysis tool in a django project (watch the video .mp4) To run this project : pi

2 Oct 16, 2021
DRF_commands is a Django package that helps you to create django rest framework endpoints faster using manage.py.

DRF_commands is a Django package that helps you to create django rest framework endpoints faster using manage.py.

Mokrani Yacine 2 Sep 28, 2022
An opinionated Django CMS setup bundled as an Aldryn Addon

Aldryn CMS |PyPI Version| An opinionated django CMS setup bundled as an Aldryn Addon. This package will auto configure django CMS including some extra

Vladimir Bezrukov 1 Nov 12, 2021
With Django Hijack, admins can log in and work on behalf of other users without having to know their credentials.

Django Hijack With Django Hijack, admins can log in and work on behalf of other users without having to know their credentials. Docs 3.x docs are avai

1.2k Jan 05, 2023
Location field and widget for Django. It supports Google Maps, OpenStreetMap and Mapbox

django-location-field Let users pick locations using a map widget and store its latitude and longitude. Stable version: django-location-field==2.1.0 D

Caio Ariede 481 Dec 29, 2022
A simple page with paypal payment and confiramtion in django

django-paypal a simple page with paypal payment and confiramtion in django Youtube Video : Paypal Smart Button : https://developer.paypal.com/demo/che

Mahmoud Ahmed 5 Feb 19, 2022
A simple demonstration of how a django-based website can be set up for local development with microk8s

Django with MicroK8s Start Building Your Project This project provides a Django web app running as a single node Kubernetes cluster in microk8s. It is

Noah Jacobson 19 Oct 22, 2022
A simple Django dev environment setup with docker for demo purposes for GalsenDev community

GalsenDEV Docker Demo This is a basic Django dev environment setup with docker and docker-compose for a GalsenDev Meetup. The main purposes was to mak

3 Jul 03, 2021
This is a simple Todo web application built Django (back-end) and React JS (front-end)

Django REST Todo app This is a simple Todo web application built with Django (back-end) and React JS (front-end). The project enables you to systemati

Maxim Mukhin 5 May 06, 2022
GeoDjango provides geospatial extensions to the Django web dev framework

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. All documentation is in the "docs" directo

Paul Smith 20 Sep 20, 2022
The friendly PIL fork (Python Imaging Library)

Pillow Python Imaging Library (Fork) Pillow is the friendly PIL fork by Alex Clark and Contributors. PIL is the Python Imaging Library by Fredrik Lund

Pillow 10.4k Jan 03, 2023
Django REST Client API

Django REST Client API Client data provider API.

Ulysses Monteiro 1 Nov 08, 2021
Mobile Detect is a lightweight Python package for detecting mobile devices (including tablets).

Django Mobile Detector Mobile Detect is a lightweight Python package for detecting mobile devices (including tablets). It uses the User-Agent string c

Botir 6 Aug 31, 2022
Full featured redis cache backend for Django.

Redis cache backend for Django This is a Jazzband project. By contributing you agree to abide by the Contributor Code of Conduct and follow the guidel

Jazzband 2.5k Jan 03, 2023
django CMS Association 1.6k Jan 06, 2023
PEP-484 stubs for django-rest-framework

pep484 stubs for Django REST framework Mypy stubs for DRF 3.12.x. Supports Python 3.6, 3.7, 3.8 and 3.9. Installation pip install djangorestframework-

TypedDjango 303 Dec 27, 2022
Dashboad Full Stack utilizando o Django.

Dashboard FullStack completa Projeto finalizado | Informações Cadastro de cliente Menu interatico mostrando quantidade de pessoas bloqueadas, liberada

Lucas Silva 1 Dec 15, 2021