We could not work if we could not set the submitter field on create. We
have people submitting tickets for other people. When this happens we
set the submitter field to the customer id. So they can modify certain
fields we have set to submitter -modify. If we could not do this we
would have to thousands of license for our people world-wide. and some
of those people only have 1 or 2 tickets per year. If we had to have
thousands of license I know we would dump ready in a heartbeat as we
could not afford it.
*Rocky*
Rocky Rockwell
eMA Team – Remedy Developer
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Ph#1: 214-567-8874
Ph#2: 325-884-1263
Carey Matthew Black wrote:
Leigh,
I totally agree with your concerns about changing the "Submitter mode"
value on an ARS server.. They are well founded.
If you have an application that is designed for "Submitter mode" =
"Locked" then it should also work fine on a server with "Submitter
mode" = "Changeable" too. However the reverse is not true. ( If the
application is designed for "Changeable" it _may_ not work in a
"Locked" environment. )
Personally I think the behavior of a Push action should be more
intelligent to the environment setting of "Submitter mode" during its
"Modify" behavior. If "Submitter mode" = "Locked" then field 2 values
should never be "Pushed" to the target record for a Modify. (Yes it
can be sent during a "Submit".) It just seems like a simple change to
make that would prevent a lot of pain for all application developers.
Maybe it becomes a footnote in some of the docs, but the reason the
workflow would work "that way" is to honor the user defined
configuration of the AR Server.
I have often wondered how much effort was put into the OOB apps due
to the above "gotchas" with ARS workflow and the "Submitter mode"
setting.
I also think some changes should be made in the "by matching field ID"
stuff too. But this is a slightly different topic for Push actions and
does not depend on "Submitter mode".
Like prevent modify of core field IDs ( field ID 1-99) by default.
There might be a need/want to also allow a way to define exceptions to
core field IDs to force them to be "modified" too. I can see some
arguments for the fields 4,7, 8, and maybe for other fields like 16-99
[If I knew what those fields are. :) ]. But you could just as easily
define a local, non-core field that you could use to communicate those
few "core field values" too. So the workaround for not having an
exception list would be easy enough to do and keep the change in the
basic action much smaller. So the exception list would be overkill in
my book.
Back to your original questions:
"
1. Is there any way, other than ones that require "brute force", to
determine if the original system has workflow that modifies the
submitter field? I have set the development box to Submitter Mode
locked and tried some very limited record modification, but I don't
have any testing resources available.
"
Testing is the most accurate way to know the actual answer.
In theory you might find a bug that "includes" field 2 in a push
action even though it is not defined in the workflow. (Like the ARS
Server incorrectly parse the Push action and splits a 2 off the end of
a different field ID that was actully in the Push action. ) But that
kind of bug has not been seen by me, and I hope it never is. :)
However, looking through the workflow is your best "predictive"
approach to the problem. Several good tools have been listed. However
I think ARSDocs was left out of the list. So let me push that one out
there too...
https://sourceforge.net/projects/arsdoc
"
2. Are there any "gotchas" I should know about that might cause us
problems if/when I change the production system?
"
Yep.
First you have to stop and start the AR Server to make the newly
changed Mode effective. So you need a change window to have an outage
to change the setting. And if you find problems in production then you
have to make the choice between having an outage or living with the
problem until you can have an outage.
If you find workflow (Push or Set actions) that try to alter the field
then the users will be BLOCKED from using the application (as they
expect it to work) after you go from "Changed" to "Locked".
"
3. Is it safe to assume that our Remedy/BMC applications will NOT have
workflow that writes to the Submitter form?
"
Uh... IMHO, that is not a save assumption to make. There were many
versions of the OOB's that were not fully "Submitter Mode" = "Locked"
compliant. Those need checking/testing too.
HTH.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
