Privilege and Roles management - agileChilli
Description of the Privilege System
In agileBase, there are three privilege levels, as well as an extra ‘Administrator’ privilege.
The three privileges take effect per user per table, i.e. a user can have certain privileges on one table and different ones on another.
The levels are
- VIEW: ability to read data only
- EDIT: ability to read and edit data
- MANAGE: ability to modify the database structure, i.e. create/delete tables, fields, reports etc., basically to build up and tear down databases. MANAGE also allows a user to unlock an individual record for editing if it has been locked.
For people with less privileges, the user interface is simplified.
As an administrator, to assign privileges, use the Administrator module at the bottom of pane 1.
The administrator privilege doesn’t apply to a particular table but is a global option that allows setting up of users, roles, assigning privileges and creating modules. To assign the administration privilege, you must make a user a member of the ‘admincompanyname‘ role (there will be a role called this, using the actual company name)
If the number of users you manage starts to become large, you may want to assign them roles, which allows privileges to be managed on a mass basis. If a user has a certain role, he/she has all the privileges assigned to that role. Users can have more than one role.
To assign privileges, click on the ‘Administration’ module then ‘users’ or ‘roles’. This will allow you to select a user/role and assign table privileges. Alternatively, you can come from the other direction by selecting a table from ‘Tables’ then going to the manage tab which will let you set user/role privileges for that one table.
When setting user privileges, agileBase will show any privileges that the user already has due to being a member of a role. In this example, the user has been given EDIT privileges specifically on customer details and site addresses and is a member of a role that has VIEW privileges on staff contact details.
Below the Privileges button is one called Views.
Normally, a user can see all views that include data from tables they have privileges to view. However, you may want more fine grained control. Reports preferences can be used to narrow down the list that individual users can see. This can be particularly useful if you want to allow clients access to selected parts of your data.
For even finer grained record level control, you can assign a specific per-user filter in the user details section.
Fine grained access control (e.g. multi-company setups)
Privileges and roles in agileBase were two of the first ideas built into the system at the earliest stage of development eight years ago.
The fundamental concept has stood the test of time, being simple to understand, easy to set up, secure and covering a wide range of needs. A user can have no privileges, read only, edit or manage privileges on any table in the system (‘manage’ being the ability to make changes like add fields). To make things easier when dealing with large groups of users, people can be assigned roles, where each role has it’s own set of privileges. User and role privileges co-exist, so if a user needs a privilege they don’t have as a member of a role, that can be assigned to them on an individual basis.
There have been no major changes to this system, the only tweak added since the beginning has been the ability to turn particular views (reports) on and off per person. So for example if you want to let each member of regional sales teams see contacts in their area only, you can set up a few filtered reports and assign them accordingly.
Recently however there have been a number of proposed applications that extend this logic. Examples are
- giving customers logins to see data related to them only
- similarly for suppliers
- setting up a franchise, where each franchise branch deals with their own data but the central office can see everything
To deal with this type of thing, we’ve just introduced fine grained access control, which works at the level of individual records within a table, rather than the whole table itself.
It’s set up to be a very flexible for administrators to implement. Each user of the system can be given a filter that’s automatically applied to any data view they look at. The filter consists of a field name and filter value. When any view is loaded that contains a matching field, the filter is applied before returning the list of data to the user. Because the fields can be of any type, even calculations, filters based on any criteria that can be represented in a calculation can be applied, i.e. almost any criteria.
Thus your data can be shared with a wide a range of people as need to see it, without fear that they will access anything unauthorised. The potential for widening participation and collaboration is dramatically expanded.
As an administrator, to set this up, just go to Administration -> users and look under ‘restrict data access’.
Managing deletion policies
What happens when you delete something from agileBase?
Well, the content of all the fields in the record to delete will be logged, so that an administrator can find the data later if necessary, and the delete will go ahead. That’s assuming the combination of options on the table and your privileges allow it of course.
Options can be set at a table level, to allow only users with manage privileges to delete from a table, or everyone who has edit privileges only. To set this, go to the manage tab of a table, then click ‘options’. Privileges can be set by role or by individual user.
But what if there are related items? For example, you may be deleting a company record which has contacts and maybe other things linked to it. In this case, the system will present a hard-to-miss warning, telling you all the things that will vanish if you carry on:
Only people with ‘manage’ privileges can carry on to do a cascading delete including linked items, and only of course if they have the necessary privileges on all the data to delete too.
That’s all fine and dandy but sometimes administrators may want more control over the details of deleting linked records.
For example, there may be cases where a user, even with full privileges, should never be allowed to delete linked ‘child’ data. For example, say there’s an event management system that you run. Each event has a venue, chosen from your global ‘companies and addresses’ list.
Now deleting an address will also prompt for the deletion of any linked events, but that doesn’t necessarily make sense. You may not want to delete an event just because it’s venue is removed – perhaps it’s just moving to another venue.
What’s the alternative?
Well there are now three options for what can happen to ‘child’ records once a ‘parent’ is deleted. The second two are new options:
- cascade the delete
This is the default option described above
- prevent deletion
The user won’t be able to delete the parent record at all, until all children have been manually removed or un-linked
- make children ‘orphans’
In other words, the children will be un-linked automatically. In the events example, events will have their venue set to a blank value if a related venue is deleted
Different options will make sense for different data and you can set each relation in the system separately to use the one best suited for the data.
In the events example, you may wish to ‘blank’ or un-set venues when a site is removed. However, if you have invoices for customers, you may want to disallow entirely the deletion of a customer who has linked invoices.
How is this set up?
Quite simply. In the field options for each relation field, there’s a new option controlling the deletion policy. A dropdown will let an administrator choose the most relevant behaviour.
It’s set from the ‘child’ table, letting you specify different options for each type of ‘child’ of a record.