Sample User Access Rights

In this section we assume you know how to add a user and how to grant access rights to the user. The topic we address here is what access rights are appropriate for a particular kind of user. We will do this through examples of user access tables, describing the reasoning behind each example in detail. You will likely have users that don't fit these examples exactly, but once you understand the security model you should be able to address your special security requirements.

Example - Purchase Clerk

Suppose user SMITH is a purchase clerk. We set up SMITH's access table as follows:

We want to grant SMITH access to objects needed to perform purchasing clerk duties, and no more. We will assume that SMITH needs access to the vendor accounts and the purchase journals. To accomplish this we added two rows to SMITH's access table as shown above. The first is attached to ACCOUNT/AP, thus granting SMITH access to all vendor accounts. The other access row is attached to JOURNAL/PURCHASE to grant SMITH access to the purchase journals.

As a reminder, when you added SMITH you should also have set SMITH's password. Provide SMITH with the password and user SMITH can now open the database. To do this SMITH will add a row to a workstation login table, select the database, and enter SMITH as the user name. The first time SMITH opens the database SMITH will be prompted for the password, i.e. the password you entered when you added SMITH.

When SMITH opens the database, SMITH's view of the database will differ from that of the administrator. SMITH will see two items in a table in the left pane, one for JOURNAL/PURCHASE, and one for ACCOUNT/AP.

SMITH will be restricted to a world where everything that can be viewed and explored will be under either JOURNAL/PURCHASE or ACCOUNT/AP.

Example - Payables Clerk

Suppose user BROWN is a payables clerk. We set up BROWN's access table as follows:

Like SMITH, we have given BROWN access to the vendor accounts under ACCOUNT/AP. But instead of purchase journals, we granted BROWN access to the bank payment journals. BROWN can now access the vendors to determine what needs to be paid, including such information as an aged accounts payable. Then BROWN can make the payments using a bank payment journal.

Note that we did not give BROWN access to any bank accounts. BROWN can select bank accounts for the payment transactions while adding them to a payment journal, but BROWN cannot access any bank account to view its transactions or balance. However, you could also grant BROWN access to any or all bank accounts as shown below:

In the last row above we granted BROWN access to a specific bank account. We did not attach the access row to the root bank account, i.e. ACCOUNT/BANK, because that would have granted BROWN access to all bank accounts. In this case, we do not want BROWN to have that much access.

When BROWN logs into the database, BROWN's left explorer will be a table with three rows. When BROWN positions on the row for the bank account, the right pane will show details of account 1060, the First National Bank, and its views can display transactions and other information about that account, but nothing else.

A point that should be emphasized here is that you do not have to grant access to whole areas of the database. You can be very specific, in this case, granting access to an individual bank account.

Example - Payables and Purchase Clerk

Suppose user BLACK is to have the duties of both SMITH and BROWN. That is, BLACK will be able to perform both purchase and payable duties. BLACK's access table might look like the following:

BLACK has the ability to do whatever SMITH or BROWN can do. Note that there could be an internal control issue here because BLACK can place orders with vendors and then pay the resulting invoices from the same vendors.

Example - Salesman

Suppose user GRAY is a salesman. We set up GRAY's access table as follows:

We have granted GRAY access to ACCOUNT/AR so that GRAY can access all customer accounts. In addition, we have granted access to JOURNAL/SALES/SO and JOURNAL/SALES/SI which will allow GRAY to access both sales order and invoice journals.

We could instead have granted GRAY access to a single journal object, JOURNAL/SALES, because JOURNAL/SALES/SO and JOURNAL/SALE/SI are both sub-journals of JOURNAL/SALES and therefore are below it. However, it is generally a good idea to be as restrictive as possible. For example, if new sub-journals are added later, GRAY will not have access to them if we granted GRAY access to JOURNAL/SALES/SO and JOURNAL/SALE/SI. On the other hand, if GRAY had been granted access to JOURNAL/SALES, then GRAY would also have access to any new sub-journals added to JOURNAL/SALES.

In a larger organization, user duties might be refined further. For example, you might grant a salesman access to only the order journal, and have a separate receivables clerk with access to the sales invoice journal. The salesman would add orders and the receivables clerk would turn them into invoices, say when the products are actually shipped or services are rendered and billed.

Example - Receivables Clerk

Suppose user GOLD is a receivables clerk. We set up GOLD's access table as follows:

The receivables clerk needs access to the customers and the bank deposit journal as indicated by the access table above. GOLD can access the customers to review them individually and or can review them using an aged receivables report. GOLD can also process receipts from the customers, adding them to bank deposits on the bank deposit journal.

Note that we did not give GOLD access to any bank accounts. GOLD can select bank accounts for the deposit transactions while adding them to a deposit journal, but GOLD cannot access any bank account to view its transactions or balance. However, you could also grant GOLD access to any or all bank accounts as shown below:

In the last row above we granted GOLD access to a specific bank account. We did not attach the access row to the root bank, i.e. ACCOUNT/BANK, account because that would have granted GOLD access to all bank accounts. In this case, we do not want GOLD to have that much access.

Example - Payroll Clerk

The access table for a payroll clerk named GREEN is shown below. GREEN has two access rows. One is attached to NEWVIEWS/PAYROLL, the root payroll object, and the other to JOURNAL/PAYROLL, the root payroll journal.

Attaching GREEN to NEWVIEWS/PAYROLL grants GREEN access to all employees, payrolls, payruns and payroll transactions. This is in fact everything GREEN needs to perform payroll duties. We added the access row for JOURNAL/PAYROLL merely for completeness since GREEN already has access under the objects listed above.

That is all you need to grant access to a payroll clerk. The rest of this example on the payroll clerk will point out a few additional concepts that illustrate the security model and related issues.

Here we can provide a brief description of why the access row attached to the root payroll object provides exactly the access needed for payroll, without going into the details of the payroll system itself.

A NEWVIEWS/PAYROLL object represents payroll functionality for a jurisdiction and contains collections of employees, payruns, and payroll transactions for that jurisdiction. The root PAYROLL object contains a number of sub-payrolls, generally one for each jurisdiction, for example NEWVIEWS/PAYROLL/CANADA and NEWVIEWS/PAYROLL/USA. These in turn contain just the employees, payruns and transactions for their respective jurisdictions. Because NEWVIEWS/PAYROLL/CANADA and NEWVIEWS/PAYROLL/USA are below the root payroll object, they inherit its access rights and GREEN thus has access to them.

Employees are attached to a payroll and therefore inherit access rights from the payroll object. Payrun objects are also attached to a payroll and therefore inherit its access rights. Payroll accounts are attached to an employee and therefore inherit the access rights of the employee and indirectly those of the employee's payroll. Finally, all payroll transactions, generally paychecks, are attached to a payrun, an employee, and a payroll.

The important point to be understood here is that all of the objects mentioned, i.e. the employees, payruns, payroll accounts and paychecks, are below the root PAYROLL object in the database. Therefore, when GREEN was granted access to the root PAYROLL object, GREEN was also automatically granted access to those employees, payruns, payroll accounts, and paychecks. This grants GREEN exactly the rights needed to perform payroll duties, but does not grant access to any other areas of the database.

Note that the PAYROLL object has sub-payroll objects for CANADA and USA, representing Canadian and American payroll functionality respectively. Payroll for any number of jurisdictions can reside within a NewViews database simultaneously. That is, you do not need separate products, programs, or databases that handle different jurisdictions. Countries will continue to be added in future versions of NewViews. We attached GREEN to the root payroll object but we could have attached GREEN to PAYROLL/CANADA or PAYROLL/USA. Had we done so, GREEN would have been granted access to exactly what is necessary to perform either Canadian or American payroll duties, and no more. For example, GREEN would have access to just Canadian or just American employees, payruns, and their transactions.

We mentioned that we gave GREEN access to JOURNAL/PAYROLL merely for completeness. GREEN already has access to the payroll transactions in several places. GREEN can access them in a payroll object for the entire payroll. GREEN can access all payroll transactions for each employee. GREEN can access them for individual employee accounts. GREEN can access them on individual payruns.

The payroll system is somewhat special because you do not manually add transactions on a journal. The transactions are added to a payroll journal, but they are added automatically when you process a payrun. Because GREEN will not add payroll transactions directly to a payroll journal, and because GREEN already has access to these transactions in many places, GREEN really does not need access to the payroll journal.

However, all payroll transactions are on the payroll journal and it is reassuring to be able to review them there so we have granted access to the journal.