Fork me on GitHub
2sxc 9.43 for DNN 7 to 9
Website Builder, Content Manager, App-System: open-source and fun
You are here: Home  >  Learn  >  Permissions

Learn to work with Permissions in 2sxc

Permissions are a new feature of 2sxc 7.1. They allow you to change access rights to views and they also allow you to publish certain data-functionality - like allowing anonymous users to create content on your site (very practical for contact-forms). 

Currently permissions can be applied to these areas:

  2. Queries
  3. Content-Types

Each area has slightly different abilities which I'll try to explain below. 

Understanding Permissions

Basically permissions are simply a set of instructions - saying "On some object, if the Condition applies to the current user, give him the following Grant."

Understanding Conditions

Conditions are basically things that DNN already checked before. So if DNN says this user is an Admin - then then this is what the condition will check. 

Note that not all conditions make sense everywhere. Clck on the image to discover more. 

Understanding Grants

So a grant is basically what is allowed. Note that not all grants make sense on every kind of object. 

Check out the image to discover more. 

Permissions on Views

When applying permissions to views, the following rules apply:

  1. Any view without any permissions is regarded as public = visible to all users. This is different from the Query or Content-Type permissions, which are regarded as private (not accessible) when no rules are applied. 
  2. No matter what you configure, Admins and higher privileges incl. Host) always have view-access
  3. So of the many possible conditions only the simpler ones make sense (Anonymous, View, Edit) 
  4. The view only cares about Read-grants or any grant which includes read (like Edit). Giving it an exotic grant like "Create" or "Delete" will have no effect

Permissions on Content-Types

In 2sxc 7.1 all content has a REST API. So you can do all CRUD operations (Create, Read, Update, Delete) using simple URLs. This is great for JavaScript development but requires that you define who is allowed to delete, create etc. 

Common use cases are:

  1. With public forms (contact forms, service requests, etc.) you will usually give Anonymous the right to Create, but nothing else
  2. With public apps (like jobs-listings, showcase-apps, galleries) you will usually give the Anonymous users Read permissions 
  3. With Admin-Forms you will usually give people with Edit permissions the right to Edit (Create, Update, Delete)

Permissions on Queries

Some queries are admin-only, some are public. So all have a REST API (from 2sxc 7.1 and up) and to define who is allowed to use the queries, you'll set permissions.

Common use cases:

  1. Public apps: give the query read permissions for Anonymous or for users who have View-rights on the App
  2. For Admin-Apps: give Editors / Admins Read access

Note that you can give other Grants as well - like update - but only the "Read" aspect will be respected.