Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Extending the Framework...
Message
De
04/06/1998 11:59:40
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
The Mere Mortals Framework
Titre:
Extending the Framework...
Divers
Thread ID:
00104792
Message ID:
00104792
Vues:
73
He all.. would love to get your comments, ideas, class library donations to solve the following issues with CBMM...

Activity Log

Basically the an entry is created in the activity log every time a user selects a menu item or toolbar button. The following information is captured in the log…

Date, Time, Menu/Button Option, Resource, User

Audit Trail

An entry is created in the audit trail log when a item that is stored in a table is modified. Prior to the audit being written the data dictionary is check to see if the data item is to be audited. The following information is captured in the Audit Trail Log…

Date, Time, File Name, Field Name, Key Value (of record being modified), Employee Name (if the file is an employee file), OldValue, NewValue,Window Name, User

Data Dictionary / Editor

The data dictionary contained the information for the structure of every file and index. It also contained extended information such as descriptions for every field, field and index, file type… it also included info for each field indicating is the field was to be audited, if it was required, and if it was validated (looking up it valid rules in the validation table.

The ‘Database Editor’ was screen set / program that presented the data dictionary to the user to allow them to edit the file information. Any changes made that modified the structure of the files was also performed to the files.

Stonefield has been suggested/looked at, but what happens when moving to SQL.. will it still work?

Data Validation

A validation table existed to define the validation of every data item in the database. The validation table was user editable. The types of validation that could be defined for a field were:

Set – the table included a list of codes and there descriptions… the ‘set’ records were used to validate the field and provide the description label for the field on the screen and in pick-lists.

Table – the would compare the value of the field with a specified field in a specified table. For example, employee number was validated against eemast.empnum.

Range – self explanitory

Pointer – basically allowed you to point the validation of a field to the validation of antoher field. So, if you used State you didn’t have to list all the states as sets every time you used state.

Menus / Tools Bars…

(The tool bar in TotalHR was actually called a ‘button bar’)

User defined menus and tools bars. In TotalHR the menus and tool bars were defined in a table. An editor was provided for the tool bar and the menus so that the user could modify them. The definition included a security level for each menu item and tool bar button.

Security

After reading through setting up the security in Mere Mortals, it seems like the ‘access’ items are all hard coded onto the users’ form. This is too much work and would cause many problems with allowing for end user customizations.

I suggest that we use the SAVI security methods (class). These are described in the Codebook Newsletter Volume 2 Issue 2….

Basically every interface control is given a security name. All security names are then placed into a database. The administrator can access a ‘security’ list for each user… all security names are listed for each user. Each security name has a edit and a visible checkbox (similar to CBMM double checkbox).

It is also not necessary to define security for every user. Groups can be created… the security set up for the group, and then users are placed into the groups.

This security would have to be extended to Menus and ToolBars also. (best way, not as good, we give the forms security names)

Misc

I know a lot of the above has to be considered carefully… Since we want to be able to deploy this as a 3-Tier ap we have to evaluate whether security and such should be interface driven or data driven. For example.. if we set up interface based security, doesn’t that mean the anyone accessing the middle tier with a different front end would have to set up interfac security. Or… do we not worry about that, relying on the users to implement security in MTS and SQL as their needs require?

It seems to me that if the security is driven from metatables in a data dictionary, the business object would not pass information to the front end if the user does not have access to it. Also, what happens in the case the the user does not have access to the back end data, yet the front end provides access to the control? Will this cause errors?


************

Thanks for any advice you can give.

BOb
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform