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. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
