The “tech doesn’t know what changed” argument I can actually work with. Makes some sense.
But the Submitter Mode Locked only applies to ARS….I don’t buy into that. That’s just playing word games at that point. VERY expensive word games….Either Submitter Mode Locked lets you modify your own records or it doesn’t. M2CW, tp From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Sent: Friday, November 30, 2012 4:57 PM To: arslist@ARSLIST.ORG Subject: Re: OFFLIST - Incident Submitter and License terms - Dear BMC have you mislead us? ** I'm actually all for not allowing submitters/end users to modify their incidents. Support techs don't re-read tickets. If somebody gets assigned an incident, reads it, then somebody modifies that ticket, how is the assignee supposed to know what was changed? At least forcing them to add work info updates adds a time stamp to their update. Something an assignee could see and know what information is new. And yes, somebody will point out auditing. But that means the tech has to know something was changed, open the audit log, look at the new entries, and then look at previous entries to determine what the previous value was. And if you create a notification to the assignee? Well, that's just one more thing for their auto-delete rule. Bottom line... The locked submitter mode is part of the Action Request System functionality. The ITSM apps are a different product and can't assume everything carries over. Exhibit B: 7.6.04 User Tool. Been one of those days. Jason _____ From: Timothy Powell <timothy.pow...@pbs-consulting.com> To: arslist@ARSLIST.ORG Sent: Friday, November 30, 2012 2:39 PM Subject: Re: OFFLIST - Incident Submitter and License terms - Dear BMC have you mislead us? ** And I will venture on to say that I understand that there are some application Role dynamics in play here. Not allowing a DIFFERENT user to make mods to a ticket that’s not theirs or where they are not a member of the assignee/owner group is completely understandable. But I am still confused on the business logic behind not allowing a user to update their own ticket beyond work info entries (which of course is really a separate submit). tp From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: Friday, November 30, 2012 12:07 PM To: arslist@ARSLIST.ORG Subject: Incident Submitter and License terms - Dear BMC have you mislead us? ** I did a search of this year’s listings before I asked this question, so I apologize if I missed a thread and am dragging up an old subject. I did see some similar discussions, but nothing specific to this. BMC/Remedy has always promoted the fact that if the server was set to Submitter Mode-Locked (SML) that any user could submit and modify their own records (where $USER$ = Submitter Field ID 2). In ITSM 7.6.04, that level of permission equates to Incident Submitter. So I have a user that is set up as Incident Submitter with a Read license attached to that role and a Read AR license. The user can submit tickets BUT cannot modify their own incident tickets (where $USER$ = Submitter Field ID 2). There is actually workflow in place to prevent this. In order for them to modify their own record, I have to bump that user up to Incident User level, which then requires a Fixed or Floating license. So my question is: Is that not in conflict with one of the major sales arguments BMC made to our organizations, that being our users could submit and modify their own records without a Fixed or Floating license? Tim Powell _attend WWRUG12 www.wwrug.com <http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"