Profiles and Access Levels - Advanced Permissioning

Access Levels

Not every user has to be the same.

Sometimes, you may want to restrict what they can see or what they can do on your jestor. For example, maybe not everyone in your company should have access to financial data, or maybe you want to invite clients to your jestor but restrict what they can see in a way they only have access to tables and records that involve them directly.

The thing about access level is that they can be infinitely different in their uses, so it makes sense that you should be able to set up an access level just the way you want to. For this, jestor has the Profiles area.

Setting up a Profile

To create a Profile, access the Developer Area and click on Profiles, then +Create new profile. Name your new profile and press Create.

📘

Default Access Level

A newly created profile will come with a default arrangement of permissions where a user will be able to see everything, but won't be able to manage users or create tables and dashboards.

Setting the rules

You can define a lot of important things on the profile setup. We're going to go over each part later, but first, here's a commented example of a profile

{
	"manage_users": 0, //can't add new users or change access levels
	"create_table": 0, //can't create new tables 
	"create_dashboard": 0, //can't create new dashboards
  "channel_read_only" : [123], //channels which the user will only be able to read
  "direct_message_users": [1,11,22], //users which the user will be able to send messages to
  "direct_message_profiles": [10001,11001], //profiles whose users the user will be able to send messages to
	"tables_enabled": {
		"tasks": { //can see the Tasks table
			"data": [ //the Tasks table will be filtered with the conditions below
				{
					"field": "owner",
					"reference": "id_user" //only shows records in which the user is tagged as owner
				},
				{ //AND
					"field": "status",
					"operator": "!=",
					"value": "Done" // only shows records with status different from "Done"
				}
			],
			"fields_excluded": [
				"request_date" //can't see the Request Date field
      ],
			"fields_readonly": [
				"client", //can see the Client field, but not edit
				"priority" //can see the Priority field, but not edit
			],
			"manage_structure": 0, //can't create/edit/delete fields 
			"can_delete": 0, //can't delete records
			"can_create": 1, //can create records 
      "can_edit": 0, //can't edit records
      "create_comment":0,
			"edit_comment":0,
			"delete_comment":0,
			"read_comment":0
		},
		"reminders": { //can see the Reminders table 
			"*": "*" //can see everything and do anything on the Reminders table
		}
	},
	"tables_disabled": [], //no specific table disabled
	"pages_enabled": {}, //no specific page disabled
	"pages_disabled": [], //no specific page disabled
	"dashboards_enabled": {  
  	"*": "*" //can see every dashboard
  },
	"dashboards_disabled": [
  	"marketing_kpis" //except for Marketing KPIs
  ]
}

There's a lot to unpack here, so let's go in order:

• manage_users: ability to add new users and change users' acess levels. Can be true/1 or false/0.
• create_table: ability to create a new table. Can be true/1 or false/0.
• create_dashboard: ability to create a new dashboard. Can be true/1 or false/0.
• tables_enabled: list of tables the user will have access to. You must pass not only the table's API name, but some additional parameters:
  • data: filters to define what the user will be able to see. For the whole set of valid operators, check the list of filters on https://docs.jestor.com/reference#list-records.
  • fields_excluded: list of fields the user won't be able to see.
  • fields_readonly: list of fields the user will be able to see, but not edit.
  • manage_structure: ability to create/edit/delete fields. Can be true/1 or false/0.
  • can_delete: ability to delete records. Can be true/1 or false/0.
  • can_create: ability to create records. Can be true/1 or false/0.
  • can_edit: ability to edit records after they are created. Can be true/1 or false/0. (BETA)
• tables_disabled: list of tables the user won't have access to.
• pages_enabled: list of pages the user will have access to.
• pages_disabled: list of pages the user won't have access to.
• dashboards_enabled: list of dashboards the user will have access to.
• dashboards_disabled: list of dashboards the user won't have access to.
• default_tabs: menu arrangement on the user's first ever login. You'll have to pass the following nested arguments:
  • sections: each menu section will be comprised of:
    id: an identification for the section.
    label: how the section will appear on the menu.
    items: list of tables/pages/dashboards that will be inside the section. For those items, you'll have to pass the following arguments:
    object: the API name of the table/page/dashboard.
    label: how the table/page/dashboard will appear on the menu.
    type: the item type, such as object (for tables in list form), board (for tables with a kanban view enabled), dashboard or page.

Restrictions are Stronger than Permissions

Always remember: a restriction will overrule permissions. What this means is that even if you say a user has access to everything, if you block a specific table, they won't have access to it. In a similar way, if you say a user can't see any tables, it doesn't matter if you grant him permission for the Tasks table: they won't have access to it.

So for example, the profile will be able to see everything, except for the Payables and Receivables tables.

{
	"manage_users": 0, 
	"create_table": 0, 
	"create_dashboard": 0,
	"tables_enabled": {
		"*": "*" 
	},
	"tables_disabled": [
		"payables",
		"receivables"
	], 
	"pages_enabled": {
		"*": "*" 
	}, 
	"pages_disabled": [], 
	"dashboards_enabled": { 
		"*": "*"
	},
	"dashboards_disabled": [
	]
}

And the profile below won't be able to see any table at all, despite having "Tasks" on tables_enabled.

{
	"manage_users": 0, 
	"create_table": 0, 
	"create_dashboard": 0,
	"tables_enabled": {
		"tasks": "*" 
	},
	"tables_disabled": [
		"*"
	], 
	"pages_enabled": {
		"*": "*"
	}, 
	"pages_disabled": [], 
	"dashboards_enabled": { 
		"*": "*"
	},
	"dashboards_disabled": [
	]
}

Always check for those rules and use them on your favor 🧙‍♂️