Offhand thought... Are you using server stored preferences (so that the Tools->Options and View selections are stored in the AR System User Preferences form)? If so would a filter that forces those values to be the ones you want help?
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of josepht Sent: Thursday, March 10, 2011 7:32 AM To: arslist@ARSLIST.ORG Subject: Re: Muliple layers of Row Level access using Dynamic groups Currently we have similar workflow in place that does limit the tickets a customer sees. Customers have a default view that forces them to use a table with the status limitation hardcoded into it. And an Error message that displays if they reach a ticket that is not closed and they managed to see it somehow. But some of the more resourceful users have been able to get around these workflow limitations. These are normally the users who have been with us for a while and are dead set on recreating what they used to be able to do before we implemented row level access and started cracking down on security. Granted it is a small portion of our users that are being a pain at the moment, but they have demonstrated this security vulnerability that needs to be resolved completely before someone with malicious intentions discover it. We are currently trying to track down how they got past our restriction so we can fix the vulnerability. We hope as soon as we do that the problem will be eliminated but knowing some of the more stubborn users they will likely find another way. Currently it seems like we are in a sinking ship trying to patch leaks as they spring up.The best way I know of to lock them out would be with the row level access permissions as they would not be able to find a work around. The other thing that has been a thorn in our sides is the macro and advanced search bar tools which there seems to be no way of permanently disabling or resticting via permissions. Thankfully these are not an issue on the Mid-tier, but our management won’t allow us to take away the User application from those who have been abusing these tools. Right now, we have hidden or disabled these tools by default, but there seems to be no way from stopping a user from going to their view options and displaying the macro bar or going to their user options and enabling the advanced search bar. We can disable them again after they search with those tools, but not before the search actually takes place as we cannot seem to trigger workflow based on the users actions within that System menu and that System form. Thanks for the quick reply and we will look at implementing some of the options you suggested. Especially the computed group idea as that will help make our workflow a bit more dynamic. -----Original Message----- Jason Miller-3 wrote: > > Is it a custom app? > > Maybe you can create a console for the customer group users and a table > field that only shows resolved tickets by hard coding the status > comparison > in the table query? They will already have permissions to the records by > being a member of system1 and then you just limit their results to query > freely. This means either you A] do not allow table drill down and set > Display Only fields in the console so they can see all the data they need > (or open a detail report?) or B] allow them to open the Regular form but > do > not let them query directly from the form. > > Another idea is to have a hidden flag field that is set by workflow when a > ticket is Closed. Then have an AL that fires on Search with the > qualification being true if they are a member of a customer group (can be > a > computed group of all customer groups so you don't need to change "code" > when groups are added/removed). This AL automatically sets the flag field > and is used in QBE to only return record where the field is set and > matches > their criteria. This is not foolproof and not really a security control > however. They can still access all records they have permissions to via > ODBC (Crystal, Excel, Access). > > For a little better enforced workflow you could create a filter that > throws > an error and fires on Get if the Status < Closed and they are a member of > a > customer group. This is not a terribly elegant solution but would work > via > ODBC also. > > Jason > > On Wed, Mar 9, 2011 at 6:58 AM, josepht > <timothy.jos...@gunter.af.mil>wrote: > >> Oh forgot to specify we are using BMC Remedy AR System version 7.0.01. >> >> >> josepht wrote: >> > >> > We are trying to use Row Level access to limit users access to records >> > based on two different qualifications. >> > >> > For example: >> > User1 is a member of both the manager group and the system1 group. We >> want >> > him to be able to see all tickets for system 1 but not for any other >> > systems. (That part is easy enough and is being used currently.) >> > >> > User2 is a member of both the customer group and the system1 group. We >> > want him to be able to see only closed tickets for system 1 but not for >> > any other systems. >> > >> > For the part that is working currently we just have the system name >> > populate in a dynamic group and then give that dynamic group access to >> the >> > tickets. When trying to implement the part to allow User2 access to a >> > limited selection based on the status of the ticket within a limited >> > selection based on the system is where I am stuck. >> > >> > The only way I can figure to do this is by creating another set of >> groups. >> > Instead of a system1 group, we would set up a manager-system1 group and >> a >> > customer-system1 group. And then just use active links to fill in the >> > dynamic group with the manager-system1 group unless the ticket is >> closed >> > then we would put both groups in that field. >> > >> > This becomes a problem for us as we already have 9 user types like >> manager >> > that need to be limited similarly and over 100 systems. Making a group >> for >> > each type of user with each system would get complex very quickly. Also >> > every time we added a new system we would need to create 9 new groups >> for >> > it. The same goes for every time a system changes its name, that would >> be >> > 9 groups we would need to update. If we were to ever add a new type of >> > user that is over a hundred new groups that need to be made for it. >> > >> > While this is possible and manageable. I am looking for a more flexible >> > solution. Is there another way to do this by just using a combination >> of >> > the groups we already have? >> > >> > I thought I had it with a computed group with a Group Definition like: >> > “Manager” AND “Dynamic Group” >> > But sadly the system does not allow this. Of course I understand why, >> but >> > I can’t think of a way to do something like that on the tickets >> themselves >> > and not as a group.
