First Security Assignments

After the last tutuorial our Orders system now has a table of customers. It is time to add a second table, a table of items, and then see how to add some security.

Related Reference Material

The topics discussed in this tutorial are also discussed in the reference sections on Superusers, table security and module security.

The Items Table

The items table will have two new columns. One of them we must define, the column "item" which is a ten-character alphanumeric. The column "price", like "description", is defined in andro_universal.add, and is of type "money". The definition of item looks like this:

column item:
   type_id: char
   colprec: 10
   description: Item Code

Naturally our tables will acquire more columns in later tutorials, but this is enough for now. Here is the table definition:

table items:
   module: orders
   description: Items
   
   column item:
      primary_key: "Y"
      uisearch: "Y"
   column description:
      uisearch: "Y"
   column price:
      uisearch: "Y"

Two Security Groups

Andromeda is a "deny by default" system, so that all access to all tables is denied by default. It is important to realize that this applies even to superusers. A superuser's power is expressed in this way:

• A superuser gains all of the priveleges of all groups, so if no groups have been defined the user will have no priveleges in the database.
• A superuser can log into the node manager and run builds, so the user has the ultimate ability to modify any business rule.
• A superuser can disable triggers and therefore turn off business rules, and therefore can corrupt data, but this is always in the power of any administrator, so it is not special to an Andromeda superuser.

We are going to create two security groups. The first is going to be regular staff. Our basic idea is that they will be able to create and work with orders, and they will at least be able to read any table. The second is going to be an administrative group that has complete control over all tables in the orders system.

The two definitions are here:

group orders_staff:
   description: Orders - Regular Staff;
   module orders:
      permsel: Y

group orders_admin:
   description: Orders - Administrator
   module orders:
      permsel: "Y"
      permins: "Y"
      permupd: "Y"
      permdel: "Y"

A group has one property, the description. This is required, as the description will be used on the user maintenance screen, which we will see in the next tutorial.

Inside each group definition is an assignment of default properties to the orders module. The "orders_staff" group is given the 'permsel' permission, that is, they are given permission to SELECT from any table in the module. The "orders_admin" group is given all four fundamental permissions, to Select (permsel), to Insert (permins), to Update (permupd), and delete (permdel).

Let Staff Control Orders

As it stands, our general group "orders_staff" can read the customers table but cannot change it, which does not give them much to do. We will now apply some settings directly at the table level for the orders_staff group, by adding an assignment to our table of customers. We will not give them ability to change items because that requires a higher security clearance.

table customers:
   module: orders
   description: Customers
   group orders_staff:
      permsel: "Y"
      permins: "Y"
      permupd: "Y"
      permdel: "Y"
   
   column customer:
      primary_key: "Y"
      uisearch:    "Y"
   column description:
      uisearch: "Y"

Run the Build

With these additional security assignments, we can then rebuild the application and we will see that our superuser now has the ability to add new information to our tables.

Note that if you are running these tutorials one after another, you will have to log out of the finance application and then log back in to reload the menu and security definitions.