I have one dream, create a unique dbid, like 536970412 and set a flag as 'master'

Then u can use this dbid in 100 regular forms, and set a flag as 'relation to masterid'

If u change the value for the masterid 536970412 from A to B, all other forms with this id will be updated, without having to build wf for that update, let ars take care of that ...

I think a timecomsuming part building a large arssystem is to keep fields 'up to date' with push field action and so.

I know ARS not is build like Access as a relational databasesystem, advantages and disadvantages ...

L ars

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of William Rentfrow
Sent: Thursday, August 12, 2004 7:27 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

The one feature I'd like to see is the ability to create variables/keywords. It is simply silly how many forms have 20+ "zTmpxxxxxx" fields that are used only for data processing.

It would be nice if you had the ability during form creation to define admin-created keywords specific to that form (globally would be nice too but that's a whole other ball of wax).

So, instead of creating a field "zTmpHeresMyFieldForFlaggingStuff" I could define a keyword $TEMPFIELD1$, along with a default value. This has two benefits. First, you don't have to place the field on the form and make sure it is or is not in 15 different views. Secondly, it takes it out of the list selection.

AND, it makes it more like "normal" programming.

In a perfect dream world, these would allow arrays, list variables, etc...but I'm not that optimisitic :)

I agree this is the idea behind a display only field - and that is what I was referring to (but did not say directly).

However, display only fields have a definite purpose when designing GUI's and using them essentially as variables seems (IMHO) like an afterthought. I rather doubt they were originally intende for what we all use them for.

I'd prefer more of a traditional variable-like mechanism, and keywords would be right up that alley. Remedy has them already. Expanding their functionality would be a simple step for current users to learn and administer.

As far as the list selection - yes, I was referring to the admin tool.


-----Original Message-----
From: Action Request System discussion list(ARSList) on behalf of Axton W Grams/NYLIC
Sent: Thu 8/12/2004 1:09 PM
To: ARSLIST@ARSLIST.ORG
Cc:
Subject: Re: OT:Remedy Annoyances

See comments below.

Kind Regards,
Axton Grams
New York Life
Remedy Solutions
Provider

Mobile: 404.861.7273
Work: 770.406.4415
Email: AxtonWGrams@NewYorkLife.com






|---------+---------------------------->
| | William Rentfrow |
| | | | COMINC.COM> |
| | Sent by: "Action |
| | Request System |
| | discussion |
| | list(ARSList)" |
| | | | ORG> |
| | |
| | |
| | 08/12/2004 01:27 |
| | PM |
| | Please respond to|
| | arslist |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: ARSLIST@ARSLIST.ORG |
| cc: |
| Subject: Re: OT:Remedy Annoyances |
>------------------------------------------------------------------------------------------------------------------------------|




The one feature I'd like to see is the ability to create
variables/keywords. It is simply silly how many forms have 20+
"zTmpxxxxxx" fields that are used only for data processing.

** This is the idea behind a display-only field. No db overhead.

It would be nice if you had the ability during form creation to define
admin-created keywords specific to that form (globally would be nice too
but that's a whole other ball of wax).

** This can be accomplished using global fields if they are static to a
given session(regular) or a given window(window-scoped).

So, instead of creating a field "zTmpHeresMyFieldForFlaggingStuff" I could
define a keyword $TEMPFIELD1$, along with a default value. This has two
benefits. First, you don't have to place the field on the form and make
sure it is or is not in 15 different views. Secondly, it takes it out of
the list selection.

** Fields can be removed from the list selection (for reporting and QBE)
for end users by removing it from the view. Maybe you are referring to the
list selection in the admin tool.

AND, it makes it more like "normal" programming.

In a perfect dream world, these would allow arrays, list variables,
etc...but I'm not that optimisitic :)

** The idea of an array type for fields is a good one. Instead of having
zTmpInt1, zTmpInt2, you could have zTmpInt[x]. Even a reserved range for
Remedy where x>1 and x<1000, and all others are free game. This could
allow for a standard set of array fields for all forms per data type for
processing, though the naming/understanding would get increasingly
confusing as the usage of a given array expanded.



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

I have done this with good results.
I have also gone as far as to put a box behind the field to make it look
like a read only field :)

Mark

----- Original Message -----
From:
To:
Sent: Thursday, August 12, 2004 2:23 AM
Subject: SV: OT:Remedy Annoyances


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



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

What a great idea ...

But why not also have the option to have a change in
value in that field on any form update all the other
records.

Susan





--- lars.j.pettersson@VATTENFALL.COM wrote:

> I have one dream, create a unique dbid, like
> 536970412 and set a flag as 'master'
>
> Then u can use this dbid in 100 regular forms, and
> set a flag as 'relation to masterid'
>
> If u change the value for the masterid 536970412
> from A to B, all other forms with this id will be
> updated, without having to build wf for that update,
> let ars take care of that ...
>
> I think a timecomsuming part building a large
> arssystem is to keep fields 'up to date' with push
> field action and so.
>
> I know ARS not is build like Access as a relational
> databasesystem, advantages and disadvantages ...
>
> L ars
>
> -----Original Message-----
> From: Action Request System discussion
> list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On
> Behalf Of William Rentfrow
> Sent: Thursday, August 12, 2004 7:27 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> The one feature I'd like to see is the ability to
> create variables/keywords. It is simply silly how
> many forms have 20+ "zTmpxxxxxx" fields that are
> used only for data processing.
>
> It would be nice if you had the ability during form
> creation to define admin-created keywords specific
> to that form (globally would be nice too but that's
> a whole other ball of wax).
>
> So, instead of creating a field
> "zTmpHeresMyFieldForFlaggingStuff" I could define a
> keyword $TEMPFIELD1$, along with a default value.
> This has two benefits. First, you don't have to
> place the field on the form and make sure it is or
> is not in 15 different views. Secondly, it takes it
> out of the list selection.
>
> AND, it makes it more like "normal" programming.
>
> In a perfect dream world, these would allow arrays,
> list variables, etc...but I'm not that optimisitic
> :)
>
>

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

I remember Doug talking about the desire to have global data elements a couple of years ago, but I don't know what the status of that is. Just wanted you to know that they ARE thinking about things like that.

Susan's wish seems more like a normalized DB structure. For a number of reasons, I don't see them going there.

Rick



From: Action Request System discussion list(ARSList) on behalf of Susan Palmer
Sent: Thu 8/12/2004 4:43 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances



What a great idea ...

But why not also have the option to have a change in
value in that field on any form update all the other
records.

Susan





--- lars.j.pettersson@VATTENFALL.COM wrote:

> I have one dream, create a unique dbid, like
> 536970412 and set a flag as 'master'
>
> Then u can use this dbid in 100 regular forms, and
> set a flag as 'relation to masterid'
>
> If u change the value for the masterid 536970412
> from A to B, all other forms with this id will be
> updated, without having to build wf for that update,
> let ars take care of that ...
>
> I think a timecomsuming part building a large
> arssystem is to keep fields 'up to date' with push
> field action and so.
>
> I know ARS not is build like Access as a relational
> databasesystem, advantages and disadvantages ...
>
> L ars
>
> -----Original Message-----
> From: Action Request System discussion
> list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On
> Behalf Of William Rentfrow
> Sent: Thursday, August 12, 2004 7:27 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> The one feature I'd like to see is the ability to
> create variables/keywords. It is simply silly how
> many forms have 20+ "zTmpxxxxxx" fields that are
> used only for data processing.
>
> It would be nice if you had the ability during form
> creation to define admin-created keywords specific
> to that form (globally would be nice too but that's
> a whole other ball of wax).
>
> So, instead of creating a field
> "zTmpHeresMyFieldForFlaggingStuff" I could define a
> keyword $TEMPFIELD1$, along with a default value.
> This has two benefits. First, you don't have to
> place the field on the form and make sure it is or
> is not in 15 different views. Secondly, it takes it
> out of the list selection.
>
> AND, it makes it more like "normal" programming.
>
> In a perfect dream world, these would allow arrays,
> list variables, etc...but I'm not that optimisitic
> :)
>
>

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

Hmmm... not sure if the following has already been mentioned - basically the idea is, to get more out of the Admin client, making it more compareable to a "real" coding editors.

You know, such little things as little as coloring brackets for example. Being able to drag n' drop actions from one AL to another, converting AL's to filters, more debugging and real time monitoring of variables - also like the log file telling you "qualificaton of AL xxx failed" - yeah, nice. But failed why ? What part ? ... and so on :-)

Basically I think that the whole idea of having those little own windows for single AL's and such may perhaps be something that could get improved, or taking another direction basically, like more diplaying those flat like code snippets too, where you can modify per text directly and copy n paste even or such things.

Well, not really annoyances those are. I think the Admin Client is real good - but I think that there is room for improvements too.


Cheers from Germany - tgif - Robert


-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Friday, August 13, 2004 3:25 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances


I remember Doug talking about the desire to have global data elements a couple of years ago, but I don't know what the status of that is. Just wanted you to know that they ARE thinking about things like that.

Susan's wish seems more like a normalized DB structure. For a number of reasons, I don't see them going there.

Rick



From: Action Request System discussion list(ARSList) on behalf of Susan Palmer
Sent: Thu 8/12/2004 4:43 PM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances



What a great idea ...

But why not also have the option to have a change in
value in that field on any form update all the other
records.

Susan





--- lars.j.pettersson@VATTENFALL.COM wrote:

> I have one dream, create a unique dbid, like
> 536970412 and set a flag as 'master'
>
> Then u can use this dbid in 100 regular forms, and
> set a flag as 'relation to masterid'
>
> If u change the value for the masterid 536970412
> from A to B, all other forms with this id will be
> updated, without having to build wf for that update,
> let ars take care of that ...
>
> I think a timecomsuming part building a large
> arssystem is to keep fields 'up to date' with push
> field action and so.
>
> I know ARS not is build like Access as a relational
> databasesystem, advantages and disadvantages ...
>
> L ars
>
> -----Original Message-----
> From: Action Request System discussion
> list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On
> Behalf Of William Rentfrow
> Sent: Thursday, August 12, 2004 7:27 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
> The one feature I'd like to see is the ability to
> create variables/keywords. It is simply silly how
> many forms have 20+ "zTmpxxxxxx" fields that are
> used only for data processing.
>
> It would be nice if you had the ability during form
> creation to define admin-created keywords specific
> to that form (globally would be nice too but that's
> a whole other ball of wax).
>
> So, instead of creating a field
> "zTmpHeresMyFieldForFlaggingStuff" I could define a
> keyword $TEMPFIELD1$, along with a default value.
> This has two benefits. First, you don't have to
> place the field on the form and make sure it is or
> is not in 15 different views. Secondly, it takes it
> out of the list selection.
>
> AND, it makes it more like "normal" programming.
>
> In a perfect dream world, these would allow arrays,
> list variables, etc...but I'm not that optimisitic
> :)
>
>

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

Hi,

I submitted and enhancement request (RFE 2620) in September 1999 on this topic.
This particular RFE has a status of 'Retired'. I resubmitted it in November
2002 (RFE 6182). It has the status of 'Assigned'.

Perhaps if more people were to request this enhancement then Remedy may look
into it.

Nyall

Quoting Rick Cook :

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

All,

Not sure how useful everyone would find this, but a
lot of times I have to create several change field
actions for fields that I need to change the display
attributes like making a whole bunch of fields hidden
or read-only. It would be nice if the change field
action would allow you to (if required) select
multiple fields and specify read-only or hidden or
other appropriate actions rather than have to add the
Change field action individually for each field. This
sometimes leads to creating more than one AL if you
have more than 24 fields for which you are changing
the display property of the fields. Maybe something
similar like how the set fields actions work.

Also how about an additional execute on for "Mouse
Over" in addition to gain and lose focus in the
execute on in AL's?

Regards,
Saby

--- "Kern Robert (SBA)"
wrote:

> Hmmm... not sure if the following has already been
> mentioned - basically the idea is, to get more out
> of the Admin client, making it more compareable to a
> "real" coding editors.
>
> You know, such little things as little as coloring
> brackets for example. Being able to drag n' drop
> actions from one AL to another, converting AL's to
> filters, more debugging and real time monitoring of
> variables - also like the log file telling you
> "qualificaton of AL xxx failed" - yeah, nice. But
> failed why ? What part ? ... and so on :-)
>
> Basically I think that the whole idea of having
> those little own windows for single AL's and such
> may perhaps be something that could get improved, or
> taking another direction basically, like more
> diplaying those flat like code snippets too, where
> you can modify per text directly and copy n paste
> even or such things.
>
> Well, not really annoyances those are. I think the
> Admin Client is real good - but I think that there
> is room for improvements too.
>
>
> Cheers from Germany - tgif - Robert
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Rick Cook
> Sent: Friday, August 13, 2004 3:25 AM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
>
> I remember Doug talking about the desire to have
> global data elements a couple of years ago, but I
> don't know what the status of that is. Just wanted
> you to know that they ARE thinking about things like
> that.
>
> Susan's wish seems more like a normalized DB
> structure. For a number of reasons, I don't see
> them going there.
>
> Rick
>
>
>
> From: Action Request System discussion list(ARSList)
> on behalf of Susan Palmer
> Sent: Thu 8/12/2004 4:43 PM
> To: ARSLIST@ARSLIST.ORG
> Subject: Re: OT:Remedy Annoyances
>
>
>
> What a great idea ...
>
> But why not also have the option to have a change in
> value in that field on any form update all the other
> records.
>
> Susan
>
>
>
>
>
> --- lars.j.pettersson@VATTENFALL.COM wrote:
>
> > I have one dream, create a unique dbid, like
> > 536970412 and set a flag as 'master'
> >
> > Then u can use this dbid in 100 regular forms, and
> > set a flag as 'relation to masterid'
> >
> > If u change the value for the masterid 536970412
> > from A to B, all other forms with this id will be
> > updated, without having to build wf for that
> update,
> > let ars take care of that ...
> >
> > I think a timecomsuming part building a large
> > arssystem is to keep fields 'up to date' with push
> > field action and so.
> >
> > I know ARS not is build like Access as a
> relational
> > databasesystem, advantages and disadvantages ...
> >
> > L ars
> >
> > -----Original Message-----
> > From: Action Request System discussion
> > list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On
> > Behalf Of William Rentfrow
> > Sent: Thursday, August 12, 2004 7:27 PM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: OT:Remedy Annoyances
> >
> > The one feature I'd like to see is the ability to
> > create variables/keywords. It is simply silly how
> > many forms have 20+ "zTmpxxxxxx" fields that are
> > used only for data processing.
> >
> > It would be nice if you had the ability during
> form
> > creation to define admin-created keywords specific
> > to that form (globally would be nice too but
> that's
> > a whole other ball of wax).
> >
> > So, instead of creating a field
> > "zTmpHeresMyFieldForFlaggingStuff" I could define
> a
> > keyword $TEMPFIELD1$, along with a default value.
> > This has two benefits. First, you don't have to
> > place the field on the form and make sure it is or
> > is not in 15 different views. Secondly, it takes
> it
> > out of the list selection.
> >
> > AND, it makes it more like "normal" programming.
> >
> > In a perfect dream world, these would allow
> arrays,
> > list variables, etc...but I'm not that optimisitic
> > :)
> >
> >
>

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

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





Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/newmail

I have submitted an eng req long time ago, to populate a field when You are creating a 'display a list AL'. Enter a text in the field 'Select the Statecode from the list' for example, its not always so easy for users to understand what ldisplaylist really shows, should be rather easy to set this text as head instead of the standard selection list ..I also want columheaders in the selection list. Much more userfrienly.. I wonder if there is any meaning leaving enh req on Remedys site - I expected some form of email back when they change status of an entry. Hopefylly Remedy are reading all we have written about on the list the last week, and maybe implement something in coming releases ..

L ars

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Nyall McCavitt
Sent: Friday, August 13, 2004 8:55 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: OT:Remedy Annoyances

Hi,

I submitted and enhancement request (RFE 2620) in September 1999 on this topic.
This particular RFE has a status of 'Retired'. I resubmitted it in November
2002 (RFE 6182). It has the status of 'Assigned'.

Perhaps if more people were to request this enhancement then Remedy may look
into it.

Nyall

Quoting Rick Cook :

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

I like the Change field idea ... and I believe it
crosses my mind everytime I have to do that because it
never seems to be just one field.

Why couldn't it work like a set field where you pick
the field and then you could pick what you want to
happen to that field, hidden or visible etc.

Susan


--- Sabyson Fernandes wrote:

> All,
>
> Not sure how useful everyone would find this, but a
> lot of times I have to create several change field
> actions for fields that I need to change the display
> attributes like making a whole bunch of fields
> hidden
> or read-only. It would be nice if the change field
> action would allow you to (if required) select
> multiple fields and specify read-only or hidden or
> other appropriate actions rather than have to add
> the
> Change field action individually for each field.
> This
> sometimes leads to creating more than one AL if you
> have more than 24 fields for which you are changing
> the display property of the fields. Maybe something
> similar like how the set fields actions work.
>
> Also how about an additional execute on for "Mouse
> Over" in addition to gain and lose focus in the
> execute on in AL's?
>
> Regards,
> Saby
>
> --- "Kern Robert (SBA)"
> wrote:
>
> > Hmmm... not sure if the following has already been
> > mentioned - basically the idea is, to get more out
> > of the Admin client, making it more compareable to
> a
> > "real" coding editors.
> >
> > You know, such little things as little as coloring
> > brackets for example. Being able to drag n' drop
> > actions from one AL to another, converting AL's to
> > filters, more debugging and real time monitoring
> of
> > variables - also like the log file telling you
> > "qualificaton of AL xxx failed" - yeah, nice. But
> > failed why ? What part ? ... and so on :-)
> >
> > Basically I think that the whole idea of having
> > those little own windows for single AL's and such
> > may perhaps be something that could get improved,
> or
> > taking another direction basically, like more
> > diplaying those flat like code snippets too, where
> > you can modify per text directly and copy n paste
> > even or such things.
> >
> > Well, not really annoyances those are. I think the
> > Admin Client is real good - but I think that there
> > is room for improvements too.
> >
> >
> > Cheers from Germany - tgif - Robert
> >
> >
> > -----Original Message-----
> > From: Action Request System discussion
> list(ARSList)
> > [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Rick
> Cook
> > Sent: Friday, August 13, 2004 3:25 AM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: OT:Remedy Annoyances
> >
> >
> > I remember Doug talking about the desire to have
> > global data elements a couple of years ago, but I
> > don't know what the status of that is. Just
> wanted
> > you to know that they ARE thinking about things
> like
> > that.
> >
> > Susan's wish seems more like a normalized DB
> > structure. For a number of reasons, I don't see
> > them going there.
> >
> > Rick
> >
> >
> >
> > From: Action Request System discussion
> list(ARSList)
> > on behalf of Susan Palmer
> > Sent: Thu 8/12/2004 4:43 PM
> > To: ARSLIST@ARSLIST.ORG
> > Subject: Re: OT:Remedy Annoyances
> >
> >
> >
> > What a great idea ...
> >
> > But why not also have the option to have a change
> in
> > value in that field on any form update all the
> other
> > records.
> >
> > Susan
> >
> >
> >
> >
> >
> > --- lars.j.pettersson@VATTENFALL.COM wrote:
> >
> > > I have one dream, create a unique dbid, like
> > > 536970412 and set a flag as 'master'
> > >
> > > Then u can use this dbid in 100 regular forms,
> and
> > > set a flag as 'relation to masterid'
> > >
> > > If u change the value for the masterid 536970412
> > > from A to B, all other forms with this id will
> be
> > > updated, without having to build wf for that
> > update,
> > > let ars take care of that ...
> > >
> > > I think a timecomsuming part building a large
> > > arssystem is to keep fields 'up to date' with
> push
> > > field action and so.
> > >
> > > I know ARS not is build like Access as a
> > relational
> > > databasesystem, advantages and disadvantages ...
> > >
> > > L ars
> > >
> > > -----Original Message-----
> > > From: Action Request System discussion
> > > list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On
> > > Behalf Of William Rentfrow
> > > Sent: Thursday, August 12, 2004 7:27 PM
> > > To: ARSLIST@ARSLIST.ORG
> > > Subject: Re: OT:Remedy Annoyances
> > >
> > > The one feature I'd like to see is the ability
> to
> > > create variables/keywords. It is simply silly
> how
> > > many forms have 20+ "zTmpxxxxxx" fields that are
> > > used only for data processing.
> > >
> > > It would be nice if you had the ability during
> > form
> > > creation to define admin-created keywords
> specific
> > > to that form (globally would be nice too but
> > that's
> > > a whole other ball of wax).
> > >
> > > So, instead of creating a field
> > > "zTmpHeresMyFieldForFlaggingStuff" I could
> define
> > a
> > > keyword $TEMPFIELD1$, along with a default
> value.
> > > This has two benefits. First, you don't have to
> > > place the field on the form and make sure it is
> or
> > > is not in 15 different views. Secondly, it
> takes
> > it
> > > out of the list selection.
> > >
> > > AND, it makes it more like "normal" programming.
> > >
> > > In a perfect dream world, these would allow
> > arrays,
> > > list variables, etc...but I'm not that
> optimisitic
> > > :)
> > >
> > >
> >
>

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

> > 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
> >
>
>
>
>
>
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> 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
>