I have a feeling that this one could go on a bit. Far be it for me to break the chain...
We have separate accounts that exist solely for the purpose of users who have tcl access. Within those accounts, is a minimum of potentially damage causing verbs. But, if security is a BIG priority, the most potent method that I know of, is to make every 'attribute' that needs guarding, an itype, that is hooked to an 'attribute.security' subroutine that contains a test which returns the field's attribute number contents if the user can see all of the fields and maybe null if the user isnt supposed to see the contents. The sub parses everything in the sentence that is a LIST or SORT etc, throwing out key words and verbs. The security file contains allowed , disallowed ( or both), file names that probably can be keyed by user id or some class of users, such as a function oriented job code. Field 1 might contain strings of file.names that the user has even potential access to, and field 2, contains the attribute names, subvalued according to file name, or maybe an asterisk if the user can see anything in that file. Separate security is also placed upon the other VERBs in the account that could be used to side step attribute security (using VOC REC<1>=R, VOC REC<4>=*VERB.SECURITY.ROUTINE',) but verbs that would be really nice to have for those who have to maintain accounts... such as copy, ED (all the ED's maybe even EV) etc. And dont forget to delete or rename the EVAL keyword. So when the 'PAUL SARBANES (D-MD)' auditors come by and say, 'how do you PROPOSE to limit the view resulting from ad hoc queries, you can have an answer for them? . On 5/24/07, Susan Lynch <[EMAIL PROTECTED]> wrote:
Mark, In my early days of consulting, many years ago, I had a client whose CFO insisted that anything that I wrote that *could* be written in English (UniQuery under its original Microdata name) be written that way, even if it was less efficient, because then if it needed changing when I was not on-site, he could do it himself. After he was let go, I got a frantic call from his assistant - a million dollar order was "missing" on the system. Turns out he had modified one of my dictionaries and created his own version of a report to only show an order once, not on subsequent months, because the production team did not want to get flak from upper management about orders that had not yet completely shipped. It took me a while to figure out what he had done and fix it so that they did not suddenly find themselves losing track of the huge orders. It also appeared that some reports had been modified (either in the dictionaries or in the selection criteria) so that some cash audit reports were, shall we say, less than clear in terms of what was not reported. So, *that* kind of user (no inhibitions at all!) does need to be constrained, if only so that there will be documentation of what the system is doing after they leave the company! Susan Lynch F W Davison & Company, Inc. ----- Original Message ----- From: "MAJ Programming" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, May 24, 2007 11:41 AM Subject: Re: [U2] A question of dictionaries. >I should add a comment to your post regarding the user changing a reporting > column. > > This borders on a very slippery topic regarding the user's access to the > system. In my travels, many systems prevent their access to TCL. Those > that > allow access only give the users a very, very limited set of commands like > LIST and SORT and perhaps SELECt but never EDIT or BASIC etc. > > Plus the user's natural inhibitions prevent them from learning (retaining) > what they may see us typing. > > So I guess my question is what kind of 'user' could actually change a > reporting column to begin with. In many of my clients' systems there are > formal, menu-driven reports with specific indicators in the headings for > report identification. The users who make their own English report never, > never use HEADING so that would be my first sign of a renegade report. > > I don't use EVAL or other live dict items and I can't imagine the most > serious non-MV user crossing over that line. We programmers, having the > keys > to the entire castle, sometimes feel that the users are only one small > step > behind us. Everytime I think that they're near me, I'm reminded of how > contained they actually are. > > For over a quarter of a century I've been trying to show users the > simplicity of creating their own reports in English. I've found that you > can > lead a horse to water but you cannot make them drink. I've seen users > decline retaining education after attending Crystal Reports classes, Excel > Classes, Powerpoint classes and even MS Access classes. I don't think they > will take a liking to our dictionaries. > > My 2 cents > Mark Johnson ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
-- john ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
