Situation:I have a Request form that is used to request usernames and passwords, of varying security levels, for one to many different employees. I have an Employee form, not a response doc, that contains information about each employee. The Request form has a single category embedded view showing the Employee documents affected by that request. The embedded view is fairly active with records/categories being added and changed regularly. If I open up the Request form and leave it open long enough (from 2 minutes to 15, seemingly depending on the view activity) the single category view data will change to a DIFFERENT category.
This is VERY BAD. The result could be that an employee will get a more significant security clearance because the embedded view values changed midstream. I realize that I can probably do some Reader field workarounds for this, but my worry is in the use/functionality of even using single category embedded views
IBM’s response:
The issue was duplicatable in client version 5, 6 and 7. My SPR for the issue is IBM Support PMR 39045,227,000. No known workarounds. Still no word on a possible fix.
My question.
This seems to me to be too big a hole not to have been noticed before. Am I missing something? If not, everybody should take heed, 'cause this bug could really invalidate the use of single category embedded views
Hope I’m just panicing unneccesarily and someone can ‘show me the way’
Subject: Single Category Embedded Views Broken??? !!!
I think that what you have to remember is that restricting the view is NOT security - it’s more of a convenience.
If your users know anything of Notes, they can simply hold down CTRL+SHIFT while they open the database or select View - Go To, and then select the view which you’ve embedded. This now gives them access to ALL views.
Proper security would REQUIRE readers fields if the users are to view only a subset of the documents in the database.
Readers fields AREN’T a work-around. they ARE THE SOLUTION.
Subject: RE: Single Category Embedded Views Broken??? !!!
Thanks for your response, Peter, but in this cast that is I disagree. There is nothing in the Employee form that needs to be secure. In fact, an Employee document can often appear in categories for multiple requests. one request for high security access to this application and another for average access to another application.
The problem is not with people reading the access requests of others. It’s the fact that if the security person pulls up a request to grant you access to an application, answers the phone, then looks back at the request. your name might be replaced with my name (or anybody elses) by magic. If the security person does not notice, then I get the access that you should have had, and you get nothing. This would be a problem for ANY application.
The reason people use single category embedded views (SCEV, I’m tired of typing that whole name) is to show only the subset of a set of documents that pertains to a specific instance. If SCEV cannot be relied on to do that or, much worse than that, presents WRONG data instead of just not working, the feature is not a feature but a problem and should not be used. Better no information than wrong information.