**
Hi All:

Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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

Add an active link to the form that fires on 'Search'.

Have the AL issue an appropriate error message.

The 'Run If' can be used to stop the admin group getting the message.


EK writes:

> Hi All:
>
> Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?
>
> I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?
>
> I'm on ARS 6.0, User and Admin tool 6.0.
> Helpdesk 5.5.
> Mid tier 6.0.
> MSSQL2000.
>
> Any kind advice is much appreciated.
>
>
> ---------------------------------
> Start your day with Yahoo! - make it your home page
>
>
> 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,

The solution I use is to write an AL that fires on Window Open with a Run if of $OPERATION$ = "SEARCH" and include an error message explaining what the problem is.

When the window is opened the error message fires and stops all processing, including opening the window.

You can also add other conditions in the Run If so it only affects certain Groups.

Later
Stephen


EK wrote:

**
Hi All:

Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.




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



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

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do, but unfortunately i encounter another error in the form of table viewing tickets in the form. Right now a ticket will not be able to be open via my view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it. However, i do not get the same error using a table drill down. Am i missing something here?

I've created an AL to disable the search function by setting it to run under SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to be able to open up a ticket for viewing?
Stephen Lumini wrote:

**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if of $OPERATION$ = "SEARCH" and include an error message explaining what the problem is.

When the window is opened the error message fires and stops all processing, including opening the window.

You can also add other conditions in the Run If so it only affects certain Groups.

Later
Stephen


EK wrote:

**
Hi All:

Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.




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



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


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

**

Just out of curiosity will this solution work for just one field when using the Advanced search feature? I want to prevent users from searching from one field when using the Advanced search feature.



Thanks,



Roger A. Nall

T-Mobile USA

OSSNMS Remedy Developer

Desk: 973-644-3963

PCS: 973-652-6723

FAX: 973-490-3296



From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form



**

Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do, but unfortunately i encounter another error in the form of table viewing tickets in the form. Right now a ticket will not be able to be open via my view button that does an OPEN WINDOW operation to Open up that ticket.



Logs in my AL shows that it is querying the ticket and then displaying it. However, i do not get the same error using a table drill down. Am i missing something here?

I've created an AL to disable the search function by setting it to run under SEARCH as per previously adviced.



Any advice how i can now achieve that while still allowing my view button to be able to open up a ticket for viewing?

Stephen Lumini wrote:

**

Hi,



The solution I use is to write an AL that fires on Window Open with a Run if of $OPERATION$ = "SEARCH" and include an error message explaining what the problem is.



When the window is opened the error message fires and stops all processing, including opening the window.



You can also add other conditions in the Run If so it only affects certain Groups.



Later

Stephen



EK wrote:

**

Hi All:

Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?



I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?



I'm on ARS 6.0, User and Admin tool 6.0.

Helpdesk 5.5.

Mid tier 6.0.

MSSQL2000.



Any kind advice is much appreciated.





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



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


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

This posting was submitted via the Web interface

Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface


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

**
Actually, no. That only works if they type something in the actual field. If you want to check the Adv Srch Bar then look at the post I sent Roger last time this came up:

Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message of some sort. That's it.


EK-

>>Any advice how i can now achieve that while still allowing my view >>button to be able to open up a ticket for viewing?

I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the macro with a value in that field. Now in the original AL add the condition "FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3" wrote:

Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface


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




ARS 5.1.2
Oracel 9i



Find your next car at Yahoo! Canada Autos This posting was submitted via the Web interface

Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface



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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface


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

** Actually, the original question was asking

"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the front end (Control Panel) form for that application to opened. Then, I would provide functionality that would only allow certain users the ability to search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3 wrote:

Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface



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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface


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





--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the Web interface

**
Hey,

Actually, the original question was answered with the AL answer I gave, the second request "Any advice how i can now achieve that while still allowing my view button to be able to open up a ticket for viewing?" was answered in the second part of the posting that replied to James' idea.

And, unfortunately, the method you describe won't work for EK (provided he/she is using a macro) because the macro will still want to open the form in a query window first which your lack of permissions won't allow.

HTH
Any questions, just ask

Later
Stephen
Frank Caruso wrote:

** Actually, the original question was asking

"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the front end (Control Panel) form for that application to opened. Then, I would provide functionality that would only allow certain users the ability to search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3 wrote:

Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface



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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface


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





--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the Web interface



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

** I never said there would be permissions on the forms that would prevent querying\viewing of data.

My idea, which works very well, would be to allow only certain forms to be OPENED from the control panel. Have a menu with a list of forms that can be queried and that menu is tied to a field which can only be seen by certain users. Take it step further and make the menu choices dynamic based on the users permissions. It is very simple solution and easily implemented.



On 8/15/05, Stephen Lumini wrote:

**
Hey,

Actually, the original question was answered with the AL answer I gave, the second request "Any advice how i can now achieve that while still allowing my view button to be able to open up a ticket for viewing?" was answered in the second part of the posting that replied to James' idea.

And, unfortunately, the method you describe won't work for EK (provided he/she is using a macro) because the macro will still want to open the form in a query window first which your lack of permissions won't allow.

HTH
Any questions, just ask

Later
Stephen
Frank Caruso wrote:

** Actually, the original question was asking


"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the front end (Control Panel) form for that application to opened. Then, I would provide functionality that would only allow certain users the ability to search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3 < James.McKenzie@hqisec.army.mil > wrote:

Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto: arslist@ARSLIST.ORG ]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3" < James.McKenzie@HQISEC.ARMY.MIL >
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under
SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if
of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still
open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar
is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface



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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface


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





--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249

AIM:FMAR10 This posting was submitted via the Web interface



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




--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the Web interface

Frank:

This is inline with what Remedy tries to do with the ITSM Control Panel.

One point, do not forget to turn off the Object List query capability in the
User Tool. If this is left on, user's can and will select from this list
when they cannot find their 'favorite' form. This bypasses your nice new
Control Panel form. Also, do not forget to educate your existing users on
the new form and what it is supposed to do.

Good luck with your new deployment.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Frank Caruso
Sent: Monday, August 15, 2005 10:51 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


** Actually, the original question was asking

"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the
front end (Control Panel) form for that application to opened. Then, I would
provide functionality that would only allow certain users the ability to
search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3
wrote:
Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under

SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if

of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still

open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar

is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface




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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface



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




--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the
Web interface


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

Frank:

You could go one better and build a form that gives the user only those
forms they can access. Remedy comes with this, and it is called the Home
Page. You might want to look into it's functionality. However, if you
desire and want to do the work, your solution is a great alternative to this
form.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Frank Caruso
Sent: Monday, August 15, 2005 1:08 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


** I never said there would be permissions on the forms that would prevent
querying\viewing of data.

My idea, which works very well, would be to allow only certain forms to be
OPENED from the control panel. Have a menu with a list of forms that can be
queried and that menu is tied to a field which can only be seen by certain
users. Take it step further and make the menu choices dynamic based on the
users permissions. It is very simple solution and easily implemented.



On 8/15/05, Stephen Lumini wrote:
**
Hey,

Actually, the original question was answered with the AL answer I gave, the
second request "Any advice how i can now achieve that while still allowing
my view button to be able to open up a ticket for viewing?" was answered in
the second part of the posting that replied to James' idea.

And, unfortunately, the method you describe won't work for EK (provided
he/she is using a macro) because the macro will still want to open the form
in a query window first which your lack of permissions won't allow.

HTH
Any questions, just ask

Later
Stephen
Frank Caruso wrote:
** Actually, the original question was asking


"Need some advice on how i can disable the search function from a particular

form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the
front end (Control Panel) form for that application to opened. Then, I would
provide functionality that would only allow certain users the ability to
search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3 <
James.McKenzie@hqisec.army.mil> wrote:
Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto: arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3" < James.McKenzie@HQISEC.ARMY.MIL >
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one

field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under

SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if

of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still

open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar

is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface




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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface



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




--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249

AIM:FMAR10 This posting was submitted via the
Web interface


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



--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the
Web interface


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

**
Another option to completely keep users out of the search screen would be to write the active link to fire on form open or load and then switch to a submit mode. The Run If would be $OPERATION$ = "QUERY", the action would be Open Form, same form but in New mode, current window. Add a caveat to not run this for admins. Perhaps also add a warning note to the users.

John

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of EK
Sent: Wednesday, August 10, 2005 9:33 PM
To: arslist@ARSLIST.ORG
Subject: Disabling search function on a form


**
Hi All:

Need some advice on how i can disable the search function from a particular form, with only allowing the administrator the ability to search that particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form -> Current View -> Menu Access. But when i log in to the user tool, i can still open up the form through the object list(i still grant the form Public permission as all users need to see it), under search mode. Once in search mode, i can press F5 and it will search on the form. The advanced search bar is also available to be use. Thus how can i disable the advance search bar and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.




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

This posting was submitted via the Web interface

**
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.

Dear James:

You brought up an interesting point in turn off the Object List Query ability. May i know how may i achieve that?

Thanks all!


"McKenzie, James J C-E LCMC HQISEC/L3" wrote:

Frank:

This is inline with what Remedy tries to do with the ITSM Control Panel.

One point, do not forget to turn off the Object List query capability in the
User Tool. If this is left on, user's can and will select from this list
when they cannot find their 'favorite' form. This bypasses your nice new
Control Panel form. Also, do not forget to educate your existing users on
the new form and what it is supposed to do.

Good luck with your new deployment.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Frank Caruso
Sent: Monday, August 15, 2005 10:51 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


** Actually, the original question was asking

"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the
front end (Control Panel) form for that application to opened. Then, I would
provide functionality that would only allow certain users the ability to
search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3
wrote:
Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under

SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if

of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still

open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar

is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface




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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface



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




--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the
Web interface


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




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

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)

I'm wish to help but I am still not clear.

If OPERATION = QUERY AND VUI != xxx (Message-search
not allowed error)

Will that work?

James Smith
DatumX, LLC

--- "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)

EK:

To turn off the Object List query you have to do the following:

Enable the use of the AR System User Preference form.

Go to the Home Page Tab and select Object List, Disable.

I know that there is another method using the Admin tool (as far as I can
remember) and this will also block access to the Object List.
Unfortunately, I cannot remember how to do this. The process may be in one
of the Administration/Development guides or on the Developer Community page
at the BMCRemedy web site.

Sorry I cannot provide further help as I work strictly in a development
environment.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

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


**
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.

Dear James:

You brought up an interesting point in turn off the Object List Query
ability. May i know how may i achieve that?

Thanks all!


"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Frank:

This is inline with what Remedy tries to do with the ITSM Control Panel.

One point, do not forget to turn off the Object List query capability in the
User Tool. If this is left on, user's can and will select from this list
when they cannot find their 'favorite' form. This bypasses your nice new
Control Panel form. Also, do not forget to educate your existing users on
the new form and what it is supposed to do.

Good luck with your new deployment.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Frank Caruso
Sent: Monday, August 15, 2005 10:51 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


** Actually, the original question was asking

"Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?".

So, I would deploy my forms through an Application object and only allow the
front end (Control Panel) form for that application to opened. Then, I would
provide functionality that would only allow certain users the ability to
search forms based on their permissions.



On 8/15/05, McKenzie, James J C-E LCMC HQISEC/L3
wrote:
Stephen:

Thank you for the correction. I did not read through the question
correctly.

James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Stephen Lumini
Sent: Monday, August 15, 2005 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Actually, no. That only works if they type something in the actual field.
If you want to check the Adv Srch Bar then look at the post I sent Roger
last time this came up:
Hey Roger,

Create an Unlimited Character DO field with ID 1005 on the form for which
you want to restrict the search (I call it AdvSrchContents).
Then write an AL with a run if including the name of the field you want to
restrict (e.g. 'AdvSrchContents' LIKE"%Create Date%") and an error message
of some sort. That's it.

EK-
>>Any advice how i can now achieve that while still allowing my view
>>button to be able to open up a ticket for viewing?
I'm guessing your button uses a macro.
If so then try this -
Add a DO field called "FromMacro"(I used a radio button), re-record the
macro with a value in that field. Now in the original AL add the condition
"FromMacro" = $NULL$
This way the macro passes the qual.

Later
Stephen
Later
Stephen



"McKenzie, James J C-E LCMC HQISEC/L3"
wrote:
Roger:

Of course, add the field name != $NULL$ or if you have a preset value, then
use that value, to the qualification line.
Something like:

$OPERATION$ = "SEARCH" AND 'Submitter' != $NULL$
James McKenzie
Remedy Engineer
C-E LCMC HQISEC
L-3 GSI

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG ]On Behalf Of Nall, Roger
Sent: Monday, August 15, 2005 8:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form


**
Just out of curiosity will this solution work for just one field when using
the Advanced search feature? I want to prevent users from searching from one
field when using the Advanced search feature.

Thanks,

Roger A. Nall
T-Mobile USA
OSSNMS Remedy Developer
Desk: 973-644-3963
PCS: 973-652-6723
FAX: 973-490-3296



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]
Sent: Sunday, August 14, 2005 10:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Disabling search function on a form

**
Hi All:

Thanks for the advice. It seems to be able to achieve what i set out to do,
but unfortunately i encounter another error in the form of table viewing
tickets in the form. Right now a ticket will not be able to be open via my
view button that does an OPEN WINDOW operation to Open up that ticket.

Logs in my AL shows that it is querying the ticket and then displaying it.
However, i do not get the same error using a table drill down. Am i missing
something here?

I've created an AL to disable the search function by setting it to run under

SEARCH as per previously adviced.

Any advice how i can now achieve that while still allowing my view button to
be able to open up a ticket for viewing?
Stephen Lumini wrote:
**
Hi,

The solution I use is to write an AL that fires on Window Open with a Run if

of $OPERATION$ = "SEARCH" and include an error message explaining what the
problem is.

When the window is opened the error message fires and stops all processing,
including opening the window.

You can also add other conditions in the Run If so it only affects certain
Groups.

Later
Stephen


EK wrote:
**
Hi All:

Need some advice on how i can disable the search function from a particular
form, with only allowing the administrator the ability to search that
particular form. How can i achieve that?

I've tried disabling all the search and new search feature under: Form ->
Current View -> Menu Access. But when i log in to the user tool, i can still

open up the form through the object list(i still grant the form Public
permission as all users need to see it), under search mode. Once in search
mode, i can press F5 and it will search on the form. The advanced search bar

is also available to be use. Thus how can i disable the advance search bar
and the F5 function from the normal users?

I'm on ARS 6.0, User and Admin tool 6.0.
Helpdesk 5.5.
Mid tier 6.0.
MSSQL2000.

Any kind advice is much appreciated.



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


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

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
This posting was submitted via the Web
interface




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



ARS 5.1.2
Oracel 9i


Find your next car at Yahoo! Canada Autos This
posting was submitted via the Web interface



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




--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249
AIM:FMAR10 This posting was submitted via the
Web interface



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



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


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

**

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 This posting was submitted via the Web interface

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)

**
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