What if the user leverages the Java or C api? What are you really trying to keep people from doing? Accessing the data or just viewing it in the user tool?
Axton Grams On Thu, Mar 10, 2011 at 1:19 PM, Mueller, Doug <[email protected]> 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: > [email protected]] On Behalf Of josepht > Sent: Thursday, March 10, 2011 11:07 AM > To: [email protected] > 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:[email protected]] On Behalf Of josepht > > Sent: Thursday, March 10, 2011 7:32 AM > > To: [email protected] > > 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 > >> <[email protected]>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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
