**
Hi JD:

My apologies for the late reply. Was busy troubleshooting some other problems that arises.

Your solution sounds simple enough to implement, but unfortunately it probably does not fulfill what i'm trying to achieve here. I have a form, let say a helpdesk form, that i would want to restrict user from searching on it. What i do is i'll allow them to see their own ticket through Remedy Requester, Remedy Support and Remedy Management.

When i try out the option of disabling search through an Active Link that says Operation = " QUERY" or Execute on: Search, it will then generate an error when the request is open from a VIEW button under the Remedy Requester Console. I check this through the Active Link log and found that this occur as an OPEN WINDOW action has triggered a QUERY condition which then prevented the ticket from being display.

Alternatively, what i need to do is to prevent the user from pressing F5 on the keyboard or from performing an advance search when opening the Helpdesk form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar cannot be disabled from the Admin tool under Properties -> Menu Access.

Any suggestions/advice would be deeply appreciated. Thank you!

"J. D. Hood" wrote:

I'm going to presume a couple of things here:

1. This search restriction mainly applies to the general user community.
2. There are one or more group(s) that may have a need to access all
records, so the search restriction should *not* apply to them.
3. All users have to identify themselves to the system, either by a login or
something -- there are no anonymous users.


If those presumptions are correct, and I do hope I've understood the problem
accurately, this seems to me like a run-of-the-mill row-level access issue.
If so, you may want to check the Admin guide for "Controlling access by
using implicit groups ?row-level security".

Basically, all you have to do is control permissions on the Request-ID field
(field ID# 1). For example, if the user's name is in the submitter field,
and the Request-ID field permissions only has the "Submitter" group, then
the submitter is the only person from the general user community who can see
that record. Of course, you would add any other appropriate group(s) to the
Request-ID field permissions (like "Human-Resources" or "Personnel
Management" groups, or whatever). You just have to be carefull not to add a
group with a broad membership that may include members who would otherwise
be restricted.

As for users running HUGE searches, that can be handled via configuration
settings limiting the max rows and/or workflow that "AND's" something into
the ASB. So you can reassure your admin that he has no worries.

-jd-



On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:

>
>Hi there:
>
>Great point. Thanks for all the tips. I believe option 1 on the allowing
search on the request ID may not work for me as the table can display any
request ID. Perhaps i need to carefully think of the logic to be used...
>
>As for option 2, the dialog box option sounds interesting. Something
worthwhile testing.
>
>As part of other people's advice(thanks to both James), James Smith
suggestion on selecting a particular VUI might seems to be the easiest way
to accomplish it(i'll test it out).
>
>As for preventing object list, one other question that i have in mind is
that, do i then have to enroll everyone into the AR System user preference form?
>
>Allow me to explain further why I would need to disable search on a
particular form. The reason why we are doing this is because:
>
>1.)it contain sensitive data, and we are trying to prevent people from
seeing someone else's record
>
>2.) our admin are concern that in future allowing search(without a proper
indexing) might slow down the system considerably, especially when we’re not
running on a high end server(1GB RAM, Single Intel Xeon processor)
>
>Hope this provide a clearer picture. Once again, Many Thanks to all of you.

>
>Warmest regards,
>EK
>
>
>"J. D. Hood" wrote:Have you considered modifying your
active-link stack that prevents searching
>to account for the request-ID that you are opening in the table?
>
>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>
>Or open the table record in dialog mode? You could copy the form to
>dlgOriginalFormName. Then you would have a seperate form that is usd to
>display the record.
>
>It might help if you explained the busniess reason behind blocking searches.
>Are you trying to prevent people from seeing someone else's records? Are
>there certain parts that are confidential on all records? What's the overall
>goal that you are trying to accomplish? Without an understanding of the
>requirement, there's usually quite a bit of "Braille Method" involved in the
>solution.
>
>-jd-
>
>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>
>>Hi All:
>>
>>Thank you for all your advice. I think i've created some confusion along
>the line, my apologies.
>>
>>Initially, when i have created the Active Link to prevent other people from
>searching an ITSM form, it works as it will check for the user's permission
>and allow them to search if they are an administrator.
>>
>>I started facing problem when i test out on a TABLE field that i've
>created, where the VIEW button will perform an OPEN WINDOW operation that
>opens it up in a DISPLAY mode. However, when i click on that, if the user
>does not have sufficient permission, will now get the error from my Active
>Link. If my table allows drill down, it does not have the same error.
>>
>>Thus what i would like to achieve is to allow my VIEW button to be able to
>open up the form, without getting the error. I'm not using a macro.
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>
>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)



Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com This posting was submitted via the Web interface

Again, I guess it goes back to "why" you want to do this What's the
definition of the problem you are trying to overcome?

>From what I can gather, you want to restrict the users from seeing any
tickets except their own. If that's correct, then "row-level-access" should
do what you are looking for. An "$OPERATION$ = "QUERY" active link would not
be needed and you could delete the one you've built. The user can hit F5 all
they want, and they will only be able to see their own records. In other
words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
Panel), if they don't have permission to the Request ID field, they don't
get to see the record. Row-Level-Access will only allow them to see their
records by selectively granting access to the Request ID field on a record-
by-record basis. Well, I'm presuming they can't bypass the Remedy API and go
straight to the DB tables.

However, there's the distinct possibility that I'm way off in left field and
have completely misunderstood your problem. If so, I apologize. If you only
want to restrict a user's ability to search "sometimes", and at other times
allow the same user to to see all records, then yes, you have a much
different problem. But it's likely not an insurmountable problem. We just
have to define the problem.

-JD-


On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:

>Hi JD:
>
>My apologies for the late reply. Was busy troubleshooting some other
problems that arises.
>
>Your solution sounds simple enough to implement, but unfortunately it
probably does not fulfill what i'm trying to achieve here. I have a form,
let say a helpdesk form, that i would want to restrict user from searching
on it. What i do is i'll allow them to see their own ticket through Remedy
Requester, Remedy Support and Remedy Management.
>
>When i try out the option of disabling search through an Active Link that
says Operation = " QUERY" or Execute on: Search, it will then generate an
error when the request is open from a VIEW button under the Remedy Requester
Console. I check this through the Active Link log and found that this occur
as an OPEN WINDOW action has triggered a QUERY condition which then
prevented the ticket from being display.
>
>Alternatively, what i need to do is to prevent the user from pressing F5 on
the keyboard or from performing an advance search when opening the Helpdesk
form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
cannot be disabled from the Admin tool under Properties -> Menu Access.
>
>Any suggestions/advice would be deeply appreciated. Thank you!
>
>"J. D. Hood" wrote:
>I'm going to presume a couple of things here:
>
>1. This search restriction mainly applies to the general user community.
>2. There are one or more group(s) that may have a need to access all
>records, so the search restriction should *not* apply to them.
>3. All users have to identify themselves to the system, either by a login
or
>something -- there are no anonymous users.
>
>
>If those presumptions are correct, and I do hope I've understood the
problem
>accurately, this seems to me like a run-of-the-mill row-level access issue.
>If so, you may want to check the Admin guide for "Controlling access by
>using implicit groups ?row-level security".
>
>Basically, all you have to do is control permissions on the Request-ID
field
>(field ID# 1). For example, if the user's name is in the submitter field,
>and the Request-ID field permissions only has the "Submitter" group, then
>the submitter is the only person from the general user community who can
see
>that record. Of course, you would add any other appropriate group(s) to the
>Request-ID field permissions (like "Human-Resources" or "Personnel
>Management" groups, or whatever). You just have to be carefull not to add a
>group with a broad membership that may include members who would otherwise
>be restricted.
>
>As for users running HUGE searches, that can be handled via configuration
>settings limiting the max rows and/or workflow that "AND's" something into
>the ASB. So you can reassure your admin that he has no worries.
>
>-jd-
>
>
>
>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>
>>
>>Hi there:
>>
>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>search on the request ID may not work for me as the table can display any
>request ID. Perhaps i need to carefully think of the logic to be used...
>>
>>As for option 2, the dialog box option sounds interesting. Something
>worthwhile testing.
>>
>>As part of other people's advice(thanks to both James), James Smith
>suggestion on selecting a particular VUI might seems to be the easiest way
>to accomplish it(i'll test it out).
>>
>>As for preventing object list, one other question that i have in mind is
>that, do i then have to enroll everyone into the AR System user preference
form?
>>
>>Allow me to explain further why I would need to disable search on a
>particular form. The reason why we are doing this is because:
>>
>>1.)it contain sensitive data, and we are trying to prevent people from
>seeing someone else's record
>>
>>2.) our admin are concern that in future allowing search(without a proper
>indexing) might slow down the system considerably, especially when we’re
not
>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>
>>Hope this provide a clearer picture. Once again, Many Thanks to all of
you.
>
>>
>>Warmest regards,
>>EK
>>
>>
>>"J. D. Hood" wrote:Have you considered modifying your
>active-link stack that prevents searching
>>to account for the request-ID that you are opening in the table?
>>
>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>
>>Or open the table record in dialog mode? You could copy the form to
>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>display the record.
>>
>>It might help if you explained the busniess reason behind blocking
searches.
>>Are you trying to prevent people from seeing someone else's records? Are
>>there certain parts that are confidential on all records? What's the
overall
>>goal that you are trying to accomplish? Without an understanding of the
>>requirement, there's usually quite a bit of "Braille Method" involved in
the
>>solution.
>>
>>-jd-
>>
>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>
>>>Hi All:
>>>
>>>Thank you for all your advice. I think i've created some confusion along
>>the line, my apologies.
>>>
>>>Initially, when i have created the Active Link to prevent other people
from
>>searching an ITSM form, it works as it will check for the user's
permission
>>and allow them to search if they are an administrator.
>>>
>>>I started facing problem when i test out on a TABLE field that i've
>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>does not have sufficient permission, will now get the error from my Active
>>Link. If my table allows drill down, it does not have the same error.
>>>
>>>Thus what i would like to achieve is to allow my VIEW button to be able
to
>>open up the form, without getting the error. I'm not using a macro.
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

**
Hi JD:

Sorry, guess after so many rounds of email interaction i still has yet to firmly articulate the problem that i need to overcome and the reason why i need to do so. Basically, it is the company's policy that people should not be allow to see other people's ticket apart from their own department's ticket.

Thus the way we organize it is to allow them to view their own tickets and their own department tickets through table qualification(using qualification such as 'department' = $department$). At the same time, we wouldn't want them to access the form itself and perform a query. Which means that what you see in a the table, is what you get.

I understand your logic of row level access, but that will then mean we have to redefine all the groups that have access to the status field and then enroll them accordingly, which is quite a huge effort.

Thus i'm looking for alternatives way of achieving it. Maybe i'm missing the big picture somewhere as well.

What i need, i guess, is to find a way to perhaps disable the F5 refresh key? Is there a way to do it?

"J.D. Hood" wrote:

Again, I guess it goes back to "why" you want to do this What's the
definition of the problem you are trying to overcome?

From what I can gather, you want to restrict the users from seeing any
tickets except their own. If that's correct, then "row-level-access" should
do what you are looking for. An "$OPERATION$ = "QUERY" active link would not
be needed and you could delete the one you've built. The user can hit F5 all
they want, and they will only be able to see their own records. In other
words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
Panel), if they don't have permission to the Request ID field, they don't
get to see the record. Row-Level-Access will only allow them to see their
records by selectively granting access to the Request ID field on a record-
by-record basis. Well, I'm presuming they can't bypass the Remedy API and go
straight to the DB tables.

However, there's the distinct possibility that I'm way off in left field and
have completely misunderstood your problem. If so, I apologize. If you only
want to restrict a user's ability to search "sometimes", and at other times
allow the same user to to see all records, then yes, you have a much
different problem. But it's likely not an insurmountable problem. We just
have to define the problem.

-JD-


On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:

>Hi JD:
>
>My apologies for the late reply. Was busy troubleshooting some other
problems that arises.
>
>Your solution sounds simple enough to implement, but unfortunately it
probably does not fulfill what i'm trying to achieve here. I have a form,
let say a helpdesk form, that i would want to restrict user from searching
on it. What i do is i'll allow them to see their own ticket through Remedy
Requester, Remedy Support and Remedy Management.
>
>When i try out the option of disabling search through an Active Link that
says Operation = " QUERY" or Execute on: Search, it will then generate an
error when the request is open from a VIEW button under the Remedy Requester
Console. I check this through the Active Link log and found that this occur
as an OPEN WINDOW action has triggered a QUERY condition which then
prevented the ticket from being display.
>
>Alternatively, what i need to do is to prevent the user from pressing F5 on
the keyboard or from performing an advance search when opening the Helpdesk
form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
cannot be disabled from the Admin tool under Properties -> Menu Access.
>
>Any suggestions/advice would be deeply appreciated. Thank you!
>
>"J. D. Hood" wrote:
>I'm going to presume a couple of things here:
>
>1. This search restriction mainly applies to the general user community.
>2. There are one or more group(s) that may have a need to access all
>records, so the search restriction should *not* apply to them.
>3. All users have to identify themselves to the system, either by a login
or
>something -- there are no anonymous users.
>
>
>If those presumptions are correct, and I do hope I've understood the
problem
>accurately, this seems to me like a run-of-the-mill row-level access issue.
>If so, you may want to check the Admin guide for "Controlling access by
>using implicit groups ?row-level security".
>
>Basically, all you have to do is control permissions on the Request-ID
field
>(field ID# 1). For example, if the user's name is in the submitter field,
>and the Request-ID field permissions only has the "Submitter" group, then
>the submitter is the only person from the general user community who can
see
>that record. Of course, you would add any other appropriate group(s) to the
>Request-ID field permissions (like "Human-Resources" or "Personnel
>Management" groups, or whatever). You just have to be carefull not to add a
>group with a broad membership that may include members who would otherwise
>be restricted.
>
>As for users running HUGE searches, that can be handled via configuration
>settings limiting the max rows and/or workflow that "AND's" something into
>the ASB. So you can reassure your admin that he has no worries.
>
>-jd-
>
>
>
>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>
>>
>>Hi there:
>>
>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>search on the request ID may not work for me as the table can display any
>request ID. Perhaps i need to carefully think of the logic to be used...
>>
>>As for option 2, the dialog box option sounds interesting. Something
>worthwhile testing.
>>
>>As part of other people's advice(thanks to both James), James Smith
>suggestion on selecting a particular VUI might seems to be the easiest way
>to accomplish it(i'll test it out).
>>
>>As for preventing object list, one other question that i have in mind is
>that, do i then have to enroll everyone into the AR System user preference
form?
>>
>>Allow me to explain further why I would need to disable search on a
>particular form. The reason why we are doing this is because:
>>
>>1.)it contain sensitive data, and we are trying to prevent people from
>seeing someone else's record
>>
>>2.) our admin are concern that in future allowing search(without a proper
>indexing) might slow down the system considerably, especially when we’re
not
>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>
>>Hope this provide a clearer picture. Once again, Many Thanks to all of
you.
>
>>
>>Warmest regards,
>>EK
>>
>>
>>"J. D. Hood" wrote:Have you considered modifying your
>active-link stack that prevents searching
>>to account for the request-ID that you are opening in the table?
>>
>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>
>>Or open the table record in dialog mode? You could copy the form to
>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>display the record.
>>
>>It might help if you explained the busniess reason behind blocking
searches.
>>Are you trying to prevent people from seeing someone else's records? Are
>>there certain parts that are confidential on all records? What's the
overall
>>goal that you are trying to accomplish? Without an understanding of the
>>requirement, there's usually quite a bit of "Braille Method" involved in
the
>>solution.
>>
>>-jd-
>>
>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>
>>>Hi All:
>>>
>>>Thank you for all your advice. I think i've created some confusion along
>>the line, my apologies.
>>>
>>>Initially, when i have created the Active Link to prevent other people
from
>>searching an ITSM form, it works as it will check for the user's
permission
>>and allow them to search if they are an administrator.
>>>
>>>I started facing problem when i test out on a TABLE field that i've
>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>does not have sufficient permission, will now get the error from my Active
>>Link. If my table allows drill down, it does not have the same error.
>>>
>>>Thus what i would like to achieve is to allow my VIEW button to be able
to
>>open up the form, without getting the error. I'm not using a macro.
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)




Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard . This posting was submitted via the Web interface

**
What about this as a workaround:

Create an active link that runs on Window Open and Window Loaded of the form that you don't want the users to search. Run if $OPERATION$ != "SET". The only action that the active link needs to have is an Error message.

This means that if you drill down through a table, you are going straight into "SET" mode, but if you press F5 or F2 you will go into create/query and generate an error and the form will close down. Tested ok on version5. Not quite as reliable as row level access but might do as a short term solution.

Regards
Isabel

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]On Behalf Of EK
Sent: 22 August 2005 13:41
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Hi JD:

Sorry, guess after so many rounds of email interaction i still has yet to firmly articulate the problem that i need to overcome and the reason why i need to do so. Basically, it is the company's policy that people should not be allow to see other people's ticket apart from their own department's ticket.

Thus the way we organize it is to allow them to view their own tickets and their own department tickets through table qualification(using qualification such as 'department' = $department$). At the same time, we wouldn't want them to access the form itself and perform a query. Which means that what you see in a the table, is what you get.

I understand your logic of row level access, but that will then mean we have to redefine all the groups that have access to the status field and then enroll them accordingly, which is quite a huge effort.

Thus i'm looking for alternatives way of achieving it. Maybe i'm missing the big picture somewhere as well.

What i need, i guess, is to find a way to perhaps disable the F5 refresh key? Is there a way to do it?

"J.D. Hood" wrote:

Again, I guess it goes back to "why" you want to do this What's the
definition of the problem you are trying to overcome?

From what I can gather, you want to restrict the users from seeing any
tickets except their own. If that's correct, then "row-level-access" should
do what you are looking for. An "$OPERATION$ = "QUERY" active link would not
be needed and you could delete the one you've built. The user can hit F5 all
they want, and they will only be able to see their own records. In other
words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
Panel), if they don't have permission to the Request ID field, they don't
get to see the record. Row-Level-Access will only allow them to see their
records by selectively granting access to the Request ID field on a record-
by-record basis. Well, I'm presuming they can't bypass the Remedy API and go
straight to the DB tables.

However, there's the distinct possibility that I'm way off in left field and
have completely misunderstood your problem. If so, I apologize. If you only
want to restrict a user's ability to search "sometimes", and at other times
allow the same user to to see all records, then yes, you have a much
different problem. But it's likely not an insurmountable problem. We just
have to define the problem.

-JD-


On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:

>Hi JD:
>
>My apologies for the late reply. Was busy troubleshooting some other
problems that arises.
>
>Your solution sounds simple enough to implement, but unfortunately it
probably does not fulfill what i'm trying to achieve here. I have a form,
let say a helpdesk form, that i would want to restrict user from searching
on it. What i do is i'll allow them to see their own ticket through Remedy
Requester, Remedy Support and Remedy Management.
>
>When i try out the option of disabling search through an Active Link that
says Operation = " QUERY" or Execute on: Search, it will then generate an
error when the request is open from a VIEW button under the Remedy Requester
Console. I check this through the Active Link log and found that this occur
as an OPEN WINDOW action has triggered a QUERY condition which then
prevented the ticket from being display.
>
>Alternatively, what i need to do is to prevent the user from pressing F5 on
the keyboard or from performing an advance search when opening the Helpdesk
form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
cannot be disabled from the Admin tool under Properties -> Menu Access.
>
>Any suggestions/advice would be deeply appreciated. Thank you!
>
>"J. D. Hood" wrote:
>I'm going to presume a couple of things here:
>
>1. This search restriction mainly applies to the general user community.
>2. There are one or more group(s) that may have a need to access all
>records, so the search restriction should *not* apply to them.
>3. All users have to identify themselves to the system, either by a login
or
>something -- there are no anonymous users.
>
>
>If those presumptions are correct, and I do hope I've understood the
problem
>accurately, this seems to me like a run-of-the-mill row-level access issue.
>If so, you may want to check the Admin guide for "Controlling access by
>using implicit groups ?row-level security".
>
>Basically, all you have to do is control permissions on the Request-ID
field
>(field ID# 1). For example, if the user's name is in the submitter field,
>and the Request-ID field permissions only has the "Submitter" group, then
>the submitter is the only person from the general user community who can
see
>that record. Of course, you would add any other appropriate group(s) to the
>Request-ID field permissions (like "Human-Resources" or "Personnel
>Management" groups, or whatever). You just have to be carefull not to add a
>group with a broad membership that may include members who would otherwise
>be restricted.
>
>As for users running HUGE searches, that can be handled via configuration
>settings limiting the max rows and/or workflow that "AND's" something into
>the ASB. So you can reassure your admin that he has no worries.
>
>-jd-
>
>
>
>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>
>>
>>Hi there:
>>
>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>search on the request ID may not work for me as the table can display any
>request ID. Perhaps i need to carefully think of the logic to be used...
>>
>>As for option 2, the dialog box option sounds interesting. Something
>worthwhile testing.
>>
>>As part of other people's advice(thanks to both James), James Smith
>suggestion on selecting a particular VUI might seems to be the easiest way
>to accomplish it(i'll test it out).
>>
>>As for preventing object list, one other question that i have in mind is
>that, do i then have to enroll everyone into the AR System user preference
form?
>>
>>Allow me to explain further why I would need to disable search on a
>particular form. The reason why we are doing this is because:
>>
>>1.)it contain sensitive data, and we are trying to prevent people from
>seeing someone else's record
>>
>>2.) our admin are concern that in future allowing search(without a proper
>indexing) might slow down the system considerably, especially when we’re
not
>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>
>>Hope this provide a clearer picture. Once again, Many Thanks to all of
you.
>
>>
>>Warmest regards,
>>EK
>>
>>
>>"J. D. Hood" wrote:Have you considered modifying your
>active-link stack that prevents searching
>>to account for the request-ID that you are opening in the table?
>>
>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>
>>Or open the table record in dialog mode? You could copy the form to
>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>display the record.
>>
>>It might help if you explained the busniess reason behind blocking
searches.
>>Are you trying to prevent people from seeing someone else's records? Are
>>there certain parts that are confidential on all records? What's the
overall
>>goal that you are trying to accomplish? Without an understanding of the
>>requirement, there's usually quite a bit of "Braille Method" involved in
the
>>solution.
>>
>>-jd-
>>
>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>
>>>Hi All:
>>>
>>>Thank you for all your advice. I think i've created some confusion along
>>the line, my apologies.
>>>
>>>Initially, when i have created the Active Link to prevent other people
from
>>searching an ITSM form, it works as it will check for the user's
permission
>>and allow them to search if they are an administrator.
>>>
>>>I started facing problem when i test out on a TABLE field that i've
>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>does not have sufficient permission, will now get the error from my Active
>>Link. If my table allows drill down, it does not have the same error.
>>>
>>>Thus what i would like to achieve is to allow my VIEW button to be able
to
>>open up the form, without getting the error. I'm not using a macro.
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)





Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard . This posting was submitted via the Web interface



----------------------------------------------------------------------------
Disclaimer:
This message is intended only for use of the addressee. If this message
was sent to you in error, please notify the sender and delete this message.
Glasgow City Council cannot accept responsibility for viruses, so please
scan attachments. Views expressed in this message do not necessarily reflect
those of the Council who will not necessarily be bound by its contents.
----------------------------------------------------------------------------

This posting was submitted via the Web interface

**
Dear Isabel:

I have tried the workaround that you suggested below, but unfortunately it does not work in my version 6.0 environment. What happen is that while i can create an Active Link that gives an error if $OPERATION$ ! = "Set", when i drill down a table, it will actually go into a QUERY mode during WINDOWS OPEN and WINDOWS LOADED.

The Table drill down is being controlled by a VIEW button which will perform an OPEN WINDOW action, open in Modify mode, and have a qualification of "Request ID" = "Table Ticket ID". Perhaps this is the condition that triggers the table to QUERY the DB to retrieve the record. Not quite sure how i can do it other way.

Thanks for the advice though. ;)

"Ross, Isabel" wrote:

**
What about this as a workaround:

Create an active link that runs on Window Open and Window Loaded of the form that you don't want the users to search. Run if $OPERATION$ != "SET". The only action that the active link needs to have is an Error message.

This means that if you drill down through a table, you are going straight into "SET" mode, but if you press F5 or F2 you will go into create/query and generate an error and the form will close down. Tested ok on version5. Not quite as reliable as row level access but might do as a short term solution.

Regards
Isabel

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]On Behalf Of EK
Sent: 22 August 2005 13:41
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Hi JD:

Sorry, guess after so many rounds of email interaction i still has yet to firmly articulate the problem that i need to overcome and the reason why i need to do so. Basically, it is the company's policy that people should not be allow to see other people's ticket apart from their own department's ticket.

Thus the way we organize it is to allow them to view their own tickets and their own department tickets through table qualification(using qualification such as 'department' = $department$). At the same time, we wouldn't want them to access the form itself and perform a query. Which means that what you see in a the table, is what you get.

I understand your logic of row level access, but that will then mean we have to redefine all the groups that have access to the status field and then enroll them accordingly, which is quite a huge effort.

Thus i'm looking for alternatives way of achieving it. Maybe i'm missing the big picture somewhere as well.

What i need, i guess, is to find a way to perhaps disable the F5 refresh key? Is there a way to do it?

"J.D. Hood" wrote:

Again, I guess it goes back to "why" you want to do this What's the
definition of the problem you are trying to overcome?

From what I can gather, you want to restrict the users from seeing any
tickets except their own. If that's correct, then "row-level-access" should
do what you are looking for. An "$OPERATION$ = "QUERY" active link would not
be needed and you could delete the one you've built. The user can hit F5 all
they want, and they will only be able to see their own records. In other
words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
Panel), if they don't have permission to the Request ID field, they don't
get to see the record. Row-Level-Access will only allow them to see their
records by selectively granting access to the Request ID field on a record-
by-record basis. Well, I'm presuming they can't bypass the Remedy API and go
straight to the DB tables.

However, there's the distinct possibility that I'm way off in left field and
have completely misunderstood your problem. If so, I apologize. If you only
want to restrict a user's ability to search "sometimes", and at other times
allow the same user to to see all records, then yes, you have a much
different problem. But it's likely not an insurmountable problem. We just
have to define the problem.

-JD-


On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:

>Hi JD:
>
>My apologies for the late reply. Was busy troubleshooting some other
problems that arises.
>
>Your solution sounds simple enough to implement, but unfortunately it
probably does not fulfill what i'm trying to achieve here. I have a form,
let say a helpdesk form, that i would want to restrict user from searching
on it. What i do is i'll allow them to see their own ticket through Remedy
Requester, Remedy Support and Remedy Management.
>
>When i try out the option of disabling search through an Active Link that
says Operation = " QUERY" or Execute on: Search, it will then generate an
error when the request is open from a VIEW button under the Remedy Requester
Console. I check this through the Active Link log and found that this occur
as an OPEN WINDOW action has triggered a QUERY condition which then
prevented the ticket from being display.
>
>Alternatively, what i need to do is to prevent the user from pressing F5 on
the keyboard or from performing an advance search when opening the Helpdesk
form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
cannot be disabled from the Admin tool under Properties -> Menu Access.
>
>Any suggestions/advice would be deeply appreciated. Thank you!
>
>"J. D. Hood" wrote:
>I'm going to presume a couple of things here:
>
>1. This search restriction mainly applies to the general user community.
>2. There are one or more group(s) that may have a need to access all
>records, so the search restriction should *not* apply to them.
>3. All users have to identify themselves to the system, either by a login
or
>something -- there are no anonymous users.
>
>
>If those presumptions are correct, and I do hope I've understood the
problem
>accurately, this seems to me like a run-of-the-mill row-level access issue.
>If so, you may want to check the Admin guide for "Controlling access by
>using implicit groups ?row-level security".
>
>Basically, all you have to do is control permissions on the Request-ID
field
>(field ID# 1). For example, if the user's name is in the submitter field,
>and the Request-ID field permissions only has the "Submitter" group, then
>the submitter is the only person from the general user community who can
see
>that record. Of course, you would add any other appropriate group(s) to the
>Request-ID field permissions (like "Human-Resources" or "Personnel
>Management" groups, or whatever). You just have to be carefull not to add a
>group with a broad membership that may include members who would otherwise
>be restricted.
>
>As for users running HUGE searches, that can be handled via configuration
>settings limiting the max rows and/or workflow that "AND's" something into
>the ASB. So you can reassure your admin that he has no worries.
>
>-jd-
>
>
>
>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>
>>
>>Hi there:
>>
>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>search on the request ID may not work for me as the table can display any
>request ID. Perhaps i need to carefully think of the logic to be used...
>>
>>As for option 2, the dialog box option sounds interesting. Something
>worthwhile testing.
>>
>>As part of other people's advice(thanks to both James), James Smith
>suggestion on selecting a particular VUI might seems to be the easiest way
>to accomplish it(i'll test it out).
>>
>>As for preventing object list, one other question that i have in mind is
>that, do i then have to enroll everyone into the AR System user preference
form?
>>
>>Allow me to explain further why I would need to disable search on a
>particular form. The reason why we are doing this is because:
>>
>>1.)it contain sensitive data, and we are trying to prevent people from
>seeing someone else's record
>>
>>2.) our admin are concern that in future allowing search(without a proper
>indexing) might slow down the system considerably, especially when we’re
not
>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>
>>Hope this provide a clearer picture. Once again, Many Thanks to all of
you.
>
>>
>>Warmest regards,
>>EK
>>
>>
>>"J. D. Hood" wrote:Have you considered modifying your
>active-link stack that prevents searching
>>to account for the request-ID that you are opening in the table?
>>
>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>
>>Or open the table record in dialog mode? You could copy the form to
>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>display the record.
>>
>>It might help if you explained the busniess reason behind blocking
searches.
>>Are you trying to prevent people from seeing someone else's records? Are
>>there certain parts that are confidential on all records? What's the
overall
>>goal that you are trying to accomplish? Without an understanding of the
>>requirement, there's usually quite a bit of "Braille Method" involved in
the
>>solution.
>>
>>-jd-
>>
>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>
>>>Hi All:
>>>
>>>Thank you for all your advice. I think i've created some confusion along
>>the line, my apologies.
>>>
>>>Initially, when i have created the Active Link to prevent other people
from
>>searching an ITSM form, it works as it will check for the user's
permission
>>and allow them to search if they are an administrator.
>>>
>>>I started facing problem when i test out on a TABLE field that i've
>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>does not have sufficient permission, will now get the error from my Active
>>Link. If my table allows drill down, it does not have the same error.
>>>
>>>Thus what i would like to achieve is to allow my VIEW button to be able
to
>>open up the form, without getting the error. I'm not using a macro.
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)





Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard . This posting was submitted via the Web interface



----------------------------------------------------------------------------
Disclaimer:
This message is intended only for use of the addressee. If this message
was sent to you in error, please notify the sender and delete this message.
Glasgow City Council cannot accept responsibility for viruses, so please
scan attachments. Views expressed in this message do not necessarily reflect
those of the Council who will not necessarily be bound by its contents.
----------------------------------------------------------------------------
This posting was submitted via the Web interface



Start your day with Yahoo! - make it your home page This posting was submitted via the Web interface

**
Hey,

It sounds to me that this is a perfect use for Row Level Access. It's on page 52 of the 5.1 Developing...Basic book.

If you have any questions, just ask.

Later
Stephen

"J.D. Hood" wrote:

So the restriction should be: users may only view tickets that were created
from within their department.

Monkey Wrenches:
- Can a person be a member of more than one department?
- Do you already have some way of resolving which department a user belongs
to?

I think your best bet is the previously mentioned idea from Stephen Lumini
suggesting you should build active-link workflow that quietly qualifys a
search by adding the user's department(s) into the hidden Advanced Search
Bar (What was it - field id 1005?) whenever the user performs a search. This
might be more desireable because it would afford the ability to
conditionally loosen/tighten the restriction through normal, run-of-the-mill
workflow.

If you are not already doing it, you may want to pre-fetch the user's
department(s) into a hidden field on display/window-open and leverage that
for quietly qualifying searches and for your table-field qualification.

I do hope you already have a way for Remedy to determine the user's
department, or this could be a big chore.

Good Luck With It!

-JD-


On Mon, 22 Aug 2005 05:40:58 -0700, EK wrote:

>Hi JD:
>
>Sorry, guess after so many rounds of email interaction i still has yet to
firmly articulate the problem that i need to overcome and the reason why i
need to do so. Basically, it is the company's policy that people should not
be allow to see other people's ticket apart from their own department's
ticket.
>
>Thus the way we organize it is to allow them to view their own tickets and
their own department tickets through table qualification(using qualification
such as 'department' = $department$). At the same time, we wouldn't want
them to access the form itself and perform a query. Which means that what
you see in a the table, is what you get.
>
>I understand your logic of row level access, but that will then mean we
have to redefine all the groups that have access to the status field and
then enroll them accordingly, which is quite a huge effort.
>
>Thus i'm looking for alternatives way of achieving it. Maybe i'm missing
the big picture somewhere as well.
>
>What i need, i guess, is to find a way to perhaps disable the F5 refresh
key? Is there a way to do it?
>
>"J.D. Hood" wrote:
>Again, I guess it goes back to "why" you want to do this What's the
>definition of the problem you are trying to overcome?
>
>From what I can gather, you want to restrict the users from seeing any
>tickets except their own. If that's correct, then "row-level-access" should
>do what you are looking for. An "$OPERATION$ = "QUERY" active link would
not
>be needed and you could delete the one you've built. The user can hit F5
all
>they want, and they will only be able to see their own records. In other
>words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
>Panel), if they don't have permission to the Request ID field, they don't
>get to see the record. Row-Level-Access will only allow them to see their
>records by selectively granting access to the Request ID field on a record-
>by-record basis. Well, I'm presuming they can't bypass the Remedy API and
go
>straight to the DB tables.
>
>However, there's the distinct possibility that I'm way off in left field
and
>have completely misunderstood your problem. If so, I apologize. If you only
>want to restrict a user's ability to search "sometimes", and at other times
>allow the same user to to see all records, then yes, you have a much
>different problem. But it's likely not an insurmountable problem. We just
>have to define the problem.
>
>-JD-
>
>
>On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:
>
>>Hi JD:
>>
>>My apologies for the late reply. Was busy troubleshooting some other
>problems that arises.
>>
>>Your solution sounds simple enough to implement, but unfortunately it
>probably does not fulfill what i'm trying to achieve here. I have a form,
>let say a helpdesk form, that i would want to restrict user from searching
>on it. What i do is i'll allow them to see their own ticket through Remedy
>Requester, Remedy Support and Remedy Management.
>>
>>When i try out the option of disabling search through an Active Link that
>says Operation = " QUERY" or Execute on: Search, it will then generate an
>error when the request is open from a VIEW button under the Remedy
Requester
>Console. I check this through the Active Link log and found that this occur
>as an OPEN WINDOW action has triggered a QUERY condition which then
>prevented the ticket from being display.
>>
>>Alternatively, what i need to do is to prevent the user from pressing F5
on
>the keyboard or from performing an advance search when opening the Helpdesk
>form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
>cannot be disabled from the Admin tool under Properties -> Menu Access.
>>
>>Any suggestions/advice would be deeply appreciated. Thank you!
>>
>>"J. D. Hood" wrote:
>>I'm going to presume a couple of things here:
>>
>>1. This search restriction mainly applies to the general user community.
>>2. There are one or more group(s) that may have a need to access all
>>records, so the search restriction should *not* apply to them.
>>3. All users have to identify themselves to the system, either by a login
>or
>>something -- there are no anonymous users.
>>
>>
>>If those presumptions are correct, and I do hope I've understood the
>problem
>>accurately, this seems to me like a run-of-the-mill row-level access
issue.
>>If so, you may want to check the Admin guide for "Controlling access by
>>using implicit groups ?row-level security".
>>
>>Basically, all you have to do is control permissions on the Request-ID
>field
>>(field ID# 1). For example, if the user's name is in the submitter field,
>>and the Request-ID field permissions only has the "Submitter" group, then
>>the submitter is the only person from the general user community who can
>see
>>that record. Of course, you would add any other appropriate group(s) to
the
>>Request-ID field permissions (like "Human-Resources" or "Personnel
>>Management" groups, or whatever). You just have to be carefull not to add
a
>>group with a broad membership that may include members who would otherwise
>>be restricted.
>>
>>As for users running HUGE searches, that can be handled via configuration
>>settings limiting the max rows and/or workflow that "AND's" something into
>>the ASB. So you can reassure your admin that he has no worries.
>>
>>-jd-
>>
>>
>>
>>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>>
>>>
>>>Hi there:
>>>
>>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>>search on the request ID may not work for me as the table can display any
>>request ID. Perhaps i need to carefully think of the logic to be used...
>>>
>>>As for option 2, the dialog box option sounds interesting. Something
>>worthwhile testing.
>>>
>>>As part of other people's advice(thanks to both James), James Smith
>>suggestion on selecting a particular VUI might seems to be the easiest way
>>to accomplish it(i'll test it out).
>>>
>>>As for preventing object list, one other question that i have in mind is
>>that, do i then have to enroll everyone into the AR System user preference
>form?
>>>
>>>Allow me to explain further why I would need to disable search on a
>>particular form. The reason why we are doing this is because:
>>>
>>>1.)it contain sensitive data, and we are trying to prevent people from
>>seeing someone else's record
>>>
>>>2.) our admin are concern that in future allowing search(without a proper
>>indexing) might slow down the system considerably, especially when we’re
>not
>>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>>
>>>Hope this provide a clearer picture. Once again, Many Thanks to all of
>you.
>>
>>>
>>>Warmest regards,
>>>EK
>>>
>>>
>>>"J. D. Hood" wrote:Have you considered modifying your
>>active-link stack that prevents searching
>>>to account for the request-ID that you are opening in the table?
>>>
>>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>>
>>>Or open the table record in dialog mode? You could copy the form to
>>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>>display the record.
>>>
>>>It might help if you explained the busniess reason behind blocking
>searches.
>>>Are you trying to prevent people from seeing someone else's records? Are
>>>there certain parts that are confidential on all records? What's the
>overall
>>>goal that you are trying to accomplish? Without an understanding of the
>>>requirement, there's usually quite a bit of "Braille Method" involved in
>the
>>>solution.
>>>
>>>-jd-
>>>
>>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>>
>>>>Hi All:
>>>>
>>>>Thank you for all your advice. I think i've created some confusion along
>>>the line, my apologies.
>>>>
>>>>Initially, when i have created the Active Link to prevent other people
>from
>>>searching an ITSM form, it works as it will check for the user's
>permission
>>>and allow them to search if they are an administrator.
>>>>
>>>>I started facing problem when i test out on a TABLE field that i've
>>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>>does not have sufficient permission, will now get the error from my
Active
>>>Link. If my table allows drill down, it does not have the same error.
>>>>
>>>>Thus what i would like to achieve is to allow my VIEW button to be able
>to
>>>open up the form, without getting the error. I'm not using a macro.
>>>
>>>

>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>http://mail.yahoo.com
>>>
>>>

>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>---------------------------------
>Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)




ARS 5.1.2
Oracel 9i


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com This posting was submitted via the Web interface

So the restriction should be: users may only view tickets that were created
from within their department.

Monkey Wrenches:
- Can a person be a member of more than one department?
- Do you already have some way of resolving which department a user belongs
to?

I think your best bet is the previously mentioned idea from Stephen Lumini
suggesting you should build active-link workflow that quietly qualifys a
search by adding the user's department(s) into the hidden Advanced Search
Bar (What was it - field id 1005?) whenever the user performs a search. This
might be more desireable because it would afford the ability to
conditionally loosen/tighten the restriction through normal, run-of-the-mill
workflow.

If you are not already doing it, you may want to pre-fetch the user's
department(s) into a hidden field on display/window-open and leverage that
for quietly qualifying searches and for your table-field qualification.

I do hope you already have a way for Remedy to determine the user's
department, or this could be a big chore.

Good Luck With It!

-JD-


On Mon, 22 Aug 2005 05:40:58 -0700, EK wrote:

>Hi JD:
>
>Sorry, guess after so many rounds of email interaction i still has yet to
firmly articulate the problem that i need to overcome and the reason why i
need to do so. Basically, it is the company's policy that people should not
be allow to see other people's ticket apart from their own department's
ticket.
>
>Thus the way we organize it is to allow them to view their own tickets and
their own department tickets through table qualification(using qualification
such as 'department' = $department$). At the same time, we wouldn't want
them to access the form itself and perform a query. Which means that what
you see in a the table, is what you get.
>
>I understand your logic of row level access, but that will then mean we
have to redefine all the groups that have access to the status field and
then enroll them accordingly, which is quite a huge effort.
>
>Thus i'm looking for alternatives way of achieving it. Maybe i'm missing
the big picture somewhere as well.
>
>What i need, i guess, is to find a way to perhaps disable the F5 refresh
key? Is there a way to do it?
>
>"J.D. Hood" wrote:
>Again, I guess it goes back to "why" you want to do this What's the
>definition of the problem you are trying to overcome?
>
>From what I can gather, you want to restrict the users from seeing any
>tickets except their own. If that's correct, then "row-level-access" should
>do what you are looking for. An "$OPERATION$ = "QUERY" active link would
not
>be needed and you could delete the one you've built. The user can hit F5
all
>they want, and they will only be able to see their own records. In other
>words, it wouldn't matter how they search (F5, Advanced Search Bar, Control
>Panel), if they don't have permission to the Request ID field, they don't
>get to see the record. Row-Level-Access will only allow them to see their
>records by selectively granting access to the Request ID field on a record-
>by-record basis. Well, I'm presuming they can't bypass the Remedy API and
go
>straight to the DB tables.
>
>However, there's the distinct possibility that I'm way off in left field
and
>have completely misunderstood your problem. If so, I apologize. If you only
>want to restrict a user's ability to search "sometimes", and at other times
>allow the same user to to see all records, then yes, you have a much
>different problem. But it's likely not an insurmountable problem. We just
>have to define the problem.
>
>-JD-
>
>
>On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:
>
>>Hi JD:
>>
>>My apologies for the late reply. Was busy troubleshooting some other
>problems that arises.
>>
>>Your solution sounds simple enough to implement, but unfortunately it
>probably does not fulfill what i'm trying to achieve here. I have a form,
>let say a helpdesk form, that i would want to restrict user from searching
>on it. What i do is i'll allow them to see their own ticket through Remedy
>Requester, Remedy Support and Remedy Management.
>>
>>When i try out the option of disabling search through an Active Link that
>says Operation = " QUERY" or Execute on: Search, it will then generate an
>error when the request is open from a VIEW button under the Remedy
Requester
>Console. I check this through the Active Link log and found that this occur
>as an OPEN WINDOW action has triggered a QUERY condition which then
>prevented the ticket from being display.
>>
>>Alternatively, what i need to do is to prevent the user from pressing F5
on
>the keyboard or from performing an advance search when opening the Helpdesk
>form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
>cannot be disabled from the Admin tool under Properties -> Menu Access.
>>
>>Any suggestions/advice would be deeply appreciated. Thank you!
>>
>>"J. D. Hood" wrote:
>>I'm going to presume a couple of things here:
>>
>>1. This search restriction mainly applies to the general user community.
>>2. There are one or more group(s) that may have a need to access all
>>records, so the search restriction should *not* apply to them.
>>3. All users have to identify themselves to the system, either by a login
>or
>>something -- there are no anonymous users.
>>
>>
>>If those presumptions are correct, and I do hope I've understood the
>problem
>>accurately, this seems to me like a run-of-the-mill row-level access
issue.
>>If so, you may want to check the Admin guide for "Controlling access by
>>using implicit groups ?row-level security".
>>
>>Basically, all you have to do is control permissions on the Request-ID
>field
>>(field ID# 1). For example, if the user's name is in the submitter field,
>>and the Request-ID field permissions only has the "Submitter" group, then
>>the submitter is the only person from the general user community who can
>see
>>that record. Of course, you would add any other appropriate group(s) to
the
>>Request-ID field permissions (like "Human-Resources" or "Personnel
>>Management" groups, or whatever). You just have to be carefull not to add
a
>>group with a broad membership that may include members who would otherwise
>>be restricted.
>>
>>As for users running HUGE searches, that can be handled via configuration
>>settings limiting the max rows and/or workflow that "AND's" something into
>>the ASB. So you can reassure your admin that he has no worries.
>>
>>-jd-
>>
>>
>>
>>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>>
>>>
>>>Hi there:
>>>
>>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>>search on the request ID may not work for me as the table can display any
>>request ID. Perhaps i need to carefully think of the logic to be used...
>>>
>>>As for option 2, the dialog box option sounds interesting. Something
>>worthwhile testing.
>>>
>>>As part of other people's advice(thanks to both James), James Smith
>>suggestion on selecting a particular VUI might seems to be the easiest way
>>to accomplish it(i'll test it out).
>>>
>>>As for preventing object list, one other question that i have in mind is
>>that, do i then have to enroll everyone into the AR System user preference
>form?
>>>
>>>Allow me to explain further why I would need to disable search on a
>>particular form. The reason why we are doing this is because:
>>>
>>>1.)it contain sensitive data, and we are trying to prevent people from
>>seeing someone else's record
>>>
>>>2.) our admin are concern that in future allowing search(without a proper
>>indexing) might slow down the system considerably, especially when we’re
>not
>>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>>
>>>Hope this provide a clearer picture. Once again, Many Thanks to all of
>you.
>>
>>>
>>>Warmest regards,
>>>EK
>>>
>>>
>>>"J. D. Hood" wrote:Have you considered modifying your
>>active-link stack that prevents searching
>>>to account for the request-ID that you are opening in the table?
>>>
>>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>>
>>>Or open the table record in dialog mode? You could copy the form to
>>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>>display the record.
>>>
>>>It might help if you explained the busniess reason behind blocking
>searches.
>>>Are you trying to prevent people from seeing someone else's records? Are
>>>there certain parts that are confidential on all records? What's the
>overall
>>>goal that you are trying to accomplish? Without an understanding of the
>>>requirement, there's usually quite a bit of "Braille Method" involved in
>the
>>>solution.
>>>
>>>-jd-
>>>
>>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>>
>>>>Hi All:
>>>>
>>>>Thank you for all your advice. I think i've created some confusion along
>>>the line, my apologies.
>>>>
>>>>Initially, when i have created the Active Link to prevent other people
>from
>>>searching an ITSM form, it works as it will check for the user's
>permission
>>>and allow them to search if they are an administrator.
>>>>
>>>>I started facing problem when i test out on a TABLE field that i've
>>>created, where the VIEW button will perform an OPEN WINDOW operation that
>>>opens it up in a DISPLAY mode. However, when i click on that, if the user
>>>does not have sufficient permission, will now get the error from my
Active
>>>Link. If my table allows drill down, it does not have the same error.
>>>>
>>>>Thus what i would like to achieve is to allow my VIEW button to be able
>to
>>>open up the form, without getting the error. I'm not using a macro.
>>>
>>>

>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>http://mail.yahoo.com
>>>
>>>

>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>---------------------------------
>Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Do you ever get that Deja-Voodoo feeling?

I agree, it sounds like your basic, garden-variety "row-level-access"
problem, but something keeps getting lost in the translation.

Either that, or they don't have their people divided up neatly into
permission groups
-AND-
there are so many people and/or so many groups that he's trying to avoid
that route. If that is the case, as cumbersome as the task may seem, I think
he will ultimately have to bite the bullet and "group" all the department
members.

-JD-


On Tue, 23 Aug 2005 15:36:14 -0400, Stephen Lumini
wrote:

>Hey,
>
>It sounds to me that this is a perfect use for Row Level Access. It's on
page 52 of the 5.1 Developing...Basic book.
>
>If you have any questions, just ask.
>
>Later
>Stephen
>
>"J.D. Hood" wrote:
>So the restriction should be: users may only view tickets that were created
>from within their department.
>
>Monkey Wrenches:
>- Can a person be a member of more than one department?
>- Do you already have some way of resolving which department a user belongs
>to?
>
>I think your best bet is the previously mentioned idea from Stephen Lumini
>suggesting you should build active-link workflow that quietly qualifys a
>search by adding the user's department(s) into the hidden Advanced Search
>Bar (What was it - field id 1005?) whenever the user performs a search.
This
>might be more desireable because it would afford the ability to
>conditionally loosen/tighten the restriction through normal, run-of-the-
mill
>workflow.
>
>If you are not already doing it, you may want to pre-fetch the user's
>department(s) into a hidden field on display/window-open and leverage that
>for quietly qualifying searches and for your table-field qualification.
>
>I do hope you already have a way for Remedy to determine the user's
>department, or this could be a big chore.
>
>Good Luck With It!
>
>-JD-
>
>
>On Mon, 22 Aug 2005 05:40:58 -0700, EK wrote:
>
>>Hi JD:
>>
>>Sorry, guess after so many rounds of email interaction i still has yet to
>firmly articulate the problem that i need to overcome and the reason why i
>need to do so. Basically, it is the company's policy that people should not
>be allow to see other people's ticket apart from their own department's
>ticket.
>>
>>Thus the way we organize it is to allow them to view their own tickets and
>their own department tickets through table qualification(using
qualification
>such as 'department' = $department$). At the same time, we wouldn't want
>them to access the form itself and perform a query. Which means that what
>you see in a the table, is what you get.
>>
>>I understand your logic of row level access, but that will then mean we
>have to redefine all the groups that have access to the status field and
>then enroll them accordingly, which is quite a huge effort.
>>
>>Thus i'm looking for alternatives way of achieving it. Maybe i'm missing
>the big picture somewhere as well.
>>
>>What i need, i guess, is to find a way to perhaps disable the F5 refresh
>key? Is there a way to do it?
>>
>>"J.D. Hood" wrote:
>>Again, I guess it goes back to "why" you want to do this What's the
>>definition of the problem you are trying to overcome?
>>
>>From what I can gather, you want to restrict the users from seeing any
>>tickets except their own. If that's correct, then "row-level-access"
should
>>do what you are looking for. An "$OPERATION$ = "QUERY" active link would
>not
>>be needed and you could delete the one you've built. The user can hit F5
>all
>>they want, and they will only be able to see their own records. In other
>>words, it wouldn't matter how they search (F5, Advanced Search Bar,
Control
>>Panel), if they don't have permission to the Request ID field, they don't
>>get to see the record. Row-Level-Access will only allow them to see their
>>records by selectively granting access to the Request ID field on a
record-
>>by-record basis. Well, I'm presuming they can't bypass the Remedy API and
>go
>>straight to the DB tables.
>>
>>However, there's the distinct possibility that I'm way off in left field
>and
>>have completely misunderstood your problem. If so, I apologize. If you
only
>>want to restrict a user's ability to search "sometimes", and at other
times
>>allow the same user to to see all records, then yes, you have a much
>>different problem. But it's likely not an insurmountable problem. We just
>>have to define the problem.
>>
>>-JD-
>>
>>
>>On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:
>>
>>>Hi JD:
>>>
>>>My apologies for the late reply. Was busy troubleshooting some other
>>problems that arises.
>>>
>>>Your solution sounds simple enough to implement, but unfortunately it
>>probably does not fulfill what i'm trying to achieve here. I have a form,
>>let say a helpdesk form, that i would want to restrict user from searching
>>on it. What i do is i'll allow them to see their own ticket through Remedy
>>Requester, Remedy Support and Remedy Management.
>>>
>>>When i try out the option of disabling search through an Active Link that
>>says Operation = " QUERY" or Execute on: Search, it will then generate an
>>error when the request is open from a VIEW button under the Remedy
>Requester
>>Console. I check this through the Active Link log and found that this
occur
>>as an OPEN WINDOW action has triggered a QUERY condition which then
>>prevented the ticket from being display.
>>>
>>>Alternatively, what i need to do is to prevent the user from pressing F5
>on
>>the keyboard or from performing an advance search when opening the
Helpdesk
>>form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
>>cannot be disabled from the Admin tool under Properties -> Menu Access.
>>>
>>>Any suggestions/advice would be deeply appreciated. Thank you!
>>>
>>>"J. D. Hood" wrote:
>>>I'm going to presume a couple of things here:
>>>
>>>1. This search restriction mainly applies to the general user community.
>>>2. There are one or more group(s) that may have a need to access all
>>>records, so the search restriction should *not* apply to them.
>>>3. All users have to identify themselves to the system, either by a login
>>or
>>>something -- there are no anonymous users.
>>>
>>>
>>>If those presumptions are correct, and I do hope I've understood the
>>problem
>>>accurately, this seems to me like a run-of-the-mill row-level access
>issue.
>>>If so, you may want to check the Admin guide for "Controlling access by
>>>using implicit groups ?row-level security".
>>>
>>>Basically, all you have to do is control permissions on the Request-ID
>>field
>>>(field ID# 1). For example, if the user's name is in the submitter field,
>>>and the Request-ID field permissions only has the "Submitter" group, then
>>>the submitter is the only person from the general user community who can
>>see
>>>that record. Of course, you would add any other appropriate group(s) to
>the
>>>Request-ID field permissions (like "Human-Resources" or "Personnel
>>>Management" groups, or whatever). You just have to be carefull not to add
>a
>>>group with a broad membership that may include members who would
otherwise
>>>be restricted.
>>>
>>>As for users running HUGE searches, that can be handled via configuration
>>>settings limiting the max rows and/or workflow that "AND's" something
into
>>>the ASB. So you can reassure your admin that he has no worries.
>>>
>>>-jd-
>>>
>>>
>>>
>>>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>>>
>>>>
>>>>Hi there:
>>>>
>>>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>>>search on the request ID may not work for me as the table can display any
>>>request ID. Perhaps i need to carefully think of the logic to be used...
>>>>
>>>>As for option 2, the dialog box option sounds interesting. Something
>>>worthwhile testing.
>>>>
>>>>As part of other people's advice(thanks to both James), James Smith
>>>suggestion on selecting a particular VUI might seems to be the easiest
way
>>>to accomplish it(i'll test it out).
>>>>
>>>>As for preventing object list, one other question that i have in mind is
>>>that, do i then have to enroll everyone into the AR System user
preference
>>form?
>>>>
>>>>Allow me to explain further why I would need to disable search on a
>>>particular form. The reason why we are doing this is because:
>>>>
>>>>1.)it contain sensitive data, and we are trying to prevent people from
>>>seeing someone else's record
>>>>
>>>>2.) our admin are concern that in future allowing search(without a
proper
>>>indexing) might slow down the system considerably, especially when we’re
>>not
>>>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>>>
>>>>Hope this provide a clearer picture. Once again, Many Thanks to all of
>>you.
>>>
>>>>
>>>>Warmest regards,
>>>>EK
>>>>
>>>>
>>>>"J. D. Hood" wrote:Have you considered modifying your
>>>active-link stack that prevents searching
>>>>to account for the request-ID that you are opening in the table?
>>>>
>>>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>>>
>>>>Or open the table record in dialog mode? You could copy the form to
>>>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>>>display the record.
>>>>
>>>>It might help if you explained the busniess reason behind blocking
>>searches.
>>>>Are you trying to prevent people from seeing someone else's records? Are
>>>>there certain parts that are confidential on all records? What's the
>>overall
>>>>goal that you are trying to accomplish? Without an understanding of the
>>>>requirement, there's usually quite a bit of "Braille Method" involved in
>>the
>>>>solution.
>>>>
>>>>-jd-
>>>>
>>>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>>>
>>>>>Hi All:
>>>>>
>>>>>Thank you for all your advice. I think i've created some confusion
along
>>>>the line, my apologies.
>>>>>
>>>>>Initially, when i have created the Active Link to prevent other people
>>from
>>>>searching an ITSM form, it works as it will check for the user's
>>permission
>>>>and allow them to search if they are an administrator.
>>>>>
>>>>>I started facing problem when i test out on a TABLE field that i've
>>>>created, where the VIEW button will perform an OPEN WINDOW operation
that
>>>>opens it up in a DISPLAY mode. However, when i click on that, if the
user
>>>>does not have sufficient permission, will now get the error from my
>Active
>>>>Link. If my table allows drill down, it does not have the same error.
>>>>>
>>>>>Thus what i would like to achieve is to allow my VIEW button to be able
>>to
>>>>open up the form, without getting the error. I'm not using a macro.
>>>>
>>>>

>
>>
>>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>>(Support: mailto:support@arslist.org)
>>>>
>>>>
>>>>
>>>>Do You Yahoo!?
>>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>>http://mail.yahoo.com
>>>>
>>>>

>
>>
>>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>>(Support: mailto:support@arslist.org)
>>>
>>>

>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>http://mail.yahoo.com
>>>
>>>

>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>---------------------------------
>>Do you Yahoo!?
>> Read only the mail you want - Yahoo! Mail SpamGuard.
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>ARS 5.1.2
>Oracel 9i
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

**
Hi JD and Gang:

So sorry for the late reply. Have been combacting some other type of higher priority problems.

Yup, i understand your concern/comments.Perhaps i have not been able to see a way through on how i can group them together as their roles tends to overlap. The idea here is that there are roles and departments that tends to overlap each other. And i think i missed out the fact that i can actually assign a form a PUBLIC Hidden permission and allows the users to only open the forms through workflow(through table or through a single click of a button).

That way, no one will be able to see the forms from the object list apart from the administrator.

Thanks so much for all your advice! Really appreciates it.

"J.D. Hood" wrote:

Do you ever get that Deja-Voodoo feeling?

I agree, it sounds like your basic, garden-variety "row-level-access"
problem, but something keeps getting lost in the translation.

Either that, or they don't have their people divided up neatly into
permission groups
-AND-
there are so many people and/or so many groups that he's trying to avoid
that route. If that is the case, as cumbersome as the task may seem, I think
he will ultimately have to bite the bullet and "group" all the department
members.

-JD-


On Tue, 23 Aug 2005 15:36:14 -0400, Stephen Lumini
wrote:

>Hey,
>
>It sounds to me that this is a perfect use for Row Level Access. It's on
page 52 of the 5.1 Developing...Basic book.
>
>If you have any questions, just ask.
>
>Later
>Stephen
>
>"J.D. Hood" wrote:
>So the restriction should be: users may only view tickets that were created
>from within their department.
>
>Monkey Wrenches:
>- Can a person be a member of more than one department?
>- Do you already have some way of resolving which department a user belongs
>to?
>
>I think your best bet is the previously mentioned idea from Stephen Lumini
>suggesting you should build active-link workflow that quietly qualifys a
>search by adding the user's department(s) into the hidden Advanced Search
>Bar (What was it - field id 1005?) whenever the user performs a search.
This
>might be more desireable because it would afford the ability to
>conditionally loosen/tighten the restriction through normal, run-of-the-
mill
>workflow.
>
>If you are not already doing it, you may want to pre-fetch the user's
>department(s) into a hidden field on display/window-open and leverage that
>for quietly qualifying searches and for your table-field qualification.
>
>I do hope you already have a way for Remedy to determine the user's
>department, or this could be a big chore.
>
>Good Luck With It!
>
>-JD-
>
>
>On Mon, 22 Aug 2005 05:40:58 -0700, EK wrote:
>
>>Hi JD:
>>
>>Sorry, guess after so many rounds of email interaction i still has yet to
>firmly articulate the problem that i need to overcome and the reason why i
>need to do so. Basically, it is the company's policy that people should not
>be allow to see other people's ticket apart from their own department's
>ticket.
>>
>>Thus the way we organize it is to allow them to view their own tickets and
>their own department tickets through table qualification(using
qualification
>such as 'department' = $department$). At the same time, we wouldn't want
>them to access the form itself and perform a query. Which means that what
>you see in a the table, is what you get.
>>
>>I understand your logic of row level access, but that will then mean we
>have to redefine all the groups that have access to the status field and
>then enroll them accordingly, which is quite a huge effort.
>>
>>Thus i'm looking for alternatives way of achieving it. Maybe i'm missing
>the big picture somewhere as well.
>>
>>What i need, i guess, is to find a way to perhaps disable the F5 refresh
>key? Is there a way to do it?
>>
>>"J.D. Hood" wrote:
>>Again, I guess it goes back to "why" you want to do this What's the
>>definition of the problem you are trying to overcome?
>>
>>From what I can gather, you want to restrict the users from seeing any
>>tickets except their own. If that's correct, then "row-level-access"
should
>>do what you are looking for. An "$OPERATION$ = "QUERY" active link would
>not
>>be needed and you could delete the one you've built. The user can hit F5
>all
>>they want, and they will only be able to see their own records. In other
>>words, it wouldn't matter how they search (F5, Advanced Search Bar,
Control
>>Panel), if they don't have permission to the Request ID field, they don't
>>get to see the record. Row-Level-Access will only allow them to see their
>>records by selectively granting access to the Request ID field on a
record-
>>by-record basis. Well, I'm presuming they can't bypass the Remedy API and
>go
>>straight to the DB tables.
>>
>>However, there's the distinct possibility that I'm way off in left field
>and
>>have completely misunderstood your problem. If so, I apologize. If you
only
>>want to restrict a user's ability to search "sometimes", and at other
times
>>allow the same user to to see all records, then yes, you have a much
>>different problem. But it's likely not an insurmountable problem. We just
>>have to define the problem.
>>
>>-JD-
>>
>>
>>On Sun, 21 Aug 2005 21:24:13 -0700, EK wrote:
>>
>>>Hi JD:
>>>
>>>My apologies for the late reply. Was busy troubleshooting some other
>>problems that arises.
>>>
>>>Your solution sounds simple enough to implement, but unfortunately it
>>probably does not fulfill what i'm trying to achieve here. I have a form,
>>let say a helpdesk form, that i would want to restrict user from searching
>>on it. What i do is i'll allow them to see their own ticket through Remedy
>>Requester, Remedy Support and Remedy Management.
>>>
>>>When i try out the option of disabling search through an Active Link that
>>says Operation = " QUERY" or Execute on: Search, it will then generate an
>>error when the request is open from a VIEW button under the Remedy
>Requester
>>Console. I check this through the Active Link log and found that this
occur
>>as an OPEN WINDOW action has triggered a QUERY condition which then
>>prevented the ticket from being display.
>>>
>>>Alternatively, what i need to do is to prevent the user from pressing F5
>on
>>the keyboard or from performing an advance search when opening the
Helpdesk
>>form from the OBJECT LIST. I'm on ARS 6.0 and thus the Advance Search Bar
>>cannot be disabled from the Admin tool under Properties -> Menu Access.
>>>
>>>Any suggestions/advice would be deeply appreciated. Thank you!
>>>
>>>"J. D. Hood" wrote:
>>>I'm going to presume a couple of things here:
>>>
>>>1. This search restriction mainly applies to the general user community.
>>>2. There are one or more group(s) that may have a need to access all
>>>records, so the search restriction should *not* apply to them.
>>>3. All users have to identify themselves to the system, either by a login
>>or
>>>something -- there are no anonymous users.
>>>
>>>
>>>If those presumptions are correct, and I do hope I've understood the
>>problem
>>>accurately, this seems to me like a run-of-the-mill row-level access
>issue.
>>>If so, you may want to check the Admin guide for "Controlling access by
>>>using implicit groups ?row-level security".
>>>
>>>Basically, all you have to do is control permissions on the Request-ID
>>field
>>>(field ID# 1). For example, if the user's name is in the submitter field,
>>>and the Request-ID field permissions only has the "Submitter" group, then
>>>the submitter is the only person from the general user community who can
>>see
>>>that record. Of course, you would add any other appropriate group(s) to
>the
>>>Request-ID field permissions (like "Human-Resources" or "Personnel
>>>Management" groups, or whatever). You just have to be carefull not to add
>a
>>>group with a broad membership that may include members who would
otherwise
>>>be restricted.
>>>
>>>As for users running HUGE searches, that can be handled via configuration
>>>settings limiting the max rows and/or workflow that "AND's" something
into
>>>the ASB. So you can reassure your admin that he has no worries.
>>>
>>>-jd-
>>>
>>>
>>>
>>>On Wed, 17 Aug 2005 00:21:41 -0700, EK wrote:
>>>
>>>>
>>>>Hi there:
>>>>
>>>>Great point. Thanks for all the tips. I believe option 1 on the allowing
>>>search on the request ID may not work for me as the table can display any
>>>request ID. Perhaps i need to carefully think of the logic to be used...
>>>>
>>>>As for option 2, the dialog box option sounds interesting. Something
>>>worthwhile testing.
>>>>
>>>>As part of other people's advice(thanks to both James), James Smith
>>>suggestion on selecting a particular VUI might seems to be the easiest
way
>>>to accomplish it(i'll test it out).
>>>>
>>>>As for preventing object list, one other question that i have in mind is
>>>that, do i then have to enroll everyone into the AR System user
preference
>>form?
>>>>
>>>>Allow me to explain further why I would need to disable search on a
>>>particular form. The reason why we are doing this is because:
>>>>
>>>>1.)it contain sensitive data, and we are trying to prevent people from
>>>seeing someone else's record
>>>>
>>>>2.) our admin are concern that in future allowing search(without a
proper
>>>indexing) might slow down the system considerably, especially when we’re
>>not
>>>running on a high end server(1GB RAM, Single Intel Xeon processor)
>>>>
>>>>Hope this provide a clearer picture. Once again, Many Thanks to all of
>>you.
>>>
>>>>
>>>>Warmest regards,
>>>>EK
>>>>
>>>>
>>>>"J. D. Hood" wrote:Have you considered modifying your
>>>active-link stack that prevents searching
>>>>to account for the request-ID that you are opening in the table?
>>>>
>>>>Or, only pop the message when $LASTCOUNT$ is greater than 1?
>>>>
>>>>Or open the table record in dialog mode? You could copy the form to
>>>>dlgOriginalFormName. Then you would have a seperate form that is usd to
>>>>display the record.
>>>>
>>>>It might help if you explained the busniess reason behind blocking
>>searches.
>>>>Are you trying to prevent people from seeing someone else's records? Are
>>>>there certain parts that are confidential on all records? What's the
>>overall
>>>>goal that you are trying to accomplish? Without an understanding of the
>>>>requirement, there's usually quite a bit of "Braille Method" involved in
>>the
>>>>solution.
>>>>
>>>>-jd-
>>>>
>>>>On Mon, 15 Aug 2005 23:49:52 -0700, EK wrote:
>>>>
>>>>>Hi All:
>>>>>
>>>>>Thank you for all your advice. I think i've created some confusion
along
>>>>the line, my apologies.
>>>>>
>>>>>Initially, when i have created the Active Link to prevent other people
>>from
>>>>searching an ITSM form, it works as it will check for the user's
>>permission
>>>>and allow them to search if they are an administrator.
>>>>>
>>>>>I started facing problem when i test out on a TABLE field that i've
>>>>created, where the VIEW button will perform an OPEN WINDOW operation
that
>>>>opens it up in a DISPLAY mode. However, when i click on that, if the
user
>>>>does not have sufficient permission, will now get the error from my
>Active
>>>>Link. If my table allows drill down, it does not have the same error.
>>>>>
>>>>>Thus what i would like to achieve is to allow my VIEW button to be able
>>to
>>>>open up the form, without getting the error. I'm not using a macro.
>>>>
>>>>

>
>>
>>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>>(Support: mailto:support@arslist.org)
>>>>
>>>>
>>>>
>>>>Do You Yahoo!?
>>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>>http://mail.yahoo.com
>>>>
>>>>

>
>>
>>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>>(Support: mailto:support@arslist.org)
>>>
>>>

>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>>
>>>
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>http://mail.yahoo.com
>>>
>>>

>
>>
>>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>>(Support: mailto:support@arslist.org)
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>>
>>
>>---------------------------------
>>Do you Yahoo!?
>> Read only the mail you want - Yahoo! Mail SpamGuard.
>>
>>

>
>>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>>(Support: mailto:support@arslist.org)
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)
>
>
>ARS 5.1.2
>Oracel 9i
>
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>

>UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
>(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)




Click here to donate to the Hurricane Katrina relief effort. This posting was submitted via the Web interface