Thanks Carey and David. I really appreciate the feedback.
Carey, I didn't think about it from a statistical information point of view. With the way it currently works an admin/developer has the option to show statistical information but still protect the actual record as you mentioned. If it were locked down to row level permissions this would not be an option, limiting design capabilities. The desired locked down result could be obtained by using the user's group list in the FB Variable qualification. David, thanks for confirming this is as designed (again your participation in this list is greatly appreciated). Your explanation of how it technically works helps. I do have a little trouble with understanding how defining the permission at design time (mentioned by both yourself and Carey) relate to the permission of the record data being displayed. The permissions defined in the admin tool grant right to see the flashboard object(s) but does not have any effect on record data being displayed in the FB, correct? This may be taken a bit out of context for flashboards and row level access but in BMC Remedy Action Request System 7.0 Concepts on page 101 there is the following section: The additive nature of permissions Access control in AR System is additive. Each user starts out with no access permissions; administrators then add permissions as needed. In this way, AR System implements strict access control. Administrators must make a conscious decision to grant access to specific groups on a case-by-case basis. I usually take the start with no access and grant it as needed approach. That may be why I was caught a bit off guard when I noticed this behavior. To look at the other side of the UNIX disk usage example... Now a list of valid user accounts has been created (possibly ordered by most active ones) that could be use to try an launch an attack on a system. Granted the list could show full name and not the actual username... I get your point, just a little bit of devil's advocate ;-) Jason -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Tuesday, September 11, 2007 9:19 AM To: [email protected] Subject: Re: Row level access with flashboards It is "as designed" and not considered a defect. The thing to keep in mind is that the admin user is typically the one doing the query [to be able to see information across multiple permission groups] for the flashboard (as defined at design time), not the user. Thus, since the admin can see all data, all the info is passed into the high level response that Flashboards use for display. As mentioned, the data itself is not available and is protected by row level security when users drill down. It's kind of like if you wrote a program (as root) that listed the users on a UNIX system with the highest disk usage for everyone to see - you would be posting high level information about each user (e.g. disk usage), but the users themselves could not see the actual data that was taking up the space. -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Tuesday, September 11, 2007 6:12 AM To: [email protected] Subject: Re: Row level access with flashboards Jason, I think that what you are seeing is "as designed". I hold this position because you can control the permissions (at design time) to the Flashboard object. So the developer has to have some ability to expose or hide the data for the targeted users. I think the real difficulty is that statistical information (like Count, Max, Min, etc) might need to be done across all of the application level restrictions for management to really get the whole picture for the business. So I can see a good argument for allowing Flashboards to show such things. However, when the user goes to "drill down" into the data, then I would think it reasonable for the results to be limited to the portion that the individual user has access too. Example: Flashboard to show number of order that are 4 or more days old that are not yet "Sent to the customer". I would think that the President would have enough access to see all order from all departments. So when they drill down they see the whole picture. However a head of a department might only see the orders from their department when they drill down. I would also suspect that the Group By clauses would likely match (very well) to the logical restrictions that the application imposes too. So there likely would only be one "department breakdown" (er.. Group By element) that a given Department head could drill down on and get a non-zero list. However, I also think there is value in letting the Department heads see the counts for the other departments too. I do see how the design you were expecting could be useful too. I am just not sure how to achieve it short of making Flashboard a total "Run Time" calculation. ( Which it is not in the current design.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 9/11/07, Jason Miller <[EMAIL PROTECTED]> wrote: > ** <snip> > I realize that I could update the FB's to query the user's group list > but my current mission is to see if I am seeing the as designed > behavior or is this a bug. This may be a good gotcha to know about when designing flashboards. > > > > Thanks again, > > Jason ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
