Introduction

§1 Some preliminary concepts

OrganiZATOR rest over three concepts whose understanding is crucial to get real benefit and avoid the risk of believing that the application is possessed by the devil at a given point. These are:

User (and its associated concept Access Level)
Application zone
Working area

§2 Users

To use OrganiZATOR it is necessary to access as a registered user, and each user has:

Username
Password
Type/Access Level.. These terms are equivalent and define the privileges (what the user can do).

There are 4 types, each with different privileges, which are fixed for each type.

Level	Type (alias)	Privileges
4	Guest	Read-only options; can not perform actions involving delete, create or modify data. You can create as many users of this level as desired.
3	Owner	It is the ordinary user. It can create and modify items. You can create as many users such as may be required.
2	SuperUser	You can hide certain data (encrypt) and have access to them (this information is not accessible to the types 3 and 4) [1]. Including the prerogatives of the previous levels plus some its own. There can be only one super user in each database [2].
1	System operator (SysOp)	It can create and modify users. Including the prerogatives of previous levels. There can be only one system operator in each database [3].

As can be seen, the lower levels have more privileges than to the highest. The highest privilege level (1) corresponds to the System Operator.

By default there are four users, one of each type, whose names can not be changed or deleted. It is advisable to change its initial default passwords by other (see Access Keys), but remember that if you lose the System Operator's password you may lose some data. Names and passwords for these defaults users are indicated:

Level	Type	User name	Password
4	Guest	guest	guestusr
3	Owner	owner	DISABLED
2	Super User	super	superUsr
1	System Operator	sysop	sysopPsw

Note: Both the username and the Password are case sensitive.

If the password of the Owner is equal to "DISABLED", then the application does not ask for a password to access as Owner (level 3). In other words, anyone can create and / or modify items in the database (as you can see, by default everyone has full access, read/write, to the database). Similarly, if the Guest's password is equal to "DISABLED", then no password is required to access as a guest, and anyone can log to see the contents of that dBase.

Note: when the password = DISABLED, we say that the access as Owner or Guest is public. Accesses as Super User and System Operator may not be public in despite of the value used for their passwords.

For each dBase there can be only one Super User and one System Operator (SysOp); however there may be as many users with Owner and Guest privileges as desired. The access conditions of each dBase are separate, and distinct from those who may have other dBases defined in the system [4].

Figure 1.

Figure 2.

Figure 3.

§3 Zones

The application has three different zones:

Initial (main): is displayed when starting the program (Figure 1). It contains several options, including access to the other two: Scheduler and dBase. From here you can access to some support utilities, as Notebook; defining work areas; initial parameters; creation of users; definition of frequent used data; definition of executables, and so on.
Scheduler includes Appointments; Expiry Dates; Pending try, and Ephemeris (figure 2). Everything that composes a planner, as well as the Zator messaging system (Sent messages; messages Inbox and messages Outbox).
Database (dBase): heterogeneous information in areas not covered above (Fig. 3).

Keep in mind that OrganiZATOR is an application rather ubiquitous and that at any given time, each zone of the application may be using a different work area (see below). For example, the scheduler might be showing data planning of your boss, which are located on a computer in the office next to yours; and the dBase may be looking at the database of customers, a file located in any of the network. While the Notebook that has opened, contains yours own notes; data stored on your computer, in the same directory as the file zator5.exe who launched the application.

§4 Work areas

The concept of work area is related to the fact that Zator is a distributed database that can use storage units (databases) located in different places. Each of these Zator dBases (zBase) is reflected in a zDB1 file housed in a directory somewhere in the intranet (LAN), and provides a work area. Every zBase can be accessed locally by the executable located in the same directory (for which serve as local area), or remotely by an executable launched in a different directory (in the same node or another point of the network), in which case it acts as a remote area for that executable.

What better explain with an example: suppose an office with a professional chief and his secretary; there are two computers connected to a small LAN of two nodes; BOSS is a computer and the other HELP. Installs OrganiZATOR in, say C:\Zator\ in each node (two installations) and both directories are visible from the other node.

When start the application in their respective computers, both the chief and his secretary are in their local area, using respectively the dBases \\BOSS\C\Zator\zDB1 and \\HELP\C\Zator\zDB1, but defining working areas properly, each one can connect with the other dBase (remote to him), so that from the connection, things happen as if they were physically sitting on the desktop of the other. Simultaneously, it may have set a third work area in another situation, which could be a specific directory of the BOSS machine; the HELP machine, or a third connected to the network. Latter directory in turn contain other zBase (file \\SOME\place\zDB1) who act as a remote area for both users. The creation of this, or other similar areas, it does not require a new installation of the application, and can be performed from any of the stations mentioned. The connection to a remote area of work is reversible, so that at any time you can go back to your local area, or jump to another of which the network has identified.

As expected, this ubiquity is complemented by an access system in which can be defined who can access each area, and how (what level). We can advance here that the process is to define in each zBase a list of users have access to it, and the level assigned to each. As stated above, the process of creating new user is only allowed to the System Operator .

Each zone of OrganiZATOR provides a menu option to change its work area. The option for the main zone is in Utils-1 >> Select work area of the menu bar, and also the button in the toolbar of the main window. The windows of the scheduler and dBase have a corresponding option work area in its menu bar. Options presented by the mentioned changing menus are the same for the three zones, and must be defined by the user through the appropriate option (Maintaining work areas).

Because they are independent of one another, at any given time, every zone of the application (main, dBase and scheduler) can be connected to the local work area or any other, so that the user can be working simultaneously on 3 different areas. In any case, some initial options in the main zone are always executed on the local dBase whatever what work area is connected.

Main options that are always executed using the data contained in the local area:

Notebook

Menu to run executables

Menu to send messages .

Security routines (save backup and restore backup).

Menu to connect with other work areas

Define page of Frequent Used Data.

See page of Frequent Used Data

Main options that run on/uses the data contained in the currently connected area (local or remote):

Maintenance routines (Check integrity; Rebuild & Compact; Reindexing).

To define Work Areas.

To define Commands Catalog.

To define Messaging Addresses.

Create user.

Erase user.

To define passwords for the standard users (Guest; Owner; SuperUser and SysOp).

To define initial parameters (settings).

Top.

[1] The choice of encrypt/decrypt fields is not available in this version.

[2] The SuperUser of each dBase can be the person who has it in its local area (its default directory), or the person directly responsible for its maintenance. Usually you access to yours dBase as Owner, but for certain actions you should access as Super User, whose privileges will allow you to access certain options who are vetoed as Owner.

[3] Ideally, the System Operator (SysOp) of all dBases defined in a facility, LAN in the office, department, business, etc., should use a single password; the same for all of them, which will be entrusted to the maintainer of the system; network administrator or similar. The idea is that there may be only one responsible for security, integrity, and political of use in the installation.

[4] Although not required, it is desirable and practical to maintain a certain consistency in access protocols of the various dBases that may exist in the system. In other words, use the same username and the same password in all the bases to which a user has access (see that Zator facilitates this control because in defining new areas, the new ones will inherit the user profiles in the station from which the expansion takes place).

Top