Joseph, Actually....
If you put a field on your form that is a display-only, character field (length doesn't really matter, but set to 0 just to be complete) and give it field ID 1005, it will hold the contents of the Advanced Search bar. This is regardless of how that bar is turned on. Make this field available to all users. DO NOT put it in the view (to prevent any possibility of the customer accessing it directly to try and override things -- which they cannot do anyway since it is a linked field to the Advanced Search bar). You could then have On Query (or is it called On Search) active links see if that field has a value in it or not. If it has a value, you could issue an error message and stop the search telling the user they should not be using the Advanced Search bar. Make the permissions of this active link public as well so it applies to everyone (or if there is a specific group you DO allow to use Advanced search, set up permissions or qualifications appropriately so that the workflow fires for everyone who is not supposed to use the Advanced bar). There is no way that the customer can work around this test regardless of what they do. NOTE: I am just describing a technical capability not commenting on the overall solution. I just wanted to call out that there IS a way to get access to the Advanced Search bar contents and you are allowed to test it before a search is issued. By the way, check out the topic "Form action reserved fields" in the documentation for a discussion of this field ID and the other dozen or so special field IDs that if you use them and put fields on your form, you can control various aspects/buttons/operations of the system by both having them anywhere on your form and by having workflow operations on them control the system function availability. Just goes to show that there are often ways to protect/block even those who are "experts" in working around things! I hope this helps, Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of josepht Sent: Thursday, March 10, 2011 11:07 AM To: arslist@ARSLIST.ORG Subject: Re: Muliple layers of Row Level access using Dynamic groups That is what we are currently doing, but the AR System User Preferences Form is slightly different from the Tools -> Options Form. We can set the default values and then make the fields read-only on the AR System User Preferences Form and the value will be set on both but the read-only option does not. The same applies to things like disabled and hidden. So if the user was to try to change their preferences on the AR System User Preferences Form to something we don't want, then they can't. Unfortunately there is nothing stopping them from changing this option in the Options Form. If a user was to enable the Advanced Search Bar using the Options Form, then click OK the change would take effect on the next form they open. There is no trigger that I have found that will fire based on what happens in the Options Form. Of course we do have an active link that fires on open of the new window that just sets the values of these fields back to what we want them to be, but it does not take effect until the next time they open a window. This does not remove the Advanced Search Bar that would be at the bottom of their current screen. There is no way that I know of that would stop this Advanced Search Bar search without also stopping every search, since there is no way to determine it the search was made with or without it. Macros are even worse. Wish remedy would make it easy and just give us the option to enable and disable these menu items like we can with the delete and search menus. That way they would be just grayed out menu items that don't work for certain users. Grooms, Frederick W wrote: > > 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. > > > > -- View this message in context: http://old.nabble.com/Muliple-layers-of-Row-Level-access-using-Dynamic-groups-tp31106995p31118741.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
