Authorization Basics with Roles and Permissions

* This is an automated transcript. Please excuse inaccuracies.

‍

So, what we're going to do right now is, jump in and take a look at the basics of authorization as it relates to 8base. Specifically, that's looking at roles and permissions as they are implemented within the 8base platform from the get-go and how by using these tools, you can leverage really fine-grained controls over the access that different users have to data as well as the actions that those users can then perform on that data.  

Let's just dive in and take a look at what we're dealing with.  

So, right now I'm in 8base workspace and this is the workspace that you would have if you had gone through the Quick Start app which you could follow at Docs.8base.com. There's absolutely no requirement to follow along for the rest of this video by complaining even that quick start first; however, it's a great way to get started and familiar with creating a simple application using 8base, so I highly recommend it if you haven't checked it out already.  

So, first off right now we are in the data builder slash data viewer view and all I wanted to show you is that we have a few different tables in here that will be seen in a minute; and brokers, customers, listings and properties- each of them with a bunch of records already populated. So, what we're going to do as this is about roles and authorization is, we’re going to jump over to our settings and click on roles. So, when you create a new workspace by default, you're going to have an administrator role and a guest role. To this workspace itself I added a property manager role. And essentially you can think of roles as an identifier to which many permissions can belong to right. So, we're going to define all different permissions that a property manager will have- that probably manager being a user because a user can have many roles. So, for example, you could say that well this user is both a property manager and a buyer; if those were two roles that you would want to have in your application. However, just to create a new role, you can click on new role, give it a name and a quick description and you're done. However, right now I'm going to click into the property manager role, and as you can see here, we have listed out all or from tables for our workspace as well as different crud actions that you could perform on a record and then fields.  

So, what we have here is, a list of all the different tables we're working with or we have in our workspace as well as the different crud actions and fields a column for fields right here. Essentially what we are able to do is specify what actions a role is, allowed to perform on a given resource as well as what fields they're allowed to access update or view on that resource as well. So, for example, for this property manager role let's say that a user is assigned at the property manager role and we want to say, “Okay well they cannot create listings. And they cannot delete listings. They can read all the listings, but they cannot update any listings.” All these things now are going to be handle at the data level, so if that user were to try to perform an update or delete action on a listing they would not be allowed to; the system would just reject it. However, then on the property since they are a property manager, when it comes with properties we're saying, “Okay they can create a property and we only want them to be able to read or actually we're going to let them read all records, but only let them update their own records the user records and we're not going to let them delete anything.”  

So, right there we defined in just a few seconds pretty much how a property manager role will be able to interact with the property's resource right; that is super-fast and super effective. And if we wanted to get even more granular, we could go to custom access on the fields and say that, “Well they have full access to fields, no access or custom access.” Custom access being like, “Hey, let's say that we didn't want them to never know when a property was created however, they could read when it was last updated. And they can update the number of bedrooms.” Like I'm saying, every single field we could go down here and then permission what they're allowed to do on that field. And as soon as we make one of these changes, it is live, it is ready to go, so we know that not only are we able to have fine-grain control over how people are allowed to interact with the data. But those changes are immediate and so we are always making sure that that's up to date.  

And just a little bit deeper you can even permission people at platform level. So for example, are they allowed to call certain endpoints; are they allowed to invoke certain functions; can they access logs if they're on the team; as well as if you wanted to just quickly see which users in your application or in your workspace have different roles by clicking on the role, you can look at the different users right here that that role belongs to.  

So, this was a quick overview there's some different levels of authorization roles and permissions that we can dive into later. However, I want to give you guys a kind of bite-sized chunk of what it looks like from the beginning and yeah, I think that was pretty good. So, if you have any questions please feel free to use the comments section below. If you're looking forward to seeing future videos, please subscribe to the channel and I hope you have a great rest of your day. Take care.