Re: Incident Last Updated
So I built out all the functionality on our dev box using an escalation to start. I was expecting to see the Last Modified By to be AR_ESCALATOR and the Last Modified Date to be the date the work log entry was created. The update was immediate when adding a work log entry from the Incident Management Console, which was odd since I set the escalation to run in 5 min intervals. I opened the ticket and the Last Modified By was the user I used to submit the work log entry. I tried with a user account that only had read access to see if it would throw any errors. I then tried in production with none of the code transferred over and everything worked as intended. I know there was some challenges in the past with the ITSM Suite especially when SRM came around. There were a lot of kinks to work out with allowing any user to submit, submitter mode lock, and licensing. People developed many workarounds to essentially by pass the errors BMC/Remedy would pop up on the screen to force licensing. This and permissions was always a challenge when you start looking at row level access. Hence the addition of additional permission fields and parent groups. I don't think 7.6.04 had the updates to the Last Modified fields like described above. It's been a while so I may be off on the version. 8.x I didn't mess around with so I'm not sure if it might have been updated in that version or 9.x. I haven't dug into how the system is updating the field on the backend. However, it is not traditional workflow that is updating the fields. Brian From: ARSList on behalf of Jason Miller Sent: Wednesday, May 30, 2018 1:52:52 PM To: ARSList Subject: Re: Incident Last Updated Wonderful! Do you mind expanding a little on what you found? Jason On Wed, May 30, 2018 at 12:45 PM, Brian Pancia mailto:panc...@finityit.com>> wrote: I did some testing with this and who knew it's already built into the system. We're running 9.1.04. Not sure when this functionality was added in. Probably 20 versions ago. Just shows sometimes our minds get stuck on how the system worked many versions ago and we assume it's never been changed. Ok, maybe that is just my old mind. 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<mailto: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
Re: Incident Last Updated
Wonderful! Do you mind expanding a little on what you found? Jason On Wed, May 30, 2018 at 12:45 PM, Brian Pancia wrote: > I did some testing with this and who knew it's already built into the > system. We're running 9.1.04. Not sure when this functionality was added > in. Probably 20 versions ago. Just shows sometimes our minds get stuck > on how the system worked many versions ago and we assume it's never been > changed. Ok, maybe that is just my old mind. > > > 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 > > -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Re: Incident Last Updated
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 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 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 > 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
Re: Incident Last Updated
I did some testing with this and who knew it's already built into the system. We're running 9.1.04. Not sure when this functionality was added in. Probably 20 versions ago. Just shows sometimes our minds get stuck on how the system worked many versions ago and we assume it's never been changed. Ok, maybe that is just my old mind. 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
Re: Incident Last Updated
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 on behalf of Jason Miller 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 mailto: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 mailto:arslist-boun...@arslist.org>> on behalf of Jason Miller mailto: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 mailto: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
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 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 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 > 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 > > -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
Re: Incident Last Updated
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 on behalf of Jason Miller 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 mailto: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<mailto: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
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 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 > > -- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
