>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…

I haven't really looked at menus yet, but what about logging of buttons contained on forms?

How about subclassing the existing controls and adding a property that is a description of the button function that you set as you create your forms. Then add some code to the Click method to call your activity class and record this info.

>
>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…

I don't think this would be too hard for simple objects, just drop a call to your audit object in the PreSaveHook method of your objects. But then what do you do when your using something like a grid? The user can potentially make a lot of changes to your table.

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

Hmm. I thought they had a SQL version...for something like this I think a specialized product is a much better idea.

>
>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:
>

Shouldn't all of this be handled on the back-end - either VFP or something like SQL Server? It sounds like a lot of overhead.



>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….

Yeah, I really like the set-up of it. Very cool.

>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?

I would think you'd want security in both the front end, and the SQL back end. You don't want people just to completely bypass your programs to query data directly from the database. In VFP, if you're using remote views you're already passing this security information to gain access to the data.

My guess is that a security class in VFP would keep a user from gaining access to the methods/properties contained (and available through) your business object. The only way users have access to these PEM's are through your interface so this is where I'd put the security. If you've got other front ends accessing your business objects they'll still need to provide your objects with the login information needed to gain access to the database, unless you're hardcoding that in your views.

>
>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?

Your front end needs to tell the middle tier what/who the user is so that this information is passed to the backend for validation. If it fails, they won't have access. At that point it's the job of the front-end programmer to make sure they define access to their controls that are consistant with the backend validation rules (ie don't let them have access to controls that access business objects that the user doesn't have rights to - it's going to fail on the backend anyways).

Of course, I'm hardly an expert at any of this (just look at the kinds of questions I've been asking here). Just my opinion.