Wow that helps a lot thanks for the info. i've used the resevered fields before, i just didn't realize there was one for the advanced search bar. That will solve a lot of issues for us.
Is there a similar reserved field for Macros? I didn't see one in the list of reserved fields. And I am still looking for a way to do multiple row level access layers easier if it is possible. Mueller, Doug wrote: > > 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" > > -- View this message in context: http://old.nabble.com/Muliple-layers-of-Row-Level-access-using-Dynamic-groups-tp31106995p31120356.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"
