Matthew ...

Does that same feature apply to search menus that are
dependent on the previous choice, like CTI.

Thanks,
Susan


--- "Watson, Matthew (Melbourne)"
wrote:

> Lars,
>
> In version 6, you can make character fields with
> menus attached to them display like a drop down list
> - the end user cannot type anything into the field
> and is forced to choose something from the menu.
>
> It is a really nice enhancement that's been a long
> time coming. You can still have the option of having
> the menu attached as per normal so that the user can
> type into the field if they want, it's just a simple
> flag that gets changed in the field properties to
> control how it displays.
>
> Cheers,
> Matt
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Thursday, August 12, 2004 3:54 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
> Frederick, seemes that we have designed the system
> in the same way. My dream is that user not are
> allows to write in fields with a menu attached if I
> have set a 'flag for this', sometimes free text can
> be useful, and the menu is just basevalues. But
> often we just want to accept the menuvalues, would
> skip 2 filters, hope Remedy will do something in
> coming versons.
>
> L ars
>
> -----Ursprungligt meddelande-----
> Fran: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]For Grooms, Frederick W
> Skickat: den 11 augusti 2004 17:15
> Till: ARSLIST@ARSLIST.ORG
> Amne: Re: OT:Remedy Annoyances
>
>
> 99% of all my menus are Search menus. As long as
> the values in the menu do not rely on any other
> fields on the form the $MENU$ works. If they do
> rely on other fields then I use a 2 filter method of
> validating.
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Wednesday, August 11, 2004 9:23 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
>
> **
>
> Or create a charmeny, with $MENU$ as pattern. But
> ..likely not the best solution if You often have to
> make changes to the list, add, delete entries, then
> a regular form with filtervalidating the data should
> be a better alternative, changes can be handled
> within the usertool. I try to avoid using hardcoded
> charmenues for that reson.
>
>
>
> L ars
>
>
>
> -----Ursprungligt meddelande-----
> Fran: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]For Palermo, Shelia D
> ERDC-ITL-MS Contractor
> Skickat: den 11 augusti 2004 15:29
> Till: ARSLIST@ARSLIST.ORG
> Amne: Re: OT:Remedy Annoyances
>
>
>
> Why not set the field to be call caps, then all you
> have to worry about is typos.
> Shelia
>
>
>
> -----Original Message-----
> From: Burkholder Anthony O Contr 83 CS/SCZA [
>
> mailto:Anthony.Burkholder@LANGLEY.AF.MIL]
> Sent: Wednesday, August 11, 2004 5:49 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
>
>
> My 2 cents,
>
> The real reason to use a separate table to store
> state information (or similar static data) is to
> prevent users from making the following kinds of
> entries; VA, va, Va, vA, VG, VI, etc for Virginia.
> The problem isn't how often the states have changed
> its how many ways will a user enter the data.
> In the example above a search for all Virginia
> related items would be a nightmare. The trouble
> saved is well worth the 4 bytes.
>
>
>
> Anthony O. Burkholder
> AOC Weapons System Database Administrator
> Dynamics Research Corporation
> (757) 225-7110 / DSN 575-7110
> Email: anthony.burkholder@langley.af.mil
> SIPR Email: anthony.burkholder@c2fs.acc.af.smil.mil
>
>
>
>
> -----Original Message-----
> From: Grooms, Frederick W [
>
> mailto:frederick.w.grooms@XO.COM]
> Sent: Tuesday, August 10, 2004 6:09 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> Of course this is not a problem when you have custom
> apps :)
>
> You are correct on healthy balance. I have a couple
> of systems (not Remedy)
> that I have to pull data from that overkill on
> normalization. i.e. The
> state code in an address is in a separate table and
> all that is stored with the address is a pointer to
> the correct row in the master list. I mean how
> many times has the government changed the
> abbreviation for a state? Why
> waste 4 (or more) bytes of space for a 2 byte
> character?
>
> Fred
>
> -----Original Message-----
>
>

> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
> From: Action Request System discussion list(ARSList)
>
>
>

> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>

> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>
>
>
>
>
>
>
>
>
**********************************************************************
> This email is intended only for the use of the
> individual or entity
> named above and may contain information that is
> confidential and
> privileged. If you are not the intended recipient,
> you are hereby notified that any dissemination,
> distribution or copying of this Email is strictly
> prohibited. When addressed to our clients, any
> opinions or advice contained in this Email are
> subject to the terms and conditions expressed in the
> governing KPMG client engagement letter. If you have
> received this Email in error, please notify us
> immediately by return email or telephone +61 2
> 93357000 and destroy the original message. Thank
> You.
>
**********************************************************************M
>
>

> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>

Lars,

In version 6, you can make character fields with menus attached to them display like a drop down list - the end user cannot type anything into the field and is forced to choose something from the menu.

It is a really nice enhancement that's been a long time coming. You can still have the option of having the menu attached as per normal so that the user can type into the field if they want, it's just a simple flag that gets changed in the field properties to control how it displays.

Cheers,
Matt

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of lars.j.pettersson@VATTENFALL.COM
Sent: Thursday, August 12, 2004 3:54 AM
To: ARSLIST@ARSLIST.ORG
Subject: SV: OT:Remedy Annoyances

Frederick, seemes that we have designed the system in the same way. My dream is that user not are allows to write in fields with a menu attached if I have set a 'flag for this', sometimes free text can be useful, and the menu is just basevalues. But often we just want to accept the menuvalues, would skip 2 filters, hope Remedy will do something in coming versons.

L ars

-----Ursprungligt meddelande-----
Fran: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG]For Grooms, Frederick W
Skickat: den 11 augusti 2004 17:15
Till: ARSLIST@ARSLIST.ORG
Amne: Re: OT:Remedy Annoyances


99% of all my menus are Search menus. As long as the values in the menu do not rely on any other fields on the form the $MENU$ works. If they do rely on other fields then I use a 2 filter method of validating.

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of lars.j.pettersson@VATTENFALL.COM
Sent: Wednesday, August 11, 2004 9:23 AM
To: ARSLIST@ARSLIST.ORG
Subject: SV: OT:Remedy Annoyances


**

Or create a charmeny, with $MENU$ as pattern. But ..likely not the best solution if You often have to make changes to the list, add, delete entries, then a regular form with filtervalidating the data should be a better alternative, changes can be handled within the usertool. I try to avoid using hardcoded charmenues for that reson.



L ars



-----Ursprungligt meddelande-----
Fran: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG]For Palermo, Shelia D ERDC-ITL-MS Contractor
Skickat: den 11 augusti 2004 15:29
Till: ARSLIST@ARSLIST.ORG
Amne: Re: OT:Remedy Annoyances



Why not set the field to be call caps, then all you have to worry about is typos.
Shelia



-----Original Message-----
From: Burkholder Anthony O Contr 83 CS/SCZA [ mailto:Anthony.Burkholder@LANGLEY.AF.MIL]
Sent: Wednesday, August 11, 2004 5:49 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances



My 2 cents,

The real reason to use a separate table to store state information (or similar static data) is to prevent users from making the following kinds of entries; VA, va, Va, vA, VG, VI, etc for Virginia. The problem isn't how often the states have changed its how many ways will a user enter the data.
In the example above a search for all Virginia related items would be a nightmare. The trouble saved is well worth the 4 bytes.



Anthony O. Burkholder
AOC Weapons System Database Administrator
Dynamics Research Corporation
(757) 225-7110 / DSN 575-7110
Email: anthony.burkholder@langley.af.mil
SIPR Email: anthony.burkholder@c2fs.acc.af.smil.mil



-----Original Message-----
From: Grooms, Frederick W [ mailto:frederick.w.grooms@XO.COM]
Sent: Tuesday, August 10, 2004 6:09 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Of course this is not a problem when you have custom apps :)

You are correct on healthy balance. I have a couple of systems (not Remedy)
that I have to pull data from that overkill on normalization. i.e. The
state code in an address is in a separate table and all that is stored with the address is a pointer to the correct row in the master list. I mean how
many times has the government changed the abbreviation for a state? Why
waste 4 (or more) bytes of space for a 2 byte character?

Fred

-----Original Message-----



From: Action Request System discussion list(ARSList)















**********************************************************************
This email is intended only for the use of the individual or entity
named above and may contain information that is confidential and
privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. When addressed to our clients, any opinions or advice contained in this Email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 93357000 and destroy the original message. Thank You.
**********************************************************************M

Any search menu. The behavior is a little different on the web though
(floating values as opposed to the drop down feel), and the arrows look a
little different; but the feature is nice.

Axton

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Susan Palmer
Sent: Wednesday, August 11, 2004 6:39 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Matthew ...

Does that same feature apply to search menus that are
dependent on the previous choice, like CTI.

Thanks,
Susan


--- "Watson, Matthew (Melbourne)"
wrote:

> Lars,
>
> In version 6, you can make character fields with
> menus attached to them display like a drop down list
> - the end user cannot type anything into the field
> and is forced to choose something from the menu.
>
> It is a really nice enhancement that's been a long
> time coming. You can still have the option of having
> the menu attached as per normal so that the user can
> type into the field if they want, it's just a simple
> flag that gets changed in the field properties to
> control how it displays.
>
> Cheers,
> Matt
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Thursday, August 12, 2004 3:54 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
> Frederick, seemes that we have designed the system
> in the same way. My dream is that user not are
> allows to write in fields with a menu attached if I
> have set a 'flag for this', sometimes free text can
> be useful, and the menu is just basevalues. But
> often we just want to accept the menuvalues, would
> skip 2 filters, hope Remedy will do something in
> coming versons.
>
> L ars
>
> -----Ursprungligt meddelande-----
> Fren: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]Fvr Grooms, Frederick W
> Skickat: den 11 augusti 2004 17:15
> Till: ARSLIST@ARSLIST.ORG
> Dmne: Re: OT:Remedy Annoyances
>
>
> 99% of all my menus are Search menus. As long as
> the values in the menu do not rely on any other
> fields on the form the $MENU$ works. If they do
> rely on other fields then I use a 2 filter method of
> validating.
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Wednesday, August 11, 2004 9:23 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
>
> **
>
> Or create a charmeny, with $MENU$ as pattern. But
> ..likely not the best solution if You often have to
> make changes to the list, add, delete entries, then
> a regular form with filtervalidating the data should
> be a better alternative, changes can be handled
> within the usertool. I try to avoid using hardcoded
> charmenues for that reson.
>
>
>
> L ars
>
>
>
> -----Ursprungligt meddelande-----
> Fren: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]Fvr Palermo, Shelia D
> ERDC-ITL-MS Contractor
> Skickat: den 11 augusti 2004 15:29
> Till: ARSLIST@ARSLIST.ORG
> Dmne: Re: OT:Remedy Annoyances
>
>
>
> Why not set the field to be call caps, then all you
> have to worry about is typos.
> Shelia
>
>
>
> -----Original Message-----
> From: Burkholder Anthony O Contr 83 CS/SCZA [
>
> mailto:Anthony.Burkholder@LANGLEY.AF.MIL]
> Sent: Wednesday, August 11, 2004 5:49 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
>
>
> My 2 cents,
>
> The real reason to use a separate table to store
> state information (or similar static data) is to
> prevent users from making the following kinds of
> entries; VA, va, Va, vA, VG, VI, etc for Virginia.
> The problem isn't how often the states have changed
> its how many ways will a user enter the data.
> In the example above a search for all Virginia
> related items would be a nightmare. The trouble
> saved is well worth the 4 bytes.
>
>
>
> Anthony O. Burkholder
> AOC Weapons System Database Administrator
> Dynamics Research Corporation
> (757) 225-7110 / DSN 575-7110
> Email: anthony.burkholder@langley.af.mil
> SIPR Email: anthony.burkholder@c2fs.acc.af.smil.mil
>
>
>
>
> -----Original Message-----
> From: Grooms, Frederick W [
>
> mailto:frederick.w.grooms@XO.COM]
> Sent: Tuesday, August 10, 2004 6:09 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> Of course this is not a problem when you have custom
> apps :)
>
> You are correct on healthy balance. I have a couple
> of systems (not Remedy)
> that I have to pull data from that overkill on
> normalization. i.e. The
> state code in an address is in a separate table and
> all that is stored with the address is a pointer to
> the correct row in the master list. I mean how
> many times has the government changed the
> abbreviation for a state? Why
> waste 4 (or more) bytes of space for a 2 byte
> character?
>
> Fred
>
> -----Original Message-----
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
> From: Action Request System discussion list(ARSList)
>
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>
>
>
>
>
>
>
>
>
**********************************************************************
> This email is intended only for the use of the
> individual or entity
> named above and may contain information that is
> confidential and
> privileged. If you are not the intended recipient,
> you are hereby notified that any dissemination,
> distribution or copying of this Email is strictly
> prohibited. When addressed to our clients, any
> opinions or advice contained in this Email are
> subject to the terms and conditions expressed in the
> governing KPMG client engagement letter. If you have
> received this Email in error, please notify us
> immediately by return email or telephone +61 2
> 93357000 and destroy the original message. Thank
> You.
>
**********************************************************************M
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES at
www.QMXS.com

Hello all,

While we are still on this topic of discussing our wish-list, a internal Remedy User
password management system is something I'm sure a lot would have wanted in the event
that the user authentication is internal... I know that there are some real slick apps
available built by the likes of Bruce to achieve this but if this feature was
'built-in' I think I would have liked that at least...

Regards


=====
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail

Hi, I found /thanks Doug) that this is possible even in pre ver 6, set 'display as text' for the field, then the menybutton is still there, but it's not possible to write in the field, only select data using the menubutton. The data is displayed as 'plain text', not in a field, but it works! I have tried with searchnmenus, suppose there is no limitation/menutypes, but I have to test more.

L ars

-----Ursprungligt meddelande-----
Fran: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] For Axton Grams
Skickat: den 12 augusti 2004 00:58
Till: ARSLIST@ARSLIST.ORG
Amne: Re: OT:Remedy Annoyances

Any search menu. The behavior is a little different on the web though
(floating values as opposed to the drop down feel), and the arrows look a
little different; but the feature is nice.

Axton

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Susan Palmer
Sent: Wednesday, August 11, 2004 6:39 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Matthew ...

Does that same feature apply to search menus that are
dependent on the previous choice, like CTI.

Thanks,
Susan


--- "Watson, Matthew (Melbourne)"
wrote:

> Lars,
>
> In version 6, you can make character fields with
> menus attached to them display like a drop down list
> - the end user cannot type anything into the field
> and is forced to choose something from the menu.
>
> It is a really nice enhancement that's been a long
> time coming. You can still have the option of having
> the menu attached as per normal so that the user can
> type into the field if they want, it's just a simple
> flag that gets changed in the field properties to
> control how it displays.
>
> Cheers,
> Matt
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Thursday, August 12, 2004 3:54 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
> Frederick, seemes that we have designed the system
> in the same way. My dream is that user not are
> allows to write in fields with a menu attached if I
> have set a 'flag for this', sometimes free text can
> be useful, and the menu is just basevalues. But
> often we just want to accept the menuvalues, would
> skip 2 filters, hope Remedy will do something in
> coming versons.
>
> L ars
>
> -----Ursprungligt meddelande-----
> Fren: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]Fvr Grooms, Frederick W
> Skickat: den 11 augusti 2004 17:15
> Till: ARSLIST@ARSLIST.ORG
> Dmne: Re: OT:Remedy Annoyances
>
>
> 99% of all my menus are Search menus. As long as
> the values in the menu do not rely on any other
> fields on the form the $MENU$ works. If they do
> rely on other fields then I use a 2 filter method of
> validating.
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of
> lars.j.pettersson@VATTENFALL.COM
> Sent: Wednesday, August 11, 2004 9:23 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: SV: OT:Remedy Annoyances
>
>
> **
>
> Or create a charmeny, with $MENU$ as pattern. But
> ..likely not the best solution if You often have to
> make changes to the list, add, delete entries, then
> a regular form with filtervalidating the data should
> be a better alternative, changes can be handled
> within the usertool. I try to avoid using hardcoded
> charmenues for that reson.
>
>
>
> L ars
>
>
>
> -----Ursprungligt meddelande-----
> Fren: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG]Fvr Palermo, Shelia D
> ERDC-ITL-MS Contractor
> Skickat: den 11 augusti 2004 15:29
> Till: ARSLIST@ARSLIST.ORG
> Dmne: Re: OT:Remedy Annoyances
>
>
>
> Why not set the field to be call caps, then all you
> have to worry about is typos.
> Shelia
>
>
>
> -----Original Message-----
> From: Burkholder Anthony O Contr 83 CS/SCZA [
>
> mailto:Anthony.Burkholder@LANGLEY.AF.MIL]
> Sent: Wednesday, August 11, 2004 5:49 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
>
>
> My 2 cents,
>
> The real reason to use a separate table to store
> state information (or similar static data) is to
> prevent users from making the following kinds of
> entries; VA, va, Va, vA, VG, VI, etc for Virginia.
> The problem isn't how often the states have changed
> its how many ways will a user enter the data.
> In the example above a search for all Virginia
> related items would be a nightmare. The trouble
> saved is well worth the 4 bytes.
>
>
>
> Anthony O. Burkholder
> AOC Weapons System Database Administrator
> Dynamics Research Corporation
> (757) 225-7110 / DSN 575-7110
> Email: anthony.burkholder@langley.af.mil
> SIPR Email: anthony.burkholder@c2fs.acc.af.smil.mil
>
>
>
>
> -----Original Message-----
> From: Grooms, Frederick W [
>
> mailto:frederick.w.grooms@XO.COM]
> Sent: Tuesday, August 10, 2004 6:09 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> Of course this is not a problem when you have custom
> apps :)
>
> You are correct on healthy balance. I have a couple
> of systems (not Remedy)
> that I have to pull data from that overkill on
> normalization. i.e. The
> state code in an address is in a separate table and
> all that is stored with the address is a pointer to
> the correct row in the master list. I mean how
> many times has the government changed the
> abbreviation for a state? Why
> waste 4 (or more) bytes of space for a 2 byte
> character?
>
> Fred
>
> -----Original Message-----
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
> From: Action Request System discussion list(ARSList)
>
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>
>
>
>
>
>
>
>
>
>
**********************************************************************
> This email is intended only for the use of the
> individual or entity
> named above and may contain information that is
> confidential and
> privileged. If you are not the intended recipient,
> you are hereby notified that any dissemination,
> distribution or copying of this Email is strictly
> prohibited. When addressed to our clients, any
> opinions or advice contained in this Email are
> subject to the terms and conditions expressed in the
> governing KPMG client engagement letter. If you have
> received this Email in error, please notify us
> immediately by return email or telephone +61 2
> 93357000 and destroy the original message. Thank
> You.
>
**********************************************************************M
>
>


> UNSUBSCRIBE or access ARSList Archives at
> http://www.ARSLIST.org (Support:
> mailto:support@arslist.org ) ARSList is hosted by
> QMX SUPPORT SERVICES at www.QMXS.com
>



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES at
www.QMXS.com

Let me second this motion. The state auditors are demanding strong
passwords, password aging, previous password prevention, etc., etc., and
while this is easy enough to implement at the OS level, many
applications (Remedy for one) do not support these restrictions in the
base product. I also need to be able to present an authorized user
security warning at login - easy on mid-tier but not on the User Tool
where you would have to hack the executable. We need to be able to set
these sorts of things on the AR Server, and let the clients enforce
them.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/

-----Original Message-----
From: Joe DeSouza [mailto:joeremedy@YAHOO.COM]
Sent: Thursday, August 12, 2004 12:42 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hello all,

While we are still on this topic of discussing our wish-list, a internal
Remedy User password management system is something I'm sure a lot would
have wanted in the event that the user authentication is internal... I
know that there are some real slick apps available built by the likes of
Bruce to achieve this but if this feature was 'built-in' I think I would
have liked that at least...

Regards


=====
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com

You could use Init-Form to bring a dialog up every time somebody logs in.
Then on close go to the Support form (or whatever yours may be). Regarding
passwords, I think the movement will be to use AREA/LDAP. There is no need
to keep all this information in silos all over the place.

Jack

-----Original Message-----
From: strauss [mailto:strauss@REMEDY.ACS.UNT.EDU]
Sent: Thursday, August 12, 2004 7:27 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


Let me second this motion. The state auditors are demanding strong
passwords, password aging, previous password prevention, etc., etc., and
while this is easy enough to implement at the OS level, many
applications (Remedy for one) do not support these restrictions in the
base product. I also need to be able to present an authorized user
security warning at login - easy on mid-tier but not on the User Tool
where you would have to hack the executable. We need to be able to set
these sorts of things on the AR Server, and let the clients enforce
them.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/=20

-----Original Message-----
From: Joe DeSouza [mailto:joeremedy@YAHOO.COM]=20
Sent: Thursday, August 12, 2004 12:42 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hello all,

While we are still on this topic of discussing our wish-list, a internal
Remedy User password management system is something I'm sure a lot would
have wanted in the event that the user authentication is internal... I
know that there are some real slick apps available built by the likes of
Bruce to achieve this but if this feature was 'built-in' I think I would
have liked that at least...

Regards


=3D=3D=3D=3D=3D
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES at
www.QMXS.com

We have already begun enforcing strong password security on the LDAP
server, which directly affects all AREA authentication, but that has no
effect on those support staff who set a LOCAL password in the User form
- which we have encouraged since they can still login and create tickets
when the LDAP server IS THE PROBLEM. eDir has been more reliable of
late, but every time they patch it or change the OS (was on Solaris,
then Linux, then NetWare - which has been the most stable) it has
hiccups that CANNOT be allowed to interfere with helpdesk staff entering
tickets, especially since when eDir breaks so many campus systems stop
working at once that the helpdesk telephones all explode! So, I need
similar controls on passwords in the User form, as will any site that is
not able to use external authentication for one reason or another.

The ability to set a login banner in the User Tool might be solved
through the Init-Form or ARS 6 Home Page (whenever we migrate to ARS
6.x), but in each case we are having to do custom application
development to work around a basic system limitation that COULD be
solved in the client-server application. My to-do list (Change Request
queue) is already overfull implementing and maintaining the ITSM apps
without having to develop basic security and system features as well.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/

-----Original Message-----
From: Covert, Jack [mailto:Jack.Covert@MCKESSON.COM]
Sent: Thursday, August 12, 2004 10:50 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

You could use Init-Form to bring a dialog up every time somebody logs
in.
Then on close go to the Support form (or whatever yours may be).
Regarding passwords, I think the movement will be to use AREA/LDAP.
There is no need to keep all this information in silos all over the
place.

Jack

-----Original Message-----
From: strauss [mailto:strauss@REMEDY.ACS.UNT.EDU]
Sent: Thursday, August 12, 2004 7:27 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


Let me second this motion. The state auditors are demanding strong
passwords, password aging, previous password prevention, etc., etc., and
while this is easy enough to implement at the OS level, many
applications (Remedy for one) do not support these restrictions in the
base product. I also need to be able to present an authorized user
security warning at login - easy on mid-tier but not on the User Tool
where you would have to hack the executable. We need to be able to set
these sorts of things on the AR Server, and let the clients enforce
them.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center http://remedy.unt.edu/=20

-----Original Message-----
From: Joe DeSouza [mailto:joeremedy@YAHOO.COM]=20
Sent: Thursday, August 12, 2004 12:42 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hello all,

While we are still on this topic of discussing our wish-list, a internal
Remedy User password management system is something I'm sure a lot would
have wanted in the event that the user authentication is internal... I
know that there are some real slick apps available built by the likes of
Bruce to achieve this but if this feature was 'built-in' I think I would
have liked that at least...

Regards


=3D=3D=3D=3D=3D
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com




UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES
at www.QMXS.com



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com

**
OK, here's something I would like to see. How about the ability to disable individual actions in an AL or Filter, for debug purposes? It's a minor thing, but would be nice sometimes to not have to delete and then reconstruct certain actions.

Rick



From: strauss
Sent: Thu 8/12/2004 9:15 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


We have already begun enforcing strong password security on the LDAP
server, which directly affects all AREA authentication, but that has no
effect on those support staff who set a LOCAL password in the User form
- which we have encouraged since they can still login and create tickets
when the LDAP server IS THE PROBLEM. eDir has been more reliable of
late, but every time they patch it or change the OS (was on Solaris,
then Linux, then NetWare - which has been the most stable) it has
hiccups that CANNOT be allowed to interfere with helpdesk staff entering
tickets, especially since when eDir breaks so many campus systems stop
working at once that the helpdesk telephones all explode! So, I need
similar controls on passwords in the User form, as will any site that is
not able to use external authentication for one reason or another.

The ability to set a login banner in the User Tool might be solved
through the Init-Form or ARS 6 Home Page (whenever we migrate to ARS
6.x), but in each case we are having to do custom application
development to work around a basic system limitation that COULD be
solved in the client-server application. My to-do list (Change Request
queue) is already overfull implementing and maintaining the ITSM apps
without having to develop basic security and system features as well.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/

-----Original Message-----
From: Covert, Jack [mailto:Jack.Covert@MCKESSON.COM]
Sent: Thursday, August 12, 2004 10:50 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

You could use Init-Form to bring a dialog up every time somebody logs
in.
Then on close go to the Support form (or whatever yours may be).
Regarding passwords, I think the movement will be to use AREA/LDAP.
There is no need to keep all this information in silos all over the
place.

Jack

-----Original Message-----
From: strauss [mailto:strauss@REMEDY.ACS.UNT.EDU]
Sent: Thursday, August 12, 2004 7:27 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


Let me second this motion. The state auditors are demanding strong
passwords, password aging, previous password prevention, etc., etc., and
while this is easy enough to implement at the OS level, many
applications (Remedy for one) do not support these restrictions in the
base product. I also need to be able to present an authorized user
security warning at login - easy on mid-tier but not on the User Tool
where you would have to hack the executable. We need to be able to set
these sorts of things on the AR Server, and let the clients enforce
them.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center http://remedy.unt.edu/=20

-----Original Message-----
From: Joe DeSouza [mailto:joeremedy@YAHOO.COM]=20
Sent: Thursday, August 12, 2004 12:42 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hello all,

While we are still on this topic of discussing our wish-list, a internal
Remedy User password management system is something I'm sure a lot would
have wanted in the event that the user authentication is internal... I
know that there are some real slick apps available built by the likes of
Bruce to achieve this but if this feature was 'built-in' I think I would
have liked that at least...

Regards


=3D=3D=3D=3D=3D
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com




UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES
at www.QMXS.com



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com





This posting was submitted via the Web interface

**
The problem with using the Init-Form is that the user has to successfully log in first. One of our requirements is to lock out a user after three bad attempts.
As for LDAP - we are not in a position to make use of that because a good number of our users are external and they don't have accounts anywhere else.
And finally, although it's makes life simpler for users, having one password to get into Everything" is never a good idea.

Later
Stephen


"Covert, Jack" wrote:

You could use Init-Form to bring a dialog up every time somebody logs in.
Then on close go to the Support form (or whatever yours may be). Regarding
passwords, I think the movement will be to use AREA/LDAP. There is no need
to keep all this information in silos all over the place.

Jack

-----Original Message-----
From: strauss [mailto:strauss@REMEDY.ACS.UNT.EDU]
Sent: Thursday, August 12, 2004 7:27 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


Let me second this motion. The state auditors are demanding strong
passwords, password aging, previous password prevention, etc., etc., and
while this is easy enough to implement at the OS level, many
applications (Remedy for one) do not support these restrictions in the
base product. I also need to be able to present an authorized user
security warning at login ! - easy on mid-tier but not on the User Tool
where you would have to hack the executable. We need to be able to set
these sorts of things on the AR Server, and let the clients enforce
them.

Christopher Strauss, MSLS
Remedy Database Administrator
University of North Texas Computing Center
http://remedy.unt.edu/=20

-----Original Message-----
From: Joe DeSouza [mailto:joeremedy@YAHOO.COM]=20
Sent: Thursday, August 12, 2004 12:42 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hello all,

While we are still on this topic of discussing our wish-list, a internal
Remedy User password management system is something I'm sure a lot would
have wanted in the event that the user authentication is internal... I
know that there are some real slick apps available built by the likes of
Bruce to achieve this but if this feature was 'built-in' I think I would
have liked that at least...

Regards


=3D=3D=3D=3D=3D
Joe DeSouza,
Remedy Technical Consultant,
CyberMAK Information Systems,
Kuwait.
Phone :- 00965 484 7068
Mobile :- 00965 940 6129








Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/newmail



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT
SERVICES at www.QMXS.com



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES This posting was submitted via the Web interface at
www.QMXS.com









Post your free ad now! Yahoo! Canada Personals