I'm not sure this would work, but what if you created the file as a distributed file with 2 parts: part1 = 'public' data, part2 = 'secure' data.
Those without security clearance would open just part1 and those with security clearance would open the distributed file which would give them access to both part files. How you do that in coding shouldn't be too difficult especially if you use named commons, I think. This is kind of a hybrid approach I just thought of based on the other suggestions. Also, some of the law we have would require the two partfiles to reside on different disks... HTH, Karl <quote who="Augusto Alonso"> > Thanks Baker. > Your suggestion is very wise, but the downside is too hard. > In fact, > The Dave's approach (@ENVVAR/PRIVATEFILE) would fit better for us, but... > > ...I've tested it, and it doesn't work at all in UniVerse (neither under > windows nor under linux) > I was thinking in a pointer-like sollution, so that the code remains > unchanged. > > ----- Original Message ----- > From: "Baker Hughes" <[EMAIL PROTECTED]> > To: <u2-users@listserver.u2ug.org> > Sent: Wednesday, November 28, 2007 11:47 PM > Subject: RE: [U2] Need to partially hide a file > > >> Augusto, >> >> sort of along the same line of thinking as Dave ... play with the user's >> logon as soon as they login... >> >> Modify your LOGIN VOC item so that it: >> a) Checks a Data Security flag for that specific user [ @logname = Item >> ID in DSA.Flags file] >> b) Open the Cust.Secure.Data file to a named common in a short program >> if they have clearance >> c) If they don't have clearance Open the Cust.Skinny.Data file to the >> same file name in the named Common >> >> The named common will follow the user to whatever account they logto (if >> you log them around in the app or if they can Logto). >> >> Downside: You will have to modify the code where you are opening this >> file in the App, since it will already be opened. >> >> BTW - This approach should meet PCI compliance, and others, since you >> are making a positive grant of access based on the User logon (rather >> than role based or menu based security). I would check the language of >> the controlling standard - sometimes they hint at the approach they want >> you to take. >> >> HTH, >> -Baker >> >> <snip> from Dave >> Another approach is the following: >> >> In UniData this could be done by using environment variables, and >> assigning the variable with different values for some users than for >> others. For example: >> >> F >> @ENVVAR/PRIVATEFILE >> D_PRIVATEFILE >> >> User "A" (privileged) could have it set to C:\private. User "B" could >> have it set to "." >> >> I don't know how much trouble that is to set up for windows users >> though. >> </snip> >> >> <snip> Augusto: >> We need to hide some private data (customer personal data) in order to >> fit with our Private Data Protection Law. >> But only for some users, the others, they need to have full access. >> Our app is complex enough to modify the source code. >> <snip> >> ------- >> u2-users mailing list >> u2-users@listserver.u2ug.org >> To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > -- Karl Pearson Director of I.T. ATS Industrial Supply, Inc. [EMAIL PROTECTED] http://www.atsindustrial.com 800-789-9300 x29 Local: 801-978-4429 Fax: 801-972-3888 "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
