Saravanan666/pypi-org huggingface dataset:
Package: django-perm
Simple class based permissions.InstallationInstall using pip:pip install django-permIn settings.py:# Add to INSTALLED_APPS
'perm',

# Add to AUTHENTICATION_BACKENDS
'perm.backends.ModelPermissionBackend',In your main urls.py, at the end add:# Load django-perm
urlpatterns += patterns('', url('^/perm/', include('perm.urls')))UsageIn your Django app, create a filepermissions.py. Its content might look like this:from perm.decorators import permissions_for
from perm.permissions import ModelPermissions

from .models import Foo


@permissions_for(Foo)
class FooPermissions(ModelPermissions):

    def has_perm_wiggle(self):
        # Let's ask the Foo object
        return self.obj.user_can_wiggle(self.user)

    def get_queryset_perm_change(self):
        # Foo objects can be changed by their owners
        return Foo.objects.filter(user=self.user)QuestionsDo you have a question aboutdjango-perm? Please ask it on StackOverflow.com so others can help out and/or learn. Tag your questiondjango-permif possible.http://stackoverflow.com/Bugs and requestsIf you have found a bug or a request for additional functionality, please use the issue tracker on GitHub.https://github.com/dyve/django-perm/issuesAboutdjango-permis written by Dylan Verheul (dylan@dyve.net).LicenseYou can use this under Apache 2.0. See LICENSE file for details.
Package: django-permalinks
Django PermalinksThis Django App acts as an internal redirector. Most likely use cases are when you have changed your URL scheme for a few pages, but your visitors still have the Old URL - this app can help you redirect the old scheme to the new one.Free URL ShortnerThis Django app also provides a free URL shortner. In order to use it:Use the Django Admin to make a new object of Permalinks.While creating an object, you should see a link which says "Generate a random string". Click it.Click the "Use this string" link when it appears.Enter the long URL in the 'NEW URL' box above.InstallationInstall from PyPI:pip install django-permalinksConfigurationsAddpermalinksto your list ofINSTALLED_APPSin settings.py:INSTALLED_APPS=[...'permalinks',...]Add the permalinks URLs tourls.pyof your base appon the top of the list:urlpatterns=[url('',include('permalinks.urls')),...]Add the permalinks middleware tosettings.pyon the top of the list:MIDDLEWARE=['permalinks.middleware.main.PermalinksMiddleware',...]Runmanage.py migrateto create the required table for the permalinks model.Create yourpermalinksobjects in your Django admin interface.Test your OLD URLs and their responses by visiting them.Enjoy a smooth URL migration!
Package: django-permanent
Django PermanentYet another approach to provide soft (logical) delete or masking (thrashing) django models instead of deleting them physically from db.ModelsTo create a non-deletable model just inherit it fromPermanentModel:classMyModel(PermanentModel):passIt automatically changes delete behaviour to hide objects instead of deleting them:>>>a=MyModel.objects.create(pk=1)>>>b=MyModel.objects.create(pk=2)>>>MyModel.objects.count()2>>>a.delete()>>>MyModel.objects.count()1To recover a deleted object just call itsrestoremethod:>>>a.restore()>>>MyModel.objects.count()2Use theforcekwarg to enforce physical deletion:>>>a.delete(force=True)# Will act as the default django delete>>>MyModel._base_manager.count()0If you need to restore a deleted object instead of re-creating the same one use therestore_on_createattribute:classMyModel(PermanentModel):classPermanent:restore_on_create=TrueIn this caseQuerySetprovides check existence of same attribute objects and restores them if they’ve been deleted, creating new ones if not.ManagersIt changes the default model manager to ignore deleted objects, adding adeleted_objectsmanager to see them instead:>>>MyModel.objects.count()2>>>a.delete()>>>MyModel.objects.count()1>>>MyModel.deleted_objects.count()1>>>MyModel.all_objects.count()2>>>MyModel._base_manager.count()2QuerySetTheQuerySet.deletemethod will act as the default django delete, with one exception - objects of models subclassingPermanentModelwill be marked as deleted; the rest will be deleted physically:>>>MyModel.objects.all().delete()You can still force django query set physical deletion:>>>MyModel.objects.all().delete(force=True)Using custom querysetsInherit your query set fromPermanentQuerySet:classServerFileQuerySet(PermanentQuerySet)passWrapPermanentQuerySetorDeletedQuerySetin you model manager declaration:classMyModel(PermanentModel)objects=MultiPassThroughManager(ServerFileQuerySet,NonDeletedQuerySet)deleted_objects=MultiPassThroughManager(ServerFileQuerySet,DeletedQuerySet)all_objects=MultiPassThroughManager(ServerFileQuerySet,PermanentQuerySet)Methodget_restore_or_createCheck for existence of the object.Restore it if it was deleted.Create a new one, if it was never created.Field nameThe default field named is ‘removed’, but you can override it with the PERMANENT_FIELD variable in settings.py:PERMANENT_FIELD='deleted'RequirementsDjango 1.7+Python 2.7, 3.4+
Package: django-permanent-helpers
Django admin helper classes fordjango-permanentmodels.Authored byBasil Shubin, inspired bydjango-taggit-helpersInstallationFirst install the module, preferably in a virtual environment. It can be installed from PyPI:pipinstalldjango-permanent-helpersSetupFirst make sure the project is configured fordjango-permanent.Then add the following settings:INSTALLED_APPS+=('django_permanent_helpers',)UsagePermanentModelAdminAn abstract ModelAdmin which will include deleted objects in its listing and enable un-deleting feature.fromdjango_permanent_helpers.adminimportPermanentModelAdminclassMyModelAdmin(PermanentModelAdmin):passPermanentModelListFilterFilter records by theirPERMANENT_FIELDvalue, use together withPermanentModelAdminclass.fromdjango_permanent_helpers.adminimportPermanentModelAdmin,PermanentModelListFilterclassMyModelAdmin(PermanentModelAdmin):list_filter=[PermanentModelListFilter]ContributingIf you like this module, forked it, or would like to improve it, please let us know!
Pull requests are welcome too. :-)Licensedjango-permanent-helpersis released under the MIT license.Changes1.0.1 (2021-11-29)Updated ru translation.1.0.0 (2021-11-29)Added Django 3+ support.Dropped Python 2.7 support.Dropped Django 1.10 / 1.11 support.
Package: django-permanent-model
Django PermanentYet another approach to provide soft (logical) delete or masking (thrashing) django models instead of deleting them physically from db.ModelsTo create a non-deletable model just inherit it fromPermanentModel:classMyModel(PermanentModel):passIt automatically changes delete behaviour to hide objects instead of deleting them:>>>a=MyModel.objects.create(pk=1)>>>b=MyModel.objects.create(pk=2)>>>MyModel.objects.count()2>>>a.delete()>>>MyModel.objects.count()1To recover a deleted object just call itsrestoremethod:>>>a.restore()>>>MyModel.objects.count()2Use theforcekwarg to enforce physical deletion:>>>a.delete(force=True)# Will act as the default django delete>>>MyModel._base_manager.count()0If you need to restore a deleted object instead of re-creating the same one use therestore_on_createattribute:classMyModel(PermanentModel):classPermanent:restore_on_create=TrueIn this caseQuerySetprovides check existence of same attribute objects and restores them if they’ve been deleted, creating new ones if not.ManagersIt changes the default model manager to ignore deleted objects, adding adeleted_objectsmanager to see them instead:>>>MyModel.objects.count()2>>>a.delete()>>>MyModel.objects.count()1>>>MyModel.deleted_objects.count()1>>>MyModel.all_objects.count()2>>>MyModel._base_manager.count()2QuerySetTheQuerySet.deletemethod will act as the default django delete, with one exception - objects of models subclassingPermanentModelwill be marked as deleted; the rest will be deleted physically:>>>MyModel.objects.all().delete()You can still force django query set physical deletion:>>>MyModel.objects.all().delete(force=True)Using custom querysetsInherit your query set fromPermanentQuerySet:classServerFileQuerySet(PermanentQuerySet)passWrapPermanentQuerySetorDeletedQuerySetin you model manager declaration:classMyModel(PermanentModel)objects=MultiPassThroughManager(ServerFileQuerySet,NonDeletedQuerySet)deleted_objects=MultiPassThroughManager(ServerFileQuerySet,DeletedQuerySet)all_objects=MultiPassThroughManager(ServerFileQuerySet,PermanentQuerySet)Methodget_restore_or_createCheck for existence of the object.Restore it if it was deleted.Create a new one, if it was never created.Field nameThe default field named is ‘removed’, but you can override it with the PERMANENT_FIELD variable in settings.py:PERMANENT_FIELD='deleted'RequirementsDjango 1.7+Python 2.7, 3.4+
Package: django-perm-filter
Django Perm FilterA simple app that can be included in Django projects which hides app specific permissions from any type of User.  Easily add entire apps, specific permissions or models and it will take care of the rest.  Non-destructive (Doesnotdelete permissions).For example, typically we haveno reason, in any Django project, to expose the following permissions for Users or Groups:AppModelPermissionadminlog entryCan view/add/change/delete log entryauthpermissionCan view/add/change/delete permissioncontenttypescontent typeCan view/add/change/delete content typesessionssessionCan view/add/change/delete sessionFeaturesHide all permissions for an AppHide permissions using app and codename (more granular)Hide models from the Django AdminRequirementsDjango 3 or 4
Python 3QuickstartInstall Django Perm Filter::pipinstalldjango-perm-filterAdd it to yourINSTALLED_APPSat the bottom:INSTALLED_APPS=(...'django_perm_filter',)In yoursettings.pyadd a entry forPERM_FILTER:PERM_FILTER = {
    "HIDE_PERMS": [
        # Use app name only to hide all app related permissions
        "admin",
        "contenttypes",
        "sessions",
        "sites",
        # Use app.codename to get more granular
        "auth.view_permission",
        "auth.add_permission",
        "auth.change_permission",
        "auth.delete_permission",
    ],
    "UNREGISTER_MODELS": [
        "django.contrib.sites.models.Site",
    ],
}OptionalBy defaultdjango_perm_filterwill register a newUserAdminandGroupAdminwhich extenddjango.contrib.auth.admin.UserAdminanddjango.contrib.auth.admin.GroupAdminthat simply adds permissions filtering.  If you would like it to extend your own customUserAdminorGroupAdminclasses, then set the class path in thePERM_FILTERsettings.PERM_FILTER = {
  ...
  "USER_ADMIN": "myapp.users.admin.UserAdmin",
  "GROUP_ADMIN": "myapp.users.admin.GroupAdmin",
}DevelopmentAssumes you havepyenvandmakeinstalled (you should!).make scratchChangelogAll notable changes to this project will be documented in this file.The format is based onKeep a Changelog,
and this project adheres toSemantic Versioning.[0.2.2] - 2023-06-22Update packaging method to usepyproject.toml.[0.2.1] - 2022-09-19Fixed issue ifUserAdminorGroupAdminwere already registered.[0.2.0] - 2022-08-11MergedHIDE_APPSandHIDE_PERMSto make more clear that we're hiding perms only.Added ability to extend your own customUserAdminandGroupAdminif need be.[0.1.1] - 2022-04-19Sorry, pushed copy/pasted changelog on first release![0.1.0] - 2022-04-19First release on PyPI.
Package: django-permissions
Introductiondjango-permissions provides per-object permissions for Django on roles:http://en.wikipedia.org/wiki/Role-based_access_controlCodeThe code can be found on bitbucket:http://github.com/diefenbach/django-permissionsImplementationsIf you want to see a comprehensive implementation of django-permissions take
a look at the CMSLFCChanges1.2.2 (2014-05-10)Fixes caching of roles1.2 (2014-05-10)Adds Django 1.8 supportAdds initial migratinons1.1 (2014-06-26)Fixes deprecation warningRemoves raw SQL statementsCaches calculated roles on user object1.0.3 (2011-04-30)Bugfix releaseBugfix: Removed mutuable parameters; issue #11Changes1.0.2 (2011-04-09)Bugfix releaseBugfix: prevent to add same Users several times to a Role; issue #6 of django-workflowsUpdated Development Status to “5 - Production/Stable”1.0.1 (2011-04-08)Bugfix releaseBugfix: DatabaseErrors with Postgres; issue #5.Bugfix: changed order of passed parameters to has_permission; issue #6Bugfix: removed not needed import of “sets”; issue #81.0 (2010-08-24)First final release1.0 beta 4 (2010-07-23)Added check_permission method to PermissionBaseAdded Unauthorized exception1.0 beta 3 (2010-07-07)Bugfix get_users/get_groups method of class Role; issue #2Bugfix: check for an object before trying to add local role; issue #3Bugfix: registration of permissions for specific content types only1.0 beta 2 (2010-05-17)Added license1.0 beta 1 (2010-05-17)Bugfix has_permission. Using roles=None instead of roles=[].1.0 alpha 4 (2010-04-16)Moved PermissionBase to __init__.py1.0 alpha 3 (2010-03-30)Added roles1.0 alpha 2 (2010-03-22)Added a lot of improvements on several places1.0 alpha 1 (2010-03-11)Initial public release
Package: django-permissions-policy
Set the draft security HTTP headerPermissions-Policy(previouslyFeature-Policy) on your Django app.Work smarter and fasterwith my bookBoost Your Django DXwhich covers many ways to improve your development experience.RequirementsPython 3.8 to 3.12 supported.Django 3.2 to 5.0 supported.InstallationInstall withpip:python-mpipinstalldjango-permissions-policy2. Add the middleware in yourMIDDLEWAREsetting. It’s best to add it
after Django’sSecurityMiddleware, so it adds the header at the same point
in your stack:MIDDLEWARE=[...,"django.middleware.security.SecurityMiddleware","django_permissions_policy.PermissionsPolicyMiddleware",...,]Add thePERMISSIONS_POLICYsetting to your settings, naming at least one
feature. Here’s an example that sets a strict policy to disable many
potentially privacy-invading and annoying features for all scripts:PERMISSIONS_POLICY={"accelerometer":[],"ambient-light-sensor":[],"autoplay":[],"camera":[],"display-capture":[],"document-domain":[],"encrypted-media":[],"fullscreen":[],"geolocation":[],"gyroscope":[],"interest-cohort":[],"magnetometer":[],"microphone":[],"midi":[],"payment":[],"usb":[],}See below for more information on the setting.SettingChange thePERMISSIONS_POLICYsetting to configure the contents of the
header.The setting should be a dictionary laid out with:Keys as the names of browser features - a full list is available on theW3 Spec repository. TheMDN articleis also worth reading.Values as lists of strings, where each string is either an origin, e.g.'https://example.com', or of the special values'self'or'*'. If
there is just one value, no containing list is necessary. To represent no
origins being allowed, use an empty list.Note that in the header, domains are wrapped in double quotes - do not
include these quotes within your Python string, as they will be added by the
middleware.If the keys or values are invalid,ImproperlyConfiguredwill be raised at instantiation time, or when processing a response.
The current feature list is pulled from the JavaScript API withdocument.featurePolicy.allowedFeatures()on Chrome and Firefox.
Browsers don’t always recognize all features, depending on the version and configuration.
You may see warnings in the console for unavailable features in the header - these are normally safe to ignore, since django-permissions-policy already validates that you don’t have completely unknown names.For backwards compatibility with old configuration, the value'none'is
supported in lists, but ignored - it’s preferable to use the empty list
instead. It doesn’t make sense to specify'none'alongside other values.ExamplesDisable geolocation entirely, for the current origin and any iframes:PERMISSIONS_POLICY={"geolocation":[],}Allow autoplay from only the current origin and iframes fromhttps://archive.org:PERMISSIONS_POLICY={"autoplay":["self","https://archive.org"],}Allow autoplay from all origins:PERMISSIONS_POLICY={"autoplay":"*",}
Package: django-permissions-unistra
Introductiondjango-permissions provides per-object permissions for Django on roles:http://en.wikipedia.org/wiki/Role-based_access_controlCodeThe code can be found on bitbucket:http://github.com/diefenbach/django-permissionsImplementationsIf you want to see a comprehensive implementation of django-permissions take
a look at the CMSLFCChanges1.2.2 (2014-05-10)Fixes caching of roles1.2 (2014-05-10)Adds Django 1.8 supportAdds initial migratinons1.1 (2014-06-26)Fixes deprecation warningRemoves raw SQL statementsCaches calculated roles on user object1.0.3 (2011-04-30)Bugfix releaseBugfix: Removed mutuable parameters; issue #11Changes1.0.2 (2011-04-09)Bugfix releaseBugfix: prevent to add same Users several times to a Role; issue #6 of django-workflowsUpdated Development Status to “5 - Production/Stable”1.0.1 (2011-04-08)Bugfix releaseBugfix: DatabaseErrors with Postgres; issue #5.Bugfix: changed order of passed parameters to has_permission; issue #6Bugfix: removed not needed import of “sets”; issue #81.0 (2010-08-24)First final release1.0 beta 4 (2010-07-23)Added check_permission method to PermissionBaseAdded Unauthorized exception1.0 beta 3 (2010-07-07)Bugfix get_users/get_groups method of class Role; issue #2Bugfix: check for an object before trying to add local role; issue #3Bugfix: registration of permissions for specific content types only1.0 beta 2 (2010-05-17)Added license1.0 beta 1 (2010-05-17)Bugfix has_permission. Using roles=None instead of roles=[].1.0 alpha 4 (2010-04-16)Moved PermissionBase to __init__.py1.0 alpha 3 (2010-03-30)Added roles1.0 alpha 2 (2010-03-22)Added a lot of improvements on several places1.0 alpha 1 (2010-03-11)Initial public release
Package: django-permissions-widget
By default, Django’s admin provides a permission widget which looks like this:There are several problems with this widget:the permission description is cut, see the fourth line:
‘admin_test_autocomplete | bar | Can add l’. The administrator will not be
able to read it and might report it as a bug.it proposes permissions foradmin.logentry. The administrator will not
understand what this is about and will ask you about it.it uses a widget which might be new to the administrator and he might ask how
to use it.The purpose of this app is to provide a better widget for selecting permissions
as well as an easy way to replace the default permissions widget in your admin
site. It will look like this:RequirementsMaintained against Python 2.7and Django 1.5Quick InstallInstall the latest release via:pip install django-permissions-widget.Add tosettings.INSTALLED_APPS, afterdjango.contrib.adminwhich we want
to override:‘permissions_widget’,. If you are using custom user modeal as
for Django 1.5 - you have to add‘permissions_widget’,after the app, that
contains your custom user model.That’s it ! You should have a sane permissions widget now.ResourcesDocumentation graciously hostedbyRTFD, read the complete documentation.Mailing list graciously hostedbyGoogle, subscribe to it to be informed about potential
backward compatibility breaks (after 1.0.0 release).Git graciously hostedbyGitHub, report bugs and request pulls.Package graciously hostedbyPyPi, install via pip.
Package: django-perms-provisioner
This package works like the standard Django loaddata / dumpdata commands only
it’s used for creating auth.Group objects with their provided permissions.RequirementsPython >= 3.6Django >= 1.11Installationpipinstalldjango_perms_provisionerThen the only thing left before you can start using theDjango Permissions Provisioneris adding it to you installed apps.INSTALLED_APPS=["django_perms_provisioner",]ConfigurationConfiguration can either be done via providing aYAMLorJSONfile. Your
file needs to have one of the following extensions: .json, .yaml, .yml, and
their approriate contents of course.Examples:---groups:-name:Group Namepermissions:sites:-site.add_site-site.change_sitewagtailadmin:-admin.access_admin{"groups"[{"name":"Group Name","permissions":{"sites":["site.add_site","site.change_site"],"wagtailadmin":["admin.access_admin"]}}]}It is also possible to only create groups this can be done by just leaving out
the permissions.Example:---groups:-name:Group Name-name:Next Group NameUsageTo load permissions from a configuration file./manage.pyloadpermspermissions.yamlOr to dump permissions to a configuration file./manage.pydumpperms>permissions.yaml
Package: django-perms-provisioner-fuxy
This package works like the standard Django loaddata / dumpdata commands only
it’s used for creating auth.Group objects with their provided permissions.RequirementsPython >= 3.6Django >= 1.11Installationpipinstalldjango_perms_provisioner_fuxyThen the only thing left before you can start using theDjango Permissions Provisioneris adding it to you installed apps.INSTALLED_APPS=["django_perms_provisioner_fuxy",]ConfigurationConfiguration can either be done via providing aYAMLorJSONfile. Your
file needs to have one of the following extensions: .json, .yaml, .yml, and
their approriate contents of course.Examples:---groups:-name:Group Namepermissions:sites:-site.add_site-site.change_sitewagtailadmin:-admin.access_admin{"groups"[{"name":"Group Name","permissions":{"sites":["site.add_site","site.change_site"],"wagtailadmin":["admin.access_admin"]}}]}It is also possible to only create groups this can be done by just leaving out
the permissions.Example:---groups:-name:Group Name-name:Next Group NameUsageTo load permissions from a configuration file./manage.pyloadpermspermissions.yamlOr to dump permissions to a configuration file./manage.pydumpperms>permissions.yaml
Package: django-perm-trans
Django permissions translationA simple way to translate the permissions of your Django project.OverviewThis package helps you translate the permissions of your Django project.It's very useful when you have a project with multiple languages or when you use the Django Admin for end users.RequirementsPython 3.8+Django 4.2 (tested)Installationpipinstalldjango-perm-transsettings.pyINSTALLED_APPS=[...'django_perm_trans',...]ConfigurationDJANGO_PERM_TRANS={'separator':'->',# Default: '|' - Separator between words (change | to ->)# 'capitalize_words': True, # Default: False# 'remove_app': True, # Default: False# 'remove_model': True, # Default: False# Custom function to translate the permission and format# ATTENTION: This function overrides the other options# 'custom_function': lambda perm: perm.name, # Default: None}RoadmapApply of capitalize in the words.Separator configurable.Remove app name from the permission.Remove model name from the permission.Custom function to translate the permission.Unit tests.Compatibility tests (Django versions).Use translation from database (configurable in admin).Command to translate the permissions from API.Documentation.LicenseMIT