- Plan
- Product
- Subscription
- Access Group
- Role
- Permission
- Access Rule
A Plan is a more aptly labeled a pricing plan. At it's core, it determines the pricing interval and price of a Product.
A Product determines the details of an item being sold whether it is a physcal item in inventory that will be shipped or a conceptual collection of software features that someone pays for over time. In non-physical items, it defines which Access Group a company recieves when they purchase the product.
A Subscription is the merging of a Plan and Product. It mainly defines who is subscribed, how long they are subscribed, when they should be billed next, etc.
An Access Group is a collection of permissions. It is different from a Feature in that it defines broad access to multiple features.
An Access Rule determines how a company can access an access group. For instance some groups may need to have a cap on how many users can access it.
A Permission (Formerly Feature) defines the access divisions to a specific Feature in the system. For instance, the Contact Feature includes editing, creating, and deleting contacts. Each user of the system will have to have the correct permissions to perform their specific use case.
Permissions are defined by a unique string that is formatted as such: /Feature Group/Feature Name/Action/
A Feature centers around the objects or logical entities in the system. For instance, "Contact" is a feature. Or, "Map" is a feature of the system. When a person wants to interact with maps in the system, they must have access to the "Map" feature and it's specific permissions. So, for instance, if a Meteorologist needs to create a new map, then they must have Permission to access "Map" entities and specifically the Permission to perform the edit or create new maps.
What is the difference between features and permissions? Features describe what comprises the system, and Permissions determine how those features are interacted with. So, for instance the Marker feature determines that there is a certain thing called a marker in our system that operates with certain rules and relationships. The Permissions around the Marker define what actually can be done by each user. Users gain permissions which grant them access to features. Some users may have more or less depending on their access group.
Access groups are designed to break the system down by manageble or sellable units or groupings of features. For instance, you have your "Base Package" of features every user gets. Then you have a "CRM" Package that turns on a bunch of features related to the CRM. Then you have a "Canvassing" group that turns on all the canvassing features. Or maybe a "Canvassing Lite" group that turns on only some of the canvassing features.
| Property | Description |
|---|---|
| name | Required. String. The name of this Access Group. |
| permissions | Required. Array<Permission>. The permissions this group enables. |
Access rules are the bridge between actors and access groups. When a user attemps to use a permission of the system, the system follows this procedure:
- Find all access rules related to this user and his company.
- Check to see if his company has this permission.
- If his company has this permission, check to see if this user has this permission.
A few use cases are covered by access rules.
- The case where a company can only have a certain number of users accessing a certain feature.
- The case where a user needs to be granted access to certain permissions.
- The case where a company needs to be granted access to certian permissions.
| Property | Description |
|---|---|
| ruleType | Required. String. The kind of rule this is. Can be ACCESS_GROUP (default) or INDIVIDUAL_PERMISSION. In the case of INDIVIDUAL_PERMISSION, the access rule bypasses group access and just grants access to the permission provided. |
| actorType | Required. String. The kind of actor that is stored in this rule. Can be USER or COMPANY. If USER, the company and user properties will both be filled out. If COMPANY, only the company property will be filled out. |
| accessType | Required. String. The type of access this rule enabled. Can be NOLIMIT, LIMIT or USAGE. |
| accessGroup | Required. String. The id of the access group this rule grants access to. |
| company | Required. Company. The id of the company that gains access to access group permissions. |
| user | Optional. User. The id of the specific user that gains access to the access group permissions. |
| value | Required when accessType=LIMIT|USAGE. Number. The value related to this rule's access type. |
| permission | Required when ruleType=INDIVIDUAL_PERMISSION |
Roles in the system have a bit of a legacy naming scheme, but they function similarly to Access Groups. The only difference is that they are user-defined.
| Property | Description |
|---|---|
| name | Required. Unique name of the role. |
| features | Required. Array<Permission>. Permissions enabled by this role. |
| account | Required. User. Account admin user id. |