This topic discusses the general background and functionality for Group Maintenance, User Maintenance, and View Maintenance within Abila Millennium.
Follow these links listed for explanations and specific procedures for Group Maintenance, User Maintenance, and View Maintenance:
When User Security is accessed, two areas display. Information about the Abila Millennium User Groups is displayed under the Group Maintenance header, and information about each individual Abila Millennium user is displayed under the User Maintenance header. The information about the user groups and the users display as individual 'data' rows in typical Abila Millennium fashion. Edit buttons are located to the left of each entry and a fly-over context menu appears when you move the mouse pointer over either the Section Header Edit button or any one of the edit buttons.
By default, the user data is shown is Short mode - a single line display. In Short mode, the display for the Abila Millennium User Group information includes the name of the group only. In Short mode, the display for Abila Millennium Users includes the Name ( Abila Millennium User id), Abila Millennium User Group (MUG), and the SQL Group (Database Group) for each user. By default, the Sort order is ASCII order within SQL Group; that is to say, User Names are first sorted into SQL Groups and then ASCII ordered within each SQL Group.
The context menu that is accessed via the Group Maintenance section header Edit button includes items that allow you to switch the display between Short and Long view, Insert a new Abila Millennium User Group, access the View Generator, or access this Help topic.
The context menu that is accessed via the User Maintenance section header Edit button includes items that allow you to switch the display between Short and Long view, Insert a new Abila Millennium User, Sort the list of Abila Millennium Users, or Close the context menu.
Note: If the Sort order selected is not the default Sort order, and if the IIS is reset, the Sort order will reset to the default Sort order.
There are three levels of security that may be applied to the operation of Abila Millennium in an SQL environment. Each has a different purpose and application and each is administered independently (or nearly so). These are:
Database Group Security is administered through the Group Maintenance function of User Security in Abila Millennium, using Views that were created using the View Generator. This form of security is used to determine which data rows a user may access, edit, or delete.
MUG security is administered through the User Maintenance function of User Security in Abila Millennium. This form of security is used as:
SSL security is entirely administered through Microsoft's Internet Information Server (IIS). This form of security is used to encrypt the transmission of data across a network and is used to secure a system against intruders. This form of security is external to the function of Abila Millennium and is not addressed by this topic.
An understanding of the following terminology is necessary for the Group Maintenance and User Maintenance documentation, which follows.
Abila Millennium uses the term, group in several different ways. This topic describes the distinct differences between the Database Group and the Abila Millennium User Group and how they are applied to the subject of security in Abila Millennium. There are additional kinds of groups within Abila Millennium that have no particular relationship to the topic of security but are simply mentioned to ensure that the reader is aware of the distinctions. These include the Lookup Table Group - a standard field in all lookup table rows that allows an institution to classify a set of lookup table entries in some way, and also a Criteria Group - which allows the Millennium Reporter to select multiple sets of constituents within a single run of a report. Those groups are discussed with Lookup Tables or Reporting, respectively.
A View is an SQL object, sometimes referred to as a virtual table, which may be used to restrict access to selected data in a particular data table.
Views are constructed and saved via the Abila Millennium View Generator, which is accessed via the Group Maintenance Options button in the User Security display page. When Abila Millennium is delivered and installed, a default set of Views is provided. That set consists of one View per Abila Millennium data table, each named <tablename>_full. For example, the default view on the Basic Data table is named corebio_full. Each of those Views gives access to all rows in the designated data table.
You may define any number of custom Views that apply to individual data tables. A listing of all Views that have been created and stored may be seen and used from within the Group Maintenance function of Abila Millennium.
You may define a custom View for the purpose of masking the display of sensitive information. For example, you may want the users in a particular Abila Millennium User Group to be able to see that a constituent has a death record, but you may not want them to be able to view the cause of death. Define a custom View that selects all fields from the death table. If the deathcause field contains information, select a series of masking characters (typically asterisks) instead of the actual text contained in the field. Give this Abila Millennium User Group select privileges for this view. When displaying a constituent's death record, then, users would see the masking characters instead of the cause of death.
Important! Do not define a custom View to mask the display of Abila Millennium's encrypted fields (coressnum, credccnum, credssnum). When these fields display through Abila Millennium, the software will attempt to decrypt the masking characters and the results will not be correct.
When a View is defined (that describes the conditions for access to rows in a specific data table) that definition may reference data in other tables, in the conditional statement. For example, you might construct a View that would allow access to all Gift rows that belong to any constituents who do not have a Y(es) in the Anonymous field in their Basic Data row. That View would have no effect on the access to the Basic Data row. A separate View would be needed to define Basic Data access.
A Database Group is a SQL technique for creating a "packaged set" of Views, naming that Group and then assigning users to that Database Group (rather than having to select individual Views for each user that you want to add to the system). Abila Millennium includes the tools necessary to define a Database Group via the Group Maintenance function within the Tools World. When a Group is defined via Abila Millennium, it is automatically "registered" appropriately within SQL. Likewise, when you are using Abila Millennium to define a Group, all Views that are have been created within the system are shown and are available for use in creating a Database Group.
When Abila Millennium is delivered, it includes a default Database Group, which is named mill. This Database Group consists of the "full" View for each of the Abila Millennium data tables and for all functions that a user might perform. If you want, you may assign all users to the mill group. This would give all users complete access to all data, for all functions (viewing, creating, editing, and deleting).
This "wide open" approach to security will not be appropriate for most institutions, and therefore, you will want to create additional Database Groups in order to impose the necessary restrictions.
Do not confuse the Database Group with the Abila Millennium User Group, which is described below.
The Abila Millennium User Group (MUG) is a one character, upper or lower case alphabetic character "flag" that is associated with the individual's User ID. They have several applications within Abila Millennium.
Abila Millennium User Groups do not need to be defined or set up within Abila Millennium prior to the time that you assign the flag to a user, though you will certainly want to have a meaningful plan for doing so. They may be defined in any way that your institution wants. We anticipate that institutions will want to use this technique for identifying users within different geographical offices, different departments, or different divisions within the institution. You might also want to distinguish groups of users based on their use of Abila Millennium.
When Abila Millennium is installed, it includes a single Database Group, named mill. The mill group is based on a default set of Views, which are also delivered with the software. This default set consists of a full View for each of the Abila Millennium data tables. For example, there is an actions_full, an address_full, etc. Therefore, since the mill group includes the full View for every data table, any user who is assigned to the mill group has complete access to all rows in all tables in Abila Millennium.
There are no Views for lookup tables in Abila Millennium. Database Groups may also be given various levels of access to Lookup Table maintenance functions as part of the definition of the Database Group. These permissions are applied to all lookup tables and all entries within them. Further control of the Access and maintenance capability may be applied to individual entries in any lookup table via Abila Millennium User Group settings.
The system administrator may create additional Groups, which use a different combination of SQL Views (including none), for certain tables or functions. When these Database Groups are created from within Abila Millennium, the system automatically registers these as SQL Groups within SQL Administration. While it is possible to create a Database Group through SQL Administration (bypassing Abila Millennium), such Groups will NOT be available within Abila Millennium.
To restrict a user's access to Abila Millennium data and functions, you must create additional Groups or alter mill, removing certain access for users in that Group. Groups may be used to restrict the user's access to the data in several ways.
You may define a Database Group in such a way that
no Views of certain of the data tables are included. For example, you
might define a Group in such a way that includes Views of all of the Biographical
and Giving data tables but no View of the Tracking data tables. If no
View of a particular data table is included in a Database Group, when
a user from that group attempts to display a constituent's data from that
table, the Profiles display will show the Section Header followed by the
text (in red), Insufficient Security to View (Table
Name).
You may pick and choose from any of the default or custom Views that are
present on the system when assigning Views to a Database Group.
You may define a Group that assigns different Views to different functions within a single data table. These functions are:
For example, you might define an Executive Group in such a way that all users in the Group have the full Views of particular data tables for the Select function but no View assigned to the Update, Delete, or Insert function. This would allow those users to look at anything in that table (in Profiles, Reporting, or any other world that accesses that table), but would provide no ability to edit, delete, or create any existing rows.
When you are defining a new Group or editing an existing one within Abila Millennium Security's Group Maintenance, you must first choose a data table from the Table List box, and then the system will display all of the Views that are available for that data table. This includes the standard ones (for example <tablename>_full) and custom ones that you have defined. You may choose any that are available for that data table, and assign them to any of the functions described above.
Create a Group that includes the following Views for the Basic Data, Name, and Attribute tables only:
For Basic Data:
For Name:
For Attribute:
Any user who is assigned to such a Database Group would be able to see (select) any Basic Data row, or any Name row. They would also be able to see (select) any Attribute row that conforms to the conditions of the View named attribute_sports. And they would also be able to update or delete any Attribute row that conforms to the attribute_sports View conditions.