I would love to have functionality like that - I would want to have a demo-user login, where the data is scrambled.
Still, that solves only part of the problem - in fact I want the demo user to be able to play through data-entry as well, and that cannot be solved without a demo-database in the background I would think. But maybe being able to show just half of the functionality is better than showing none? regards, Martin On Wed, 19 Jan 2005 11:06:41 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > Good point. It looks like I'll be just implementing this for myself > but I'd appreciate input from the list. > > You could always have two attribute. One that indicates general > obfuscation (replaces each character with '#') and one where you can > specify the number of dummy characters to use (for salary case). > > Also, general obfuscation method could only replace alpha numeric > characters (would ignore characters such as ',' and '-'.) That way > the social security number would still have '-' in it (which would be > desirable IMO). > > On Wed, 19 Jan 2005 09:56:22 -0600, Nail, Evan Burke > <[EMAIL PROTECTED]> wrote: > > I've worked on a small HR system and we ran into this type of problem. On > > demos yes, but mostly on tracking down data related issues we would often > > need the production employee data in test without the sensitive information. > > We ended up incorporating some data manipulation methods when copying the > > db down to our test environment. Kind of like data obfuscation. Much more > > complexity was generally needed that just performing a char replace at > > display time. I can't think of all the examples but a couple would be.. > > > > For example ( not that this is what you are doing of course) but assume > > your demoing a list of employees salaries and you display John Smith and > > Jane Doe's salaries as #,###.## and ###,###.## Even though you can't see > > the amount the difference is obvious. Now John jumps across the conference > > table during the demo and smacks Jane..there's a lawsuit..your demo is > > ruined. > > > > Plus we had lots of search items on SS# . Displaying the SS# is perfect for > > your scenario because of it's uniformity, but we had lots of search fields > > that used the SS# so even typing that in during a search demo would cause > > issues if it wasn't switched to some set of random numbers. We wrote some > > stuff that generated the ss# and other keys and was able to propagate them > > to keep all the PK, FK relationships with the new fake data. > > > > Anyway, not that these are your issues, but just a few things to think > > about. It's more work of course, but I'd advise a demo database with > > scrubbed data. > > > > bn > > > > > > -----Original Message----- > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 18, 2005 4:36 PM > > To: MyFaces Discussion > > Subject: Re: Idea for new "privacy" feature > > > > I am leaning towards that conclusion. We'll leave this thread up here > > and see what others think. There isn't really any harm in including > > it in MyFaces. It would be another attribute that you could add to a > > tag and a few custom renderers. Not a big deal really. > > > > On the other hand, if this is really something only I care about. Why > > subject anyone else to it ;-) > > > > On Tue, 18 Jan 2005 14:31:58 -0800, Travis Reeder > > <[EMAIL PROTECTED]> wrote: > > > I think you should just create your own custom components to add this, > > > definitely not something that should be in MyFaces. > > > > > > Travis > > > > > > > > > Sean Schofield wrote: > > > That's a bit difficult in my case. I have a perfectly functioning > > system > > > already with real data. Suppose I don't want to add fake data > > to my > > > production system. Also, the data is in a lot of different > > tables with > > > foreign keys, etc. Finally some of the data tables are > > not under our control > > > - we just read from them. > > > > On Tue, 18 Jan 2005 16:16:41 -0600, Heath > > > Borders > > <[EMAIL PROTECTED]> wrote: > > > > > You can't just create dummy data? > > > > On Tue, 18 Jan 2005 17:13:38 -0500, Sean > > > Schofield > > <[EMAIL PROTECTED]> wrote: > > > > > What do you think about this idea ... > > > > Our current application at work uses > > > very sensitive data. I've often > > wanted to show the application to other > > > clients but I don't want any > > of this data to be shown. > > > > Maybe we could > > > modify the ext tags to provide a "private" attribute > > (true/false.) Then > > > supply some custom renderers that could render a > > private version of the > > > data. > > > > So for example "Sean Schofield" could become "#### #########". > > > > Would > > > this be useful for anyone else besides myself? I'm thinking it > > could also be > > > used to generate screen shots for user guides. > > > > Thoughts? > > > > sean > > > > -- > > -Heath > > > Borders-Wing > > [EMAIL PROTECTED] > > > > > -- > > Travis Reeder > > Ecommstats Web Analytics > > www.ecommstats.com > > > > > > ********************************************************************** > > This e-mail is the property of Enron Corp. and/or its relevant affiliate > > and may contain confidential and privileged material for the sole use of > > the intended recipient (s). Any review, use, distribution or disclosure by > > others is strictly prohibited. If you are not the intended recipient (or > > authorized to receive for the recipient), please contact the sender or > > reply to Enron Corp. at [EMAIL PROTECTED] and delete all copies of the > > message. This e-mail (and any attachments hereto) are not intended to be an > > offer (or an acceptance) and do not create or evidence a binding and > > enforceable contract between Enron Corp. (or any of its affiliates) and the > > intended recipient or any other party, and may not be relied on by anyone > > as the basis of a contract by estoppel or otherwise. Thank you. > > ********************************************************************** > > > > >
