Security Roles

This help file applies to an out-of-date version of MainBoss.
The most recent version of MainBoss is MainBoss 4.2.4.
For the latest version of this help file can be found here.

< Previous section | Table of Contents | Index | Next section >

Security roles make it possible for your organization to restrict access to information. By assigning a role to a MainBoss user, you give that user permission to perform various operations within MainBoss.

In many cases, a single user will be given multiple security roles. Each new role that a user receives will give additional permissions to that person. If a user has no assigned roles, the user cannot use any feature in MainBoss; therefore, when you add a new user to the MainBoss Users table, you should assign that person at least one role.

Important: Each built-in security role has a brief description and a much longer "Comments" field describing how the role works. We strongly recommend that you read the "Comments" to understand the role in detail.

There are several general types of security roles:

Summary roles: Let you read a subset of the information that a record contains. For example, the UnitSummary role lets you read basic information about a unit but doesn't let you to read all the information in a unit record.

Summary roles are intended for people whose primary concern is some other aspect of MainBoss but who may have need for a small amount of information on other subjects. For example, someone working on a help-desk is primarily concerned with requests, but might also be given WorkOrderSummary (in order to tell clients, "Yes, your job is on our schedule for next Thursday" and to link requests to existing work orders) and UnitSummary (in order to make sure that the unit specified in a request really is the unit that needs service).

We recommend that organizations be generous in assigning Summary roles, but cautious in handing out roles that allow wider access to information.

View roles: Let you read information but not change it. For example, the UnitView role lets you read all the information in a unit record, but doesn't let you change any of that information.

A view role includes all the information available through the corresponding summary role. For example, WorkOrderView includes all the information of WorkOrderSummary (and more). Therefore, if you assign someone a view role, you don't need to assign the corresponding summary role.
Fulfillment roles: Let you perform selected operations on a type of record. Loosely speaking, these operations are ones you'd do in day-to-day work except for actually creating the record. For example, WorkOrderFulfillment doesn't let you create work orders, but lets you perform operations related to closing existing work orders. RequestFulfillment lets you add comments to requests and to send comments to requestors (if you have licensed the MainBoss Service module). ItemFulfillment doesn't let you create item records, but lets you record item information including physical counts, item issues, and item transfers.

With WorkOrderFulfillment, you can only affect work orders that you can already see because of other permissions. In particular, if you don't have WorkOrder or WorkOrderView, you will only be allowed to deal with work orders to which you've been assigned. A similar principle applies to RequestFulfillment.
Create/edit roles: Let you create and edit various types of records. For example, the WorkOrder role lets you create/edit work orders while the Item role lets you create/edit item records.

A create/edit role includes all the information available through roles in the same "family". For example, if you assign someone WorkOrder, you don't have to assign that person WorkOrderSummary, WorkOrderView or WorkOrderFulfillment, since WorkOrder includes all the permissions of the other three roles (and more). Therefore, if you assign someone a create/edit role, you don't need to assign any other roles in the same "family".
Accounting roles: Provide access to monetary information. If you do not have an appropriate accounting role, you may be prevented from seeing prices and costs; for example, if you have WorkOrder role but not AccountingWorkOrder, you will be able to record, say, the quantities of materials used on a job, but you will not see the actual cost of those materials.

In addition to the selective roles listed above, there is a role called All. This grants a user permission to use every aspect of the program. We recommend that you avoid using All; too often, we have seen organizations give All permission to users without thinking about it. Instead of taking the shortcut of All, decide which permissions a particular user really needs and only give the user those permissions.

Security roles are listed in the Security Roles table (Administration | Security Roles). To give someone one or more security roles, you open that person's record from the Users table (Administration | Users) and go to the record's Security Roles section. You then use New User Security Role to add role records to the user's list of roles. Each role record contains a "Comments" field explaining what permissions the role provides.

Some security roles combine with each other to provide users with more information. For example, if you have both ItemSummary and WorkOrderView, you can see more information about the items on a work order than either ItemSummary or WorkOrderView would provide individually.

When you assign security roles to a user, it can be difficult to figure out the effect of those roles: what the user can and can't do with the roles you've assigned. To make it easier to see the effects of a person's security roles, you can use the Evaluate Security As button in Administration | Users. For more information, see Viewing Users.

For information on viewing security roles, see Viewing Security Roles. For information on creating and editing user records, see Editing Security Role Records.