The old 5.x apps we still have in production (and earlier versions) used a "Submitter = Requester" push or set fields on Submit mechanism to ensure that the Requesters would always be able to update their own tickets, which normally are submitted on their behalf by agents or other IT staff. ITSM 7 does NOT work this way, except through the Requester Console service requests.
Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/helpdesk/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Rockwell Sent: Wednesday, July 11, 2007 12:40 PM To: arslist@ARSLIST.ORG Subject: Re: Submitter Mode - Locked ...Brute force? 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
