This document will briefly go over the knowledge required to be able to understand how the permission system is constructed at what each item in it does.
Briefly, our permission system is configured to be made of objects called Operation Rights. The attributes in this info object that are of main concern to us for this concept section are: Actions, Enabled, GrantType, and System.
Please note all system and action items are case sensitive.
A system item is used to apply operation rights to. What this means is the permission system understands the hierarchy of objects (currently only for the Keep Object Model items) therefore rights created for a base type will apply to derived members. For example, an Operation Right of Create for MercuryController allow the user/group to create any derived type of MercuryController (ex. Ep1501 or Lp1502/Lp3202).
A system can therefore be any Keep Object Model item and the naming convention is how it is stored in the mongoDB database. For more information on the Keep Object Structure please check out the Using Aggregates Document. Briefly in most cases the info object is stored in the database without the info attached to it and these are the objects that can be used as a system.
As an example the current possible permission system items offered by our Windows client are: AccessLevel, AlarmAction, AlarmDefinition, AreaAssignment, BadgeType, BadgeTypeField, BoschArea, BoschAuthorityLevel, BoschDevice, BoschDoor, BoschOutput, BoschPanel, BoschPoint, BoschService, BoschSked, BoschUser, Camera, CardFormat, Controller, Downstream, ElevatorAccessLevel, EngageIpGateway, EngageReader, EngageSite, EventMessage, ExecuteProcedureAction, Floorplan, FloorplanItem, Folder, Generic, Group, HgProcedure, HgTrigger, Holiday, ImagePointer, Instance, InstanceSettings, KeepObject, LdapAgent, License, LocalArea, MercuryInput, MercuryOutput, MercuryReader, MessageTemplate, NotificationAction, Person, Schedule, ServiceContainer, User, Visit, WebHook, AwsKinesisEventDestination, AwsKinesisAlarmAction, AwsSnsAlarmAction, AwsSnsEventDestination, AwsSqsAlarmAction, AwsSqsEventDestination, KoneCabinAccess, InputScanner, Attendee, and VisitorManagementSettings.
A short cut to applying all items it to use the system All Types, (Which is really BaseInfo in the database)
The Set of actions available to the user/group for the stated system. These actions include: Read, Create, Update, Delete, Publish, Linking, and advanced options.
In actuality an action can be whatever you want the above is only how we have decided to implement the actions in our system.
Thus the rest of this actions section will look at our configuration but if you are building your own different model you may or may not find this useful.
An object generally requires read permissions generally if you would like to view it. In most cases you will not require anymore permissions to view a particular object. This assumes you are not wanting to look at the objects that might be associated with the object you are wanting to view. Any associated abject will also need read rights.
An object generally requires create permissions if it does not exist yet.
An object generally requires update permissions if it does exist and you want to modify it.
An object generally requires delete permissions if it does exist and you want to get rid of it.
An object generally requires publish permissions if you want to allow a user to create events for the system item in question.
Linking occurs whenever you have a connected object. To be able to connect an object (a system) the object you wish to connect must have add linking permission on itself. Also to be able to remove a connected object the object you wish to remove must have remove linking permissions.
If you want to be able to link anything to an item you can use a * for the system item in the action. Please note this works best on groups of items or if you have custom names for a system or systems in your model.
It is possible to apply permissions to custom groups of objects by applying tags to the operation right and the desired items to group together.
In our system permissions are any action that fall out of scope of the above actions. For instance with advanced permissions we can set actions that will only apply to specific system types. This is in our system where the custom individual operation rights will be set and determined.
This attribute in the permission system is probably the most important and simple portion. For the Operation Right to take place (be active) it must be enabled. This attribute is a simple boolean attribute that when true means the operation right is enabled. If false then the operation right will not validate and the permission will be denied.
The intention of this flag, is to make it very easy to temporarily elevate a user/group permissions by turning on or off a given Operation Right.
Grant Types come in two choices: grant and deny. This needs to be set so the system knows weather to grant (allow) access or deny (disallow) access. The deny will supersede any grant if there is a conflict on the same system item.