Re: Muliple layers of Row Level access using Dynamic groups
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-tp31106995p31107102.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"
Re: Muliple layers of Row Level access using Dynamic groups
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 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-tp31106995p31107102.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"
Re: Muliple layers of Row Level access using Dynamic groups
I may have over thought this in my previous reply... How about having another form that relates customer group to system (you probably already have one). Then have a filter would fire when the status changes to Close, look up the corresponding customer group for the system in a Set Fields and append the customer group name to the field being used to grant row level access. We do something kind of similar with a custom form where some non-IT people work on the requests. A requests comes to their group, they do their part and then transfer the request to the IT department for implementation. We keep appending the groups in the row level field so any group that has touched the request does not lose access. We do not currently use it, but we have a field for Read access in addition to Write access. We built in the option to grant the currently assigned group write access and other groups that have been assigned read access. You just need workflow to move the group names around to the appropriate fields at the request transfers. HTH, Jason On Wed, Mar 9, 2011 at 8:40 PM, Jason Miller 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 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 unders
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. 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 > 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 s
Re: Muliple layers of Row Level access using Dynamic groups
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 > 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 &g
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 s
Re: Muliple layers of Row Level access using Dynamic groups
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 >
Re: Muliple layers of Row Level access using Dynamic groups
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 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 Requ
Re: Muliple layers of Row Level access using Dynamic groups
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 s
Re: Muliple layers of Row Level access using Dynamic groups (Out of Office 12/20/10 - 12/24/10)
I will be out 12/20/10 and return back on 12/27/10. For Remedy issues, please submit a ticket and someone on the Remedy team will address. Regards, >>> arslist 03/10/11 14:06 >>> 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. > > >
Re: Muliple layers of Row Level access using Dynamic groups (Out of Office 03/10/11 - 03/14/11)
I will be out 03/10/11 and return back on 03/14/11. For Remedy issues, please submit a ticket and someone on the Remedy team will address. Regards, >>> arslist 03/10/11 14:19 >>> 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