Hi!

Can someone explain please what is this command good for? The manual says
it "Copies a field on the current form to another field on the current
form." Fine, can't I copy a field on the current form to another field on
the current form with a Set Fields action since ARS exists? What am I
missing?

Mark


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

Tim,

>My guess is it might be useful that you get a return value (0 or 1) back
>the assignment function. So you could do some conditional branching in
>the next step.

That is fantastic, but I still don't see the value of having this. If I
get the return value or not, I will have to check either a variable for 0
or 1 or the actual field. So why bother?


Mark


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

My guess is it might be useful that you get a return value (0 or 1) back the
assignment function. So you could do some conditional branching in the next
step.

--Tim


--- Mark Milke wrote:

> Hi!
>
> Can someone explain please what is this command good for? The manual says
> it "Copies a field on the current form to another field on the current
> form." Fine, can't I copy a field on the current form to another field on
> the current form with a Set Fields action since ARS exists? What am I
> missing?
>
> Mark
>
>

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

Also, it's data driven. One can include logic to move values around rather
than hard-coding the source and target fields in a Set Field action.

-Chris

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]On Behalf Of Tim Widowfield
Sent: Friday, December 23, 2005 1:18 PM
To: arslist@ARSLIST.ORG
Subject: Re: [ARSLIST] Application-Copy-Field-Value


My guess is it might be useful that you get a return value (0 or 1) back the
assignment function. So you could do some conditional branching in the next
step.

--Tim


--- Mark Milke wrote:

> Hi!
>
> Can someone explain please what is this command good for? The manual says
> it "Copies a field on the current form to another field on the current
> form." Fine, can't I copy a field on the current form to another field on
> the current form with a Set Fields action since ARS exists? What am I
> missing?
>
> Mark
>
>


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


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

Chris,

>Also, it's data driven. One can include logic to move values around rather
>than hard-coding the source and target fields in a Set Field action.

This sound really interesting! Does it mean I can decide at runtime, from
where to where I move the data? How exactly do I that? The manual says
targetid and sourceid are being accepted as parameters. Can I provide
those ids as a value of a field?

Mark


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

I use this in one case to walk a table field of fields ids to audit
for transactional changes. I use this run process to copy the audited
value to a display only character field so one filter can be used to
push the audited value to the audit form.

Without this, I would have to write a filter for each field I wanted to audit.

The presence of this run process comnand allows me to use a form to
dynamically change the fields to audit on the form without having to
write any new workflow.

Axton

On 12/23/05, Mark Milke wrote:
> Chris,
>
> >Also, it's data driven. One can include logic to move values around rather
> >than hard-coding the source and target fields in a Set Field action.
>
> This sound really interesting! Does it mean I can decide at runtime, from
> where to where I move the data? How exactly do I that? The manual says
> targetid and sourceid are being accepted as parameters. Can I provide
> those ids as a value of a field?
>
> Mark
>
>
> 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)

Axton,

How exactly do you use this command? The command accepts targetid and
sourceid as parameters. So my guess is, you do this $PROCESS$ Application-
Copy-Field-Value $fieldholdingtheidofyourtargetfield$
$fieldholdingtheidofyoursourcefield$. Is that correct?

>I use this in one case to walk a table field of fields ids to audit
>for transactional changes.

How exactly do you do that? I guess you have a filter guide, that uses the
$ROWCHANGED$ keyword. Is that right? What does the table field show?
What's the data source of the table field?


> I use this run process to copy the audited
> value to a display only character field

Why don't you do that by a normal SetFields?


>so one filter can be used to push the audited value to the audit form.

>Without this, I would have to write a filter for each field I wanted to
>audit.
>The presence of this run process comnand allows me to use a form to
>dynamically change the fields to audit on the form without having to
>write any new workflow.

I believe you, you use it this way. My problem is, I still do not
understand how this function works. Can you explain it to me, please?

Mark


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

Mark,

You almost get it... :)
You are really close... :)
Let me try to get that light bulb to fully light for you.


On 12/23/05, Mark Milke wrote:
> Axton,
>
> How exactly do you use this command? The command accepts targetid and
> sourceid as parameters. So my guess is, you do this $PROCESS$ Application-
> Copy-Field-Value $fieldholdingtheidofyourtargetfield$
> $fieldholdingtheidofyoursourcefield$. Is that correct?


Yes.
So let us set up the form so we can talk about things properly:

Fields on the form and their fieldId values:
'Request ID' (1)
'Submitter' (2)
...
'Status' (7)
'Short Description'(8)
...
'fieldholdingtheidofyourtargetfield' (113456700)
'fieldholdingtheidofyoursourcefield'(113456701)
'zUnlimitedTempChar' (123456789)


The command will take field references to find the fieldId values that
it should operate on.

So if:
$fieldholdingtheidofyourtargetfield$ has a value of "123456789"
then that is the fieldId it will copy the data to.

Same for the source field reference too.


And if you have workflow that sets the values of
'fieldholdingtheidofyourtargetfield' and
'fieldholdingtheidofyoursourcefield' then the single action can
move any fields value to any other field based completely on a data
driven model.

In Axton's example there is a table that lists the
'fieldholdingtheidofyoursourcefield' values and the
'fieldholdingtheidofyourtargetfield' value is a constant.

So in one call it is something like:

// copy the 'Status' value to the "tmp common field" (123456789) which
will later be pushed to the 'changed value for this field' field on
the audit form.
$PROCESS$ Application-Copy-Field-Value 123456789 7

So field 123456789 is set with a value like "New"

or...

// copy the 'Short Description' value to the "tmp common field"
(123456789) which will later be pushed to the 'changed value for this
field' field.
$PROCESS$ Application-Copy-Field-Value 123456789 8

So field 123456789 is set with a value like "This is my description..."


Then a push action can be used to push the value from 'targetfield'
to the audit form.
(The records likely look like:
'Field name that changed',
'changed value for this field',
'$USER$',
'TIMESTAMP'
)

The push action maps the local 123456789 field to the audit form's
'changed value for this field' field and other fields to build a new
record. (A new record is likely submitted to the audit form for every
field change. But you could update a record if you made the push
action work that way too.... that is up to you.)


So if you add a new fieldId to the config form then you start seeing
any data change to that field in the audit table data too. (no
workflow changes needed)


The basics things are this...
A push (or SetField) action has a "hard coded" field map in the
definition which is specified at design time. So if you use a temp
field and use a run time dynamic action to move a value to the temp
field (that are hard coded in the push/SetField) action then you have
a way to move one field's value around at run time. And all you have
to do is add/alter a record to a "config form" to alter what happens
at run time. No ARS objects need to be harmed, er... changed, to "add
one more" field to the mix.



> >I use this in one case to walk a table field of fields ids to audit
> >for transactional changes.
>
> How exactly do you do that? I guess you have a filter guide, that uses the
> $ROWCHANGED$ keyword. Is that right? What does the table field show?
> What's the data source of the table field?

The table field looks at the config form that defines the fieldId's
that should be audited. (The fields that should be logged to the audit
form when the values in the fields are changed by the user.)

No need to use $ROWCHANGED$ here. Every fieldId listed in the config
data (table field results) is evaluated. And if you get fancy enough
with it... you can also pull back the DB value for the field or use an
EXTERNAL() operator in the RunIf of the filter to only log the changed
fields too. :)

You have the fieldId that was copied to the temp field. So if you also
dynamically stack a temp field used in a EXTERNAL() operator on the
Filter that does the push action with a value like:

Pattern:
'' != 'DB.'

Example for fieldId = 7
'7' != 'DB.7'

Then the Filter RunIf could even decide to skip this field because it
was not changed in the current transaction too!

Now you could also have a flag in the config form that is set, per
field, that indicates to only log changes or to log the value for any
transaction too. (If there is some gestapo'ish reason to log the value
when it does not change, but the record is updated in some other way.)
Then you would simply build the EXTERNAL() value to be some simple
thing like 1=1 or $NULL$. (I am 99% sure a null value is evaluated to
be true by the EXTERNAL() function, but you might just want to use 1=1
anyway to be clear about what you want it to do.)


> > I use this run process to copy the audited
> > value to a display only character field
>
> Why don't you do that by a normal SetFields?

Because you would need a (hard coded) SetField map set up for each
field individually. If your form has 1000 fields, then that is 1000
Filters. And the maintenance of every time you add a new field you
have to add (yet another) filter to deal with the new field.

However with a data driven model it is 1000 data records, 1 Filter to
copy the value to the temp field, 1 Filter to push the value to the
audit form (or it could be the same filter too), and a Filter Guide(or
other filters) to loop over the data set until all have been
processed. And with a more advanced use of the EXTERNAL() operator
then you could also add conditions that would add/remove fields from
the audit process based on other conditions in the record too. (Like
if it is a 'Type' = "A" record then audit the field, but if it is not
a 'Type' = "A" record then the field would not be audited.)


BTW: The push action needs to be done in a "non-phased" filter (`!) as
well. So that the "right now" run time value is used in the push
action and not the value left in the field at the end of the Phase 1
Filter execution process. If I just lost you again.... give the PDF
files a good search for "filter phase" and let us know what you do not
yet know about that topic too.


> >so one filter can be used to push the audited value to the audit form.
>
> >Without this, I would have to write a filter for each field I wanted to
> >audit.
> >The presence of this run process comnand allows me to use a form to
> >dynamically change the fields to audit on the form without having to
> >write any new workflow.
>
> I believe you, you use it this way. My problem is, I still do not
> understand how this function works. Can you explain it to me, please?
>
> Mark

HTH

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.


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

Carey,

>You almost get it... :)
>You are really close... :)
>Let me try to get that light bulb to fully light for you.

You sound like Thomas Edison ;-)


>So let us set up the form so we can talk about things properly:
>
>Fields on the form and their fieldId values:
>'Request ID' (1)
>'Submitter' (2)
>...
>'Status' (7)
>'Short Description'(8)
>...
>'fieldholdingtheidofyourtargetfield' (113456700)
>'fieldholdingtheidofyoursourcefield'(113456701)
>'zUnlimitedTempChar' (123456789)
>
>
>The command will take field references to find the fieldId values that
>it should operate on.
>
>So if:
>$fieldholdingtheidofyourtargetfield$ has a value of "123456789"
>then that is the fieldId it will copy the data to.
>Same for the source field reference too.
>And if you have workflow that sets the values of
>'fieldholdingtheidofyourtargetfield' and
>'fieldholdingtheidofyoursourcefield' then the single action can
>move any fields value to any other field based completely on a data
>driven model.

That's clear, fine!




>In Axton's example there is a table that lists the
>'fieldholdingtheidofyoursourcefield' values and the
>'fieldholdingtheidofyourtargetfield' value is a constant.
>
>So in one call it is something like:
>
>// copy the 'Status' value to the "tmp common field" (123456789) which
>will later be pushed to the 'changed value for this field' field on
>the audit form.
>$PROCESS$ Application-Copy-Field-Value 123456789 7
>
>So field 123456789 is set with a value like "New"

Why would one want to store the 'changed value for one field' into an
audit trail? I see the changed value in my form, don't I? When I make an
audit trail, I always log:

Date, User, Field Name, Field's old value, Field's new value

I've implemented what Axton said and you so beautifully explained and I
have two issues:

1. The assignment

$PROCESS$ Application-Copy-Field-
Value 'fieldholdingtheidofmytargetfield' 'fieldholdingtheidofmy
sourcefield' gives me the changed value for one field, but I want to get
the value of the field *before* the changed has occured, because that's
what makes an audit trail interesting. Is this possible? What am I missing?

2. The above mentioned assignment returns 0, which, according to the
manual, means, the assignment failed. I still see the assignment occuring
in the log:

FieldAudit:Guide:FieldLoop:1CopyValue (1)
--> Passed -- perform actions
0: Set Fields
zzAuditHolderField (801510053) = test 3
Application-Copy-Field-Value
801510053 8
Exit code: 0 Value: 0
TmpResult (801510054) = 0

Apart from the failing (?) assignment, the test 3 is the new value. How do
I get the value, before the change?


>Then a push action can be used to push the value from 'targetfield'
>to the audit form.
>(The records likely look like:
>'Field name that changed',
>'changed value for this field',
>'$USER$',
>'TIMESTAMP'
>)

Sorry, I don't understand why do you store the 'changed value for this
field' in the audit form, but don't store the 'value of the field before
the changed occured'.


>The push action maps the local 123456789 field to the audit form's
>'changed value for this field' field and other fields to build a new
>record. (A new record is likely submitted to the audit form for every
>field change. But you could update a record if you made the push
>action work that way too.... that is up to you.)

OK, how does this push look like? It's just a list of mappings or do you
use any command within this push action?


>The basics things are this...
>A push (or SetField) action has a "hard coded" field map in the
>definition which is specified at design time. So if you use a temp
>field and use a run time dynamic action to move a value to the temp
>field (that are hard coded in the push/SetField) action then you have
>a way to move one field's value around at run time. And all you have
>to do is add/alter a record to a "config form" to alter what happens
>at run time. No ARS objects need to be harmed, er... changed, to "add
>one more" field to the mix.

Perfect! I understand what you're talking about. I'm only missing the bit
of getting the value before the change.


>> >I use this in one case to walk a table field of fields ids to audit
>> >for transactional changes.
>>
>> How exactly do you do that? I guess you have a filter guide, that uses
the
>> $ROWCHANGED$ keyword. Is that right? What does the table field show?
>> What's the data source of the table field?
>
>The table field looks at the config form that defines the fieldId's
>that should be audited. (The fields that should be logged to the audit
>form when the values in the fields are changed by the user.)

OK.


>No need to use $ROWCHANGED$ here. Every fieldId listed in the config
>data (table field results) is evaluated. And if you get fancy enough
>with it... you can also pull back the DB value for the field or use an
>EXTERNAL() operator in the RunIf of the filter to only log the changed
>fields too. :)

OK.


>You have the fieldId that was copied to the temp field. So if you also
>dynamically stack a temp field used in a EXTERNAL() operator on the
>Filter that does the push action with a value like:
>
>Pattern:
>'' != 'DB.'
>
>Example for fieldId = 7
>'7' != 'DB.7'
>
>Then the Filter RunIf could even decide to skip this field because it
>was not changed in the current transaction too!

That's the way I've implemented it.


>Now you could also have a flag in the config form that is set, per
>field, that indicates to only log changes or to log the value for any
>transaction too. (If there is some gestapo'ish reason to log the value
>when it does not change, but the record is updated in some other way.)
>Then you would simply build the EXTERNAL() value to be some simple
>thing like 1=1 or $NULL$. (I am 99% sure a null value is evaluated to
>be true by the EXTERNAL() function, but you might just want to use 1=1
>anyway to be clear about what you want it to do.)

Fine.


>> > I use this run process to copy the audited
>> > value to a display only character field
>>
>> Why don't you do that by a normal SetFields?
>
>Because you would need a (hard coded) SetField map set up for each
>field individually. If your form has 1000 fields, then that is 1000
>Filters. And the maintenance of every time you add a new field you
>have to add (yet another) filter to deal with the new field.
>
>However with a data driven model it is 1000 data records, 1 Filter to
>copy the value to the temp field, 1 Filter to push the value to the
>audit form (or it could be the same filter too), and a Filter Guide(or
>other filters) to loop over the data set until all have been
>processed. And with a more advanced use of the EXTERNAL() operator
>then you could also add conditions that would add/remove fields from
>the audit process based on other conditions in the record too. (Like
>if it is a 'Type' = "A" record then audit the field, but if it is not
>a 'Type' = "A" record then the field would not be audited.)

I got the point, I only do not understand how do you get the value of the
field before the change.


>BTW: The push action needs to be done in a "non-phased" filter (`!) as
>well. So that the "right now" run time value is used in the push
>action and not the value left in the field at the end of the Phase 1
>Filter execution process. If I just lost you again.... give the PDF
>files a good search for "filter phase" and let us know what you do not
>yet know about that topic too.

No, that's ok.


Mark


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

Mark,

Ok... let us work on that last point...


On 12/24/05, Mark Milke wrote:
> Carey,



> >Then a push action can be used to push the value from 'targetfield'
> >to the audit form.
> >(The records likely look like:
> >'Field name that changed',
> >'changed value for this field',
> >'$USER$',
> >'TIMESTAMP'
> >)

Opps... you also likely want a 'record Request ID' value in there too.
And if this is a shared form that you audit log multiple forms to you
also want a $SCHEMA$ value as well. :)


> Sorry, I don't understand why do you store the 'changed value for this
> field' in the audit form, but don't store the 'value of the field before
> the changed occured'.


You sure could store that value in every transaction in the audit log
as well. However, the last audit log entry for that field should have
the value already. (Unless it is during a submit, and then there would
be no audit record for the record and field yet.) So you can choose to
"double log" the value if that offers some reporting advantage, but
you really are storing the value twice in the audit log.

If you want to get the "DB" value for the field then you have to get a
bit more tricky.... You can either get the value from the audit log
records, or you can employ a SetField action with Direct SQL to get
the value. This approach would again require you to stack up a dynamic
string to do the "Right thing" for the Right field.

So you would get the schemaId for the current $SCHEMA$. (need a temp
field for that)
Then use the fieldId (from the audit form configuration) and set up a
string like...

SELECT C from T

So if the schemaId=253 and the fieldId =7 you would build the following string:

SELECT C7 from T253

The Set field action should always return the value to a "old value"
temp field so that the push action can add it to the audit record.


On the other hand... If you get the value from the audit trail form...
then a normal Set Field action can be used with little effort. :)
First you need to get the sort order to be what you want it to be.
(LIFO) So create a self join of the audit form to itself and set the
sort order on the form to be descending on 'Create Date' with a join
condition of 'Request ID' = $Request ID$.

Then a normal set field action from this join could use a set field-if
condition something like...

'Schema field' = $SCHEMA$ AND 'Record ID' = $Request ID$ AND 'Field
name that changed' = $tmpFieldId$

Use the first matching record, or set to null if no record found. The
sort order on the join should give you the last entry that was added
to the log form for the SCHEMA, 'Request ID, and 'FieldId' that is
being processed inside the loop.

Return the value to the "old value" temp field... do the push... etc....

But I hope that you already see why most implementations do not drag
this value around in every transaction audit log record. ( The double
storage does add up.)


> >The push action maps the local 123456789 field to the audit form's
> >'changed value for this field' field and other fields to build a new
> >record. (A new record is likely submitted to the audit form for every
> >field change. But you could update a record if you made the push
> >action work that way too.... that is up to you.)
>
> OK, how does this push look like? It's just a list of mappings or do you
> use any command within this push action?
>

> Mark

No special command in the push action. Just a static map of remote
field(s) to local field(s).

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.


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

To comment on:

"Sorry, I don't understand why do you store the 'changed value for this
field' in the audit form, but don't store the 'value of the field before
the changed occured'."

If you create an audit entry on submit for all the fields that are
audited on a form, then capture the transactional changes to these
fields on an individual basis, you have a cronology of the
transactional changes per field since the beginning, showing the
time/user making the change. The data in this format is pretty easy
to render in a table field for users to view the audit data on a per
field basis. I think this is a pretty good design because users
usually want to know when one field changed (assigned to, status,
etc.) and not all of the audit data lumped together.

A few more details/areas for expansion:
- There is some tuning that is pretty necessary when designing
something like this. I wont go into gory detail, but if you have
questions, do ask. An issue you may run into is if you audit values
on submit, and you attempt to create 10 tasks on a change request at
the same time. Don't fret though, if written properly this does not
present an issue.
- Update the old audit records with an end date/time
- Calculate time diffs (business / real) between the start/end times
(good for reporting)
- Use the status field to mark the record either current or historic
(makes reporting and indexing easier). This can be used to allow
users to view all the last changes for audited fields for a given
request, instead of on a per field basis.
- Don't use the form/entryid to relate audit records, use a guid
instead (This indexes much better than the form/eid, and the guid (FID
179) is available to filters on submit without any special handling)
- If the audit form is lean, storage shouldnt present an issue.
Figure that you can get each row into 250 bytes. 10m rows (which is a
very large number) only equates to 2.5gb (plus the history table
data)). (avg of 100 audit records per 100,000 entries)

On the subject of getting the value of the field before it changed, I
encourage you to just store the audit data in submit so that you
already have the value before it changed. Performing a lookup on each
field that changed after the fact will cause you to incur a
select/GLEWF against your ticketing form for each field, which can be
expensive.

Axton


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

This is good stuff! Thank you and Carey for sharing this.

I just put together an auditing system after reading your posts. The
only tip I might add (you probably already have this on your forms) is
on the Audit Config form that you use to enter the schemas and fields,
create a SQL menu for the names of the forms (from the ARSchema table)
and a menu for the names of the fields (from the Field table). This
makes entering a new field to audit very quick.

Stephen

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Axton
Sent: Friday, December 23, 2005 3:44 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Copy-Field-Value

I use this in one case to walk a table field of fields ids to audit for
transactional changes. I use this run process to copy the audited value
to a display only character field so one filter can be used to push the
audited value to the audit form.

Without this, I would have to write a filter for each field I wanted to
audit.

The presence of this run process comnand allows me to use a form to
dynamically change the fields to audit on the form without having to
write any new workflow.

Axton

On 12/23/05, Mark Milke wrote:
> Chris,
>
> >Also, it's data driven. One can include logic to move values around
> >rather than hard-coding the source and target fields in a Set Field
action.
>
> This sound really interesting! Does it mean I can decide at runtime,
> from where to where I move the data? How exactly do I that? The manual

> says targetid and sourceid are being accepted as parameters. Can I
> provide those ids as a value of a field?
>
> Mark
>
>
> 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)


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

Stephen,

Actually I would suggest using the Data Dictionary (DD) menus in v6.x
(6.3?) instead of SQL menus. They are more portable and also allow you
to honor users permissions to visibility to forms too. :) I have not
tested the field DD menus to verify that they honor field level access
for the users, but I would think that those ARS objects should honor
the ARS permission model. (Direct SQL menus would have no such
feature.)

Generally the config form is reserved for "Admin" or some kind of
elevated "Manager" level access too. So the permission differences may
not make as much of a difference in some installations too. However,
the DD menus have some nice and subtle features worth mentioning.

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.




On 12/27/05, Heider, Stephen wrote:
> This is good stuff! Thank you and Carey for sharing this.
>
> I just put together an auditing system after reading your posts. The
> only tip I might add (you probably already have this on your forms) is
> on the Audit Config form that you use to enter the schemas and fields,
> create a SQL menu for the names of the forms (from the ARSchema table)
> and a menu for the names of the fields (from the Field table). This
> makes entering a new field to audit very quick.
>
> Stephen


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