Repository files navigation

rules is a tiny but powerful app providing object-level permissions toDjango, without requiring a database. At its core, it is a generic frameworkfor building rule-based systems, similar todecision trees. It can also beused as a standalone library in other contexts and frameworks.

rules has got you covered.rules is:

• Documented,tested,reliable andeasy to use.
• Versatile. Decorate callables to build complex graphs of predicates.Predicates can be any type of callable -- simple functions, lambdas,methods, callable class objects, partial functions, decorated functions,anything really.
• A good Django citizen. Seamless integration with Django views,templates and the Admin for testing for object-level permissions.
• Efficient andsmart. No need to mess around with a database to figureout whether John really wrote that book.
• Simple. Dive in the code. You'll need 10 minutes to figure out how itworks.
• Powerful.rules comes complete with advanced features, such asinvocation context and storage for arbitrary data, skipping evaluation ofpredicates under specific conditions, logging of evaluated predicates and more!

• Requirements
• Upgrading from 2.x
• Upgrading from 1.x
• How to install
  • Configuring Django
• Using Rules
  • Creating predicates
  • Dynamic predicates
  • Setting up rules
  • Combining predicates
• Using Rules with Django
  • Permissions
  • Permissions in models
  • Permissions in views
  • Permissions and rules in templates
  • Permissions in the Admin
  • Permissions in Django Rest Framework
• Advanced features
  • Custom rule sets
  • Invocation context
  • Binding "self"
  • Skipping predicates
  • Logging predicate evaluation
• Best practices
• API Reference
• Licence

rules requires Python 3.8 or newer. The last version to support Python 2.7isrules 2.2. It can optionally integrate with Django, in which caserequires Django 3.2 or newer.

Note: At any given moment in time,rules will maintain support for allcurrently supported Django versions, while dropping support for those versionsthat reached end-of-life in minor releases. See theSupported Versionssection on Django Project website for the current state and timeline.

The are no significant changes betweenrules 2.x and 3.x except droppingsupport for Python 2, so before upgrading to 3.x you just need to make sureyou're running a supported Python 3 version.

• Support for Python 2.6 and 3.3, and Django versions before 1.11 has beendropped.
• TheSkipPredicate exception andskip() method ofPredicate,that were used to signify that a predicate should be skipped, have beenremoved. You may returnNone from your predicate to achieve this.
• The APIs to replace a rule's predicate have been renamed and theirbehaviour changed.replace_rule andreplace_perm functions andreplace_rule method ofRuleSet have been renamed toset_rule,set_perm andRuleSet.set_perm respectively. The old behaviour wasto raise aKeyError if a rule by the given name did not exist. Sinceversion 2.0 this has changed and you can safely useset_* to set arule's predicate without having to ensure the rule exists first.

Using pip:

$ pip install rules

Manually:

$ git clone https://github.com/dfunckt/django-rules.git$cd django-rules$ python setup.py install

Run tests with:

$ ./runtests.sh

You may also want to readBest practices for general advice on how touserules.

Addrules toINSTALLED_APPS:

INSTALLED_APPS= (# ...'rules',)

Add the authentication backend:

AUTHENTICATION_BACKENDS= ('rules.permissions.ObjectPermissionBackend','django.contrib.auth.backends.ModelBackend',)

rules is based on the idea that you maintain a dict-like object that mapsstring keys used as identifiers of some kind, to callables, calledpredicates. This dict-like object is actually an instance ofRuleSet andthe predicates are instances ofPredicate.

Let's ignore rule sets for a moment and go ahead and define a predicate. Theeasiest way is with the@predicate decorator:

>>>@rules.predicate>>>defis_book_author(user,book):...returnbook.author==user...>>>is_book_author<Predicate:is_book_authorobjectat0x10eeaa490>

This predicate will returnTrue if the book's author is the given user,False otherwise.

Predicates can be created from any callable that accepts anything from zero totwo positional arguments:

• fn(obj, target)
• fn(obj)
• fn()

This is their generic form. If seen from the perspective of authorization inDjango, the equivalent signatures are:

• fn(user, obj)
• fn(user)
• fn()

Predicates can do pretty much anything with the given arguments, but mustalways returnTrue if the condition they check is true,Falseotherwise.rules comes with several predefined predicates that you mayread about later on inAPI Reference, that are mostly useful when dealingwithauthorization in Django.

If needed predicates can be created dynamically depending on parameters:

importrulesdefrole_is(role_id):@rules.predicatedefuser_has_role(user):returnuser.role.id==role_idreturnuser_has_rolerules.add_perm("reports.view_report_abc",role_is(12))rules.add_perm("reports.view_report_xyz",role_is(13))

Let's pretend that we want to let authors edit or delete their books, but notbooks written by other authors. So, essentially, what determines whether anauthorcan edit orcan delete a given book iswhether they are itsauthor.

Inrules, such requirements are modelled asrules. Arule is a map ofa unique identifier (eg. "can edit") to a predicate. Rules are groupedtogether into arule set.rules has two predefined rule sets:

• A default rule set storing shared rules.
• Another rule set storing rules that serve as permissions in a Djangocontext.

So, let's define our first couple of rules, adding them to the shared ruleset. We can use theis_book_author predicate we defined earlier:

>>>rules.add_rule('can_edit_book',is_book_author)>>>rules.add_rule('can_delete_book',is_book_author)

Assuming we've got some data, we can now test our rules:

>>>fromdjango.contrib.auth.modelsimportUser>>>frombooks.modelsimportBook>>>guidetodjango=Book.objects.get(isbn='978-1-4302-1936-1')>>>guidetodjango.author<User:adrian>>>>adrian=User.objects.get(username='adrian')>>>rules.test_rule('can_edit_book',adrian,guidetodjango)True>>>rules.test_rule('can_delete_book',adrian,guidetodjango)True

Nice... but not awesome.

Predicates by themselves are not so useful -- not more useful than any otherfunction would be. Predicates, however, can be combined using binary operatorsto create more complex ones. Predicates support the following operators:

• P1 & P2: Returns a new predicate that returnsTrue ifbothpredicates returnTrue, otherwiseFalse. If P1 returnsFalse,P2 will not be evaluated.
• P1 | P2: Returns a new predicate that returnsTrue ifany of thepredicates returnsTrue, otherwiseFalse. If P1 returnsTrue,P2 will not be evaluated.
• P1 ^ P2: Returns a new predicate that returnsTrue if one of thepredicates returnsTrue and the other returnsFalse, otherwiseFalse.
• ~P: Returns a new predicate that returns the negated result of theoriginal predicate.

Suppose the requirement for allowing a user to edit a given book was for themto be either the book's author, or a member of the "editors" group. Allowingusers to delete a book should still be determined by whether the user is thebook's author.

Withrules that's easy to implement. We'd have to define anotherpredicate, that would returnTrue if the given user is a member of the"editors" group,False otherwise. The built-inis_group_member factorywill come in handy:

>>>is_editor=rules.is_group_member('editors')>>>is_editor<Predicate:is_group_member:editorsobjectat0x10eee1350>

We could combine it with theis_book_author predicate to create a new onethat checks for either condition:

>>>is_book_author_or_editor=is_book_author|is_editor>>>is_book_author_or_editor<Predicate:(is_book_author|is_group_member:editors)objectat0x10eee1390>

We can now update ourcan_edit_book rule:

>>>rules.set_rule('can_edit_book',is_book_author_or_editor)>>>rules.test_rule('can_edit_book',adrian,guidetodjango)True>>>rules.test_rule('can_delete_book',adrian,guidetodjango)True

Let's see what happens with another user:

>>>martin=User.objects.get(username='martin')>>>list(martin.groups.values_list('name',flat=True))['editors']>>>rules.test_rule('can_edit_book',martin,guidetodjango)True>>>rules.test_rule('can_delete_book',martin,guidetodjango)False

Awesome.

So far, we've only used the underlying, generic framework for defining andtesting rules. This layer is not at all specific to Django; it may be used inany context. There's actually no import of anything Django-related in thewhole app (except in therules.templatetags module).rules however canintegrate tightly with Django to provide authorization.

rules is able to provide object-level permissions in Django. It comeswith an authorization backend and a couple template tags for use in yourtemplates.

Inrules, permissions are a specialised type of rules. You still definerules by creating and combining predicates. These rules however, must be addedto a permissions-specific rule set that comes withrules so that they canbe picked up by therules authorization backend.

The convention for naming permissions in Django isapp_label.action_object,and we like to adhere to that. Let's add rules for thebooks.change_bookandbooks.delete_book permissions:

>>>rules.add_perm('books.change_book',is_book_author|is_editor)>>>rules.add_perm('books.delete_book',is_book_author)

See the difference in the API?add_perm adds to a permissions-specificrule set, whereasadd_rule adds to a default shared rule set. It'simportant to know however, that these two rule sets are separate, meaning thatadding a rule in one does not make it available to the other.

Let's go ahead and check whetheradrian has change permission to theguidetodjango book:

>>>adrian.has_perm('books.change_book',guidetodjango)False

When you call theUser.has_perm method, Django asks each backend insettings.AUTHENTICATION_BACKENDS whether a user has the given permissionfor the object. When queried for object permissions, Django's defaultauthentication backend always returnsFalse.rules comes with anauthorization backend, that is able to provide object-level permissions bylooking into the permissions-specific rule set.

Let's add therules authorization backend in settings:

AUTHENTICATION_BACKENDS= ('rules.permissions.ObjectPermissionBackend','django.contrib.auth.backends.ModelBackend',)

Now, checking again givesadrian the required permissions:

>>>adrian.has_perm('books.change_book',guidetodjango)True>>>adrian.has_perm('books.delete_book',guidetodjango)True>>>martin.has_perm('books.change_book',guidetodjango)True>>>martin.has_perm('books.delete_book',guidetodjango)False

NOTE: Calling has_perm on a superuser will ALWAYS return True.

NOTE: The features described in this section work on Python 3+ only.

It is common to have a set of permissions for a model, like what Django offers withits default model permissions (such asadd,change etc.). When usingrulesas the permission checking backend, you can declare object-level permissions forany model in a similar way, using a newMeta option.

First, you need to switch your model's base and metaclass to the slightly extendedversions provided inrules.contrib.models. There are several classes and mixinsyou can use, depending on whether you're already using a custom base and/or metaclassfor your models or not. The extensions are very slim and don't affect the models'behavior in any way other than making it register permissions.

• If you're using the stockdjango.db.models.Model as base for your models,simply switch over toRulesModel and you're good to go.

• If you already have a custom base class adding common functionality to your models,addRulesModelMixin to the classes it inherits from and setRulesModelBaseas its metaclass, like so:

  from django.db.models import Modelfrom rules.contrib.models import RulesModelBase, RulesModelMixinclass MyModel(RulesModelMixin, Model, metaclass=RulesModelBase):    ...

• If you're using a custom metaclass for your models, you'll already know how tomake it inherit fromRulesModelBaseMixin yourself.

Then, create your models like so, assuming you're usingRulesModel as basedirectly:

import rulesfrom rules.contrib.models import RulesModelclass Book(RulesModel):    class Meta:        rules_permissions = {            "add": rules.is_staff,            "read": rules.is_authenticated,        }

This would be equivalent to the following calls:

rules.add_perm("app_label.add_book", rules.is_staff)rules.add_perm("app_label.read_book", rules.is_authenticated)

There are methods inRulesModelMixin that you can overwrite in order to customizehow a model's permissions are registered. See the documented source code for detailsif you need this.

Of special interest is theget_perm classmethod ofRulesModelMixin, which canbe used to convert a permission type to the corresponding full permission name. Ifyou need to query for some type of permission on a given model programmatically,this is handy:

if user.has_perm(Book.get_perm("read")):    ...

rules comes with a set of view decorators to help you enforceauthorization in your views.

For function-based views you can use thepermission_required decorator:

fromdjango.shortcutsimportget_object_or_404fromrules.contrib.viewsimportpermission_requiredfromposts.modelsimportPostdefget_post_by_pk(request,post_id):returnget_object_or_404(Post,pk=post_id)@permission_required('posts.change_post',fn=get_post_by_pk)defpost_update(request,post_id):# ...

Usage is straight-forward, but there's one thing in the example above thatstands out and this is theget_post_by_pk function. This function, giventhe current request and all arguments passed to the view, is responsible forfetching and returning the object to check permissions against -- i.e. thePost instance with PK equal to the givenpost_id in the example.This specific use-case is quite common so, to save you some typing,rulescomes with a generic helper function that you can use to do this declaratively.The example below is equivalent to the one above:

fromrules.contrib.viewsimportpermission_required,objectgetterfromposts.modelsimportPost@permission_required('posts.change_post',fn=objectgetter(Post,'post_id'))defpost_update(request,post_id):# ...

For more information on the decorator and helper function, refer to therules.contrib.views module.

Django includes a set of access mixins that you can use in your class-basedviews to enforce authorization.rules extends this framework to provideobject-level permissions via a mixin,PermissionRequiredMixin.

The following example will automatically test for permission against theinstance returned by the view'sget_object method:

fromdjango.views.generic.editimportUpdateViewfromrules.contrib.viewsimportPermissionRequiredMixinfromposts.modelsimportPostclassPostUpdate(PermissionRequiredMixin,UpdateView):model=Postpermission_required='posts.change_post'

You can customise the object either by overridingget_object orget_permission_object.

For more information refer to theDjango documentation and therules.contrib.views module.

If you use the mechanisms provided byrules.contrib.models to register permissionsfor your models as described inPermissions in models, there's another convenientmixin for class-based views available for you.

rules.contrib.views.AutoPermissionRequiredMixin can recognize the type of viewit's used with and check for the corresponding permission automatically.

This example view would, without any further configuration, automatically check forthe"posts.change_post" permission, given that the app label is"posts":

from django.views.generic import UpdateViewfrom rules.contrib.views import AutoPermissionRequiredMixinfrom posts.models import Postclass UpdatePostView(AutoPermissionRequiredMixin, UpdateView):    model = Post

By default, the generic CRUD views fromdjango.views.generic are mapped to thenative Django permission types (add,change,delete andview). However,the pre-defined mappings can be extended, changed or replaced altogether whensubclassingAutoPermissionRequiredMixin. See the fully documented source codefor details on how to do that properly.

rules comes with two template tags to allow you to test for rules andpermissions in templates.

Addrules to yourINSTALLED_APPS:

INSTALLED_APPS= (# ...'rules',)

Then, in your template:

{% load rules %}{% has_perm 'books.change_book' author book as can_edit_book %}{% if can_edit_book %}    ...{% endif %}{% test_rule 'has_super_feature' user as has_super_feature %}{% if has_super_feature %}    ...{% endif %}

If you've setuprules to be used with permissions in Django, you're almostset to also userules to authorize any add/change/delete actions in theAdmin. The Admin asks forfour different permissions, depending on action:

• <app_label>.add_<modelname>
• <app_label>.view_<modelname>
• <app_label>.change_<modelname>
• <app_label>.delete_<modelname>
• <app_label>

Note: view permission is new in Django v2.1 and should not be added in versions before that.

The first four are obvious. The fifth is the required permission for an appto be displayed in the Admin's "dashboard". Overriding it does not restrict access to the add,change or delete views. Here's some rules for our imaginarybooks app as an example:

>>>rules.add_perm('books',rules.always_allow)>>>rules.add_perm('books.add_book',is_staff)>>>rules.add_perm('books.view_book',is_staff|has_secret_access_code)>>>rules.add_perm('books.change_book',is_staff)>>>rules.add_perm('books.delete_book',is_staff)

Django Admin does not support object-permissions, in the sense that it willnever ask for permission to perform an actionon an object, only whether auser is allowed to act on (any) instances of a model.

If you'd like to tell Django whether a user has permissions on a specificobject, you'd have to override the following methods of a model'sModelAdmin:

• has_view_permission(user, obj=None)
• has_change_permission(user, obj=None)
• has_delete_permission(user, obj=None)

rules comes with a customModelAdmin subclass,rules.contrib.admin.ObjectPermissionsModelAdmin, that overrides thesemethods to pass on the edited model instance to the authorization backends,thus enabling permissions per object in the Admin:

# books/admin.pyfromdjango.contribimportadminfromrules.contrib.adminimportObjectPermissionsModelAdminfrom .modelsimportBookclassBookAdmin(ObjectPermissionsModelAdmin):passadmin.site.register(Book,BookAdmin)

Now this allows you to specify permissions like this:

>>>rules.add_perm('books',rules.always_allow)>>>rules.add_perm('books.add_book',has_author_profile)>>>rules.add_perm('books.change_book',is_book_author_or_editor)>>>rules.add_perm('books.delete_book',is_book_author)

To preserve backwards compatibility, Django will ask for eitherview orchange permission. For maximum flexibility,rules behaves subtlydifferent:rules will ask for the change permission if and only if no ruleexists for the view permission.

Similar torules.contrib.views.AutoPermissionRequiredMixin, there is arules.contrib.rest_framework.AutoPermissionViewSetMixin for viewsets in DjangoRest Framework. The difference is that it doesn't derive permission from the typeof view but from the API action (create,retrieve etc.) that's tried to beperformed. Of course, it also requires you to declare your models as described inPermissions in models.

Here is a possibleModelViewSet for thePost model with fully automated CRUDpermission checking:

from rest_framework.serializers import ModelSerializerfrom rest_framework.viewsets import ModelViewSetfrom rules.contrib.rest_framework import AutoPermissionViewSetMixinfrom posts.models import Postclass PostSerializer(ModelSerializer):    class Meta:        model = Post        fields = "__all__"class PostViewSet(AutoPermissionViewSetMixin, ModelViewSet):    queryset = Post.objects.all()    serializer_class = PostSerializer

By default, the CRUD actions ofModelViewSet are mapped to the nativeDjango permission types (add,change,delete andview). Thelistaction has no permission checking enabled. However, the pre-defined mappingscan be extended, changed or replaced altogether when using (or subclassing)AutoPermissionViewSetMixin. Custom API actions defined via the@actiondecorator may then be mapped as well. See the fully documented source code fordetails on how to properly customize the default behavior.

You may create as many rule sets as you need:

>>>features=rules.RuleSet()

And manipulate them by adding, removing, querying and testing rules:

>>>features.rule_exists('has_super_feature')False>>>is_special_user=rules.is_group_member('special')>>>features.add_rule('has_super_feature',is_special_user)>>>'has_super_feature'infeaturesTrue>>>features['has_super_feature']<Predicate:is_group_member:specialobjectat0x10eeaa500>>>>features.test_rule('has_super_feature',adrian)True>>>features.remove_rule('has_super_feature')

Note however that custom rule sets arenot available in Django templates --you need to provide integration yourself.

A new context is created as a result of invokingPredicate.test() and isonly valid for the duration of the invocation. A context is a simpledictthat you can use to store arbitrary data, (eg. caching computed values,setting flags, etc.), that can be used by predicates later on in the chain.Inside a predicate function it can be used like so:

>>>@predicate...defmypred(a,b):...value=compute_expensive_value(a)...mypred.context['value']=value...returnTrue

Other predicates can later use stored values:

>>>@predicate...defmyotherpred(a,b):...value=myotherpred.context.get('value')...ifvalueisnotNone:...returndo_something_with_value(value)...else:...returndo_something_without_value()

Predicate.context provides a singleargs attribute that contains thearguments as given totest() at the beginning of the invocation.

In a predicate's function body, you can refer to the predicate instance itselfby its name, eg.is_book_author. Passingbind=True as a keywordargument to thepredicate decorator will let you refer to the predicatewithself, which is more convenient. Bindingself is just syntacticsugar. As a matter of fact, the following two are equivalent:

>>>@predicate...defis_book_author(user,book):...ifis_book_author.context.args:...returnuser==book.author...returnFalse>>> @predicate(bind=True)...defis_book_author(self,user,book):...ifself.context.args:...returnuser==book.author...returnFalse

You may skip evaluation by returningNone from your predicate:

>>>@predicate(bind=True)...defis_book_author(self,user,book):...iflen(self.context.args)>1:...returnuser==book.author...else:...returnNone

ReturningNone signifies that the predicate need not be evaluated, thusleaving the predicate result up to that point unchanged.

rules can optionally be configured to log debug information as rules areevaluated to help with debugging your predicates. Messages are sent at theDEBUG level to the'rules' logger. The followingdictConfig configuresa console logger (place this in your project's settings.py if you're usingrules with Django):

LOGGING= {'version':1,'disable_existing_loggers':False,'handlers': {'console': {'level':'DEBUG','class':'logging.StreamHandler',        },    },'loggers': {'rules': {'handlers': ['console'],'level':'DEBUG','propagate':True,        },    },}

When this logger is active each individual predicate will have a log messageprinted when it is evaluated.

Before you can test for rules, these rules must be registered with a rule set,and for this to happen the modules containing your rule definitions must beimported.

For complex projects with several predicates and rules, it may not bepractical to define all your predicates and rules inside one module. It mightbe best to split them among any sub-components of your project. In a Djangocontext, these sub-components could be the apps for your project.

On the other hand, because importing predicates from all over the place inorder to define rules can lead to circular imports and broken hearts, it'sbest to further split predicates and rules in different modules.

rules may optionally be configured to autodiscoverrules.py modules inyour apps and import them at startup. To haverules do so, just edit yourINSTALLED_APPS setting:

INSTALLED_APPS= (# replace 'rules' with:'rules.apps.AutodiscoverRulesConfig',)

Note: On Python 2, you must also add the following to the top of yourrules.py file, or you'll get import errors trying to importrulesitself:

from __future__importabsolute_import

The core APIs are accessible from the rootrules module. Django-specificfunctionality for the Admin and views is available fromrules.contrib.

You createPredicate instances by passing in a callable:

>>>defis_book_author(user,book):...returnbook.author==user...>>>pred=Predicate(is_book_author)>>>pred<Predicate:is_book_authorobjectat0x10eeaa490>

You may optionally provide a different name for the predicate that is usedwhen inspecting it:

>>>pred=Predicate(is_book_author,name='another_name')>>>pred<Predicate:another_nameobjectat0x10eeaa490>

Also, you may optionally providebind=True in order to be able to accessthe predicate instance withself:

>>>defis_book_author(self,user,book):...ifself.context.args:...returnuser==book.author...returnFalse...>>>pred=Predicate(is_book_author,bind=True)>>>pred<Predicate:is_book_authorobjectat0x10eeaa490>

test(obj=None, target=None)

Returns the result of calling the passed in callable with zero, one or twopositional arguments, depending on how many it accepts.

RuleSet extends Python's built-indict type. Therefore, you may createand use a rule set any way you'd use a dict.

add_rule(name, predicate)

Adds a predicate to the rule set, assigning it to the given rule name.RaisesKeyError if another rule with that name already exists.

set_rule(name, predicate)

Set the rule with the given name, regardless if one already exists.

remove_rule(name)

Remove the rule with the given name. RaisesKeyError if a rule withthat name does not exist.

rule_exists(name)

ReturnsTrue if a rule with the given name exists,False otherwise.

test_rule(name, obj=None, target=None)

Returns the result of callingpredicate.test(obj, target) wherepredicate is the predicate for the rule with the given name. ReturnsFalse if a rule with the given name does not exist.

@predicate

Decorator that creates a predicate out of any callable:

>>>@predicate...defis_book_author(user,book):...returnbook.author==user...>>>is_book_author<Predicate:is_book_authorobjectat0x10eeaa490>

Customising the predicate name:

>>>@predicate(name='another_name')...defis_book_author(user,book):...returnbook.author==user...>>>is_book_author<Predicate:another_nameobjectat0x10eeaa490>

Bindingself:

>>>@predicate(bind=True)...defis_book_author(self,user,book):...if'user_has_special_flag'inself.context:...returnself.context['user_has_special_flag']...returnbook.author==user

always_allow(),always_true()

Always returnsTrue.

always_deny(),always_false()

Always returnsFalse.

is_authenticated(user)

Returns the result of callinguser.is_authenticated(). ReturnsFalse if the given user does not have anis_authenticated method.

is_superuser(user)

Returns the result of callinguser.is_superuser. ReturnsFalseif the given user does not have anis_superuser property.

is_staff(user)

Returns the result of callinguser.is_staff. ReturnsFalse if thegiven user does not have anis_staff property.

is_active(user)

Returns the result of callinguser.is_active. ReturnsFalse if thegiven user does not have anis_active property.

is_group_member(*groups)

Factory that creates a new predicate that returnsTrue if the givenuser is a member ofall the given groups,False otherwise.

add_rule(name, predicate)

Adds a rule to the shared rule set. SeeRuleSet.add_rule.

set_rule(name, predicate)

Set the rule with the given name from the shared rule set. SeeRuleSet.set_rule.

remove_rule(name)

Remove a rule from the shared rule set. SeeRuleSet.remove_rule.

rule_exists(name)

Returns whether a rule exists in the shared rule set. SeeRuleSet.rule_exists.

test_rule(name, obj=None, target=None)

Tests the rule with the given name. SeeRuleSet.test_rule.

add_perm(name, predicate)

Adds a rule to the permissions rule set. SeeRuleSet.add_rule.

set_perm(name, predicate)

Replace a rule from the permissions rule set. SeeRuleSet.set_rule.

remove_perm(name)

Remove a rule from the permissions rule set. SeeRuleSet.remove_rule.

perm_exists(name)

Returns whether a rule exists in the permissions rule set. SeeRuleSet.rule_exists.

has_perm(name, user=None, obj=None)

Tests the rule with the given name. SeeRuleSet.test_rule.

django-rules is distributed under the MIT licence.

Copyright (c) 2014 Akis Kesoglou

Permission is hereby granted, free of charge, to any personobtaining a copy of this software and associated documentationfiles (the "Software"), to deal in the Software withoutrestriction, including without limitation the rights to use,copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom theSoftware is furnished to do so, subject to the followingconditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHTHOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISINGFROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OROTHER DEALINGS IN THE SOFTWARE.