Rocky, Hum... I am not sure where some of your response came from... I am guessing that you do understand the details, but just to make sure we (all on arslist) are all on the same page....
The ability to "set the submitter field on create" is not altered based on the "Submitter Mode" value(Changeable or Locked). The user and workflow are able to alter the value up and to the point that it is first saved to the DB. [So all the way through Submit filters, but not in "After Submit" Active Links.] After that point however if "Submitter Mode =Locked" then an AR Server will not let the user or the ARS workflow MODIFY the value. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 7/11/07, Rocky Rockwell <[EMAIL PROTECTED]> wrote:
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"
