Ah, I see where you are going. Would non-licensed people other than the requester add work log entries? The requester should be able to update their own request (unless less the "you do not have write permissions" workflow in ITSM prevents this). I personally I view adding/modifying a work log entry and not updating the last modified timestamp/user on the main record as a flaw. The context of the main request was updated and the date/user stamps should reflect this (and is why in my custom app I made sure it did).
One thing regarding porting SQL code between environments.. I brought this up on the list years ago when I was researching any potential performance issues... What I have done in the past is create a second utility DB next to ARSystem on the same DB server. Here is where all of our custom views, stored procs, jobs, etc. lived. This left ARsystem purely manged by Remedy and anything we created directly in SQL went in to the utility DB. All of these custom SQL objects were coded to use the appropriate resources (linked servers, etc) for that environment (ex: our QA utility DB references other QA systems we were integrated with). By doing this, assuming our custom SQL objects were using the automatically-generated view names or our DBs were so in sync the schemeIds matched, we just refreshed the lower level environment DBs with a copy of prod and only had to do our normal ARSystem/ITSM environment updates (using the Remedy Restore Tool when were on ITSM). All of our customs SQL just worked after a DB refresh. Jason On Tue, May 29, 2018 at 4:51 PM, Brian Pancia <panc...@finityit.com> wrote: > Jason, > > > Great stuff. > > > The license issues come in because you can have customers submit work log > updates without a write license. I believe SRM is setup that way or at > least us to be if I'm not mistaken, so this would make a filter update a > problem. If I went the escalation route I would setup a qualification to > say only update the last modified date if the work log submit date is newer > than the incident last modified date. For now we don't have customers > adding work log entries, but we may down the road. Not sure if we would at > that time say date last updated by support versus date last updated by > customer. > > > The challenge with the SQL route is going across various environments when > porting code over (dev, test, prod). The SQL code may or may not have to > be redone. We have multiple environments and multiple networks utilizing > remedy. I do like direct SQL because a lot of times it is much faster > depending on what you are doing. > > > I'm going to play around with a few of these in our dev environment and > figure out which one works the best. > > > Brian > > > ------------------------------ > *From:* ARSList <arslist-boun...@arslist.org> on behalf of Jason Miller < > jason.mil...@gmail.com> > *Sent:* Tuesday, May 29, 2018 3:39:08 PM > > *To:* ARSList > *Subject:* Re: Incident Last Updated > > What kind of licensing issues are you thinking of? I probably would not > create workflow around forcing an updated. That is a procedural issue, not > a system issue (a common desire is to manage people via tech). > > I haven't researched if this would have a negative affect in ITSM, but at > my last job we built our own incident management and change management apps > and I made sure to include a filter that would update the main ticket any > time an associated work log records was created/updated so there wasn't a > situation where the last modified date was older on the main ticket than a > work log entry. These apps had the same basic structure as ITSM where > there was a main record and related work log records (although audit and > work log were all recorded in the same form so you could see the full life > cycle of the ticket by looking at one table field / report). You want to > consider this route if want simply look at the last modified date on the > main record (assuming it wouldn't be updated by an escalation giving a > false update). > > Another thought is to have a SQL job that updates your custom field for > capturing last user modified date. It would be pretty quick performance > wise and wouldn't touch the core last modified by and last modified date > fields. By doing this then you can add the custom field to consoles like > you mention and allow for sorting by this value. Or you could use a > combination of this custom field that captures only user update times with > workflow on the work log record as mentioned in the last paragraph, many > options here. > > On Tue, May 29, 2018 at 1:57 PM, Brian Pancia <panc...@finityit.com> > wrote: > > Jason - Thanks I was looking at that as a potential option too. Of course > the challenge with the work logs is licensing related issues. I definitely > want to make sure I don't kill all the functionality designed around the > work logs with workflow forcing updates. One thing I was looking at for > the escalation route is so the users can see quickly the last time the > ticket was updated, which can be used in the out of box consoles easily. I > may be able to use a display only field for that and do a join for backend > reporting though. > > > Brian > > > ------------------------------ > *From:* ARSList <arslist-boun...@arslist.org> on behalf of Jason Miller < > jason.mil...@gmail.com> > *Sent:* Tuesday, May 29, 2018 1:55:52 PM > *To:* ARSList > *Subject:* Re: Incident Last Updated > > I have seen these type of reports written against a join of HPD:WorkLog > and HPD:HelpDesk. This way you do not need to modify any data (and in-turn > you don't update the last modified date) like you would with an escalation. > > Jason > > On Tue, May 29, 2018 at 11:52 AM, Brian Pancia <panc...@finityit.com> > wrote: > > I'm looking at including the last date a ticket was updated either > directly or through a work log entry. My initial thought is to create an > escalation that checks to see if the work log entry submit date is greater > than the ticket last modified date and then update the ticket with that > date and user in the last modified fields. The goal is to be able to > easily report on how many days since the ticket was updated. I'm sure this > has come up 1000 times. Has anyone come up with other cool alternative > methods? > > > Thanks, > > > Brian > > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
