Search results

python3-bleach-allowlist-1.0.3-1.lbn36.noarch

Bleach allowlist A curated list of tags, attributes, and styles suitable for filtering user-provided HTML using bleach < it consists of basic set of tags suitable for rendering markdown, and markup intended for printing, as well as a list of all CSS styles. Please send pull requests with improvements or lists of tags and attributes for other purposes (wikis, comments, etc?).Installation pip...

python3-bracex-2.1.1-5.fc36.noarch

Bracex is a brace expanding library (à la Bash) for Python. Brace expanding is used to generate arbitrary strings.

python3-django-currentuser-0.8.0-2.lbn36.noarch

Conveniently store reference to request user on thread/db level. Quickstart Differences to django-cuser Release Notes Contributing Reporting issues/improvements Pull Requests Setting up all Python versions Code of Conduct Quickstart Install django-currentuser: pip install django-currentuser Add it to the middleware classes in your settings.py: MIDDLEWARE = ( ..., 'django_currentuser.middleware.ThreadLocalUserMiddleware', ) Then use it in a project: from django_currentuser.middleware import ( get_current_user, get_current_authenticated_user) from django_currentuser.db.models import CurrentUserField class Foo(models.Model): created_by = CurrentUserField() updated_by = CurrentUserField(on_update=True) Differences to django-cuser Both libraries serve the same purpose, but be aware of these differences (as of django-cuser v.2017.3.16): django-currentusers CurrentUserField stores the reference to the request user at initialization of the mod

python3-django-guardian-2.4.0-2.lbn36.noarch

django-guardian is an implementation of per object permissions [1] on top of Djangos authorization backend Documentation Online documentation is available at https:/django-guardian.readthedocs.io/. Requirements Python 3.5+ A supported version of Django (currently 2.2+) GitHub Actions run tests against Django versions 2.2, 3.0, 3.1, 3.2, and main. Installation To install django-guardian simply run: pip install django-guardian Configuration We need to hook django-guardian into our project. Put guardian into your INSTALLED_APPS at settings module: INSTALLED_APPS = ( ... 'guardian', ) Add extra authorization backend to your settings.py: AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', # default 'guardian.backends.ObjectPermissionBackend', ) Create guardian database tables by running: python manage.py migrate Usage After installation and project hooks we can finally use object permissions with Django. Lets start really quickly: >>> fro

python3-django-guid-3.5.1-1.lbn36.noarch

Django GUID Django GUID attaches a unique correlation ID/request ID to all your log outputs for every request. In other words, all logs connected to a request now has a unique ID attached to it, making debugging simple. Which version of Django GUID you should use depends on your Django version and whether you run ASGI or WSGI servers.

python3-django-import-export-4.1.0-1.lbn36.noarch

django-import-export is a Django application and library for importing and exporting data with included admin integration. Features: support multiple formats (Excel, CSV, JSON, and everything else that tablib support) admin integration for importing preview import changes admin integration for exporting export data respecting admin filters Documentation: https:/django-import-export.readthedocs.io/en/stable/ GitHub: https:/github.com/django-import-export/django-import-export/ Free software: BSD license PyPI: https:/pypi.org/project/django-import-export/ Example app To run the demo app: cd tests ./manage.py makemigrations ./manage.py migrate ./manage.py createsuperuser ./manage.py loaddata category book ./manage.py runserver Contribute If youd like to contribute, simply fork the repository, commit your changes to the develop branch (or branch off of it), and send a pull request. Make sure you add yourself to AUTHORS. As most projects, we try to follow PEP8 as closely as possible

python3-django-lifecycle-1.2.4-2.lbn36.noarch

Django Lifecycle Hooks This project provides a @hook decorator as well as a base model and mixin to add lifecycle hooks to your Django models. Django's built-in approach to offering lifecycle hooks is Signals. However, my team often finds that Signals introduce unnecessary indirection and are at odds with Django's "fat models" approach. Django Lifecycle Hooks supports Python 3.5, 3.6, 3.7, 3.8 and 3.9, Django 2.0.x, 2.1.x, 2.2.x, 3.0.x and 3.1.x. In short, you can write model code like this: from django_lifecycle import LifecycleModel, hook, BEFORE_UPDATE, AFTER_UPDATE class Article(LifecycleModel): contents = models.TextField() updated_at = models.DateTimeField(null=True) status = models.ChoiceField(choices=['draft', 'published']) editor = models.ForeignKey(AuthUser) @hook(BEFORE_UPDATE, when='contents', has_changed=True) def on_content_change(self): self.updated_at = timezone.now() @hook(AFTER_UPDATE, when="status", was="draft", is_now="pub

python3-django-readonly-field-1.1.1-1.lbn36.noarch

Django Readonly Field Make Django model fields readonly. In other words, make it so that Django will read from your fields in your database, but never try to write them. It can be

python3-djangorestframework-queryfields-1.1.0-1.lbn36.noarch

Django REST Framework QueryFields Installation .. code-block:: bash pip install djangorestframework-queryfields Quickstart -Specify your base model serializer like this:.. code-block:: python from rest_framework.serializers import ModelSerializer from drf_queryfields import QueryFieldsMixin class MyModelSerializer(QueryFieldsMixin, ModelSerializer): pass--.. code-block:: bash GET...

python3-drf-access-policy-1.5.0-2.lbn36.noarch

Django REST - Access Policy This project brings a declaritive, organized approach to managing access control in Django REST Framework projects. Each ViewSet or function-based view can be assigned an explicit policy for the exposed resource(s). No more digging through views or seralizers to understand access logic -- it's all in one place in a format that less technical stakeholders can understand. If you're familiar with other declaritive access models, such as AWS' IAM, the syntax will be familiar. In short, you can start expressing your access rules like this: class ArticleAccessPolicy(AccessPolicy): statements = [ { "action": ["list", "retrieve"], "principal": "*", "effect": "allow" }, { "action": ["publish", "unpublish"], "principal": ["group:editor"], "effect": "allow" } ] This project has complete test coverage and the base AccessPolicy class is only ~150 lines of co