Add Logic check from Work Items not stored in the Cireson database

Brian_Wiest

Looking to see if an logic option can be added that when a user attempts to access a work item ID that has been moved out of the live database and moved into production that rather then getting the error 

FAILED
The item you requested either does not exist or you do not have access to view it.

They get a different error

Sorry
The work item ID is not contained in the database. (If possible add setting in admin panel to include link to provide a URL for warehouse searching if org has one setup)

This would help with identifying issues with permissions/vs archived content. Get a number of tickets for warehouse content. 

If possible take it a step further the logic would recognize that the ID is greater then the top ten ID in the portal and provide a different error that would report they would need to contact the admin (For cases with the cache builder needs restarting)

Ron_Evans

Thanks Brian, restarting cache builder resolved the issue.

Ron_Evans

This issue first manifested when analysts could not open the incident from the link in the email notifications; and could not be found by a search via the portal as well. However this issue did appear to affect service requests.

Brian_Wiest

@Ron_Evans Check out this post which shows how to look at the cache builder log
https://community.cireson.com/discussion/comment/3992#Comment_3992

German_Minicucci

I think you could update the localization "WorkItemAccessDenied" to replace the error message with something else.
Or, go all the way to update the html file directly: \CiresonPortal\Scripts\ng\page\pageViewErrorNotFound.html (I'm sure it's not supported as any upgrade will remove your changes)

Sandy_Wood

Would love to be able to search the DW from the Analyst Portal.

Tom_Hendricks

Brian_Wiest said:

Looking to see if an logic option can be added that when a user attempts to access a work item ID that has been moved out of the live database and moved into production that rather then getting the error 

...

(If possible add setting in admin panel to include link to provide a URL for warehouse searching if org has one setup)

...

At four votes on an FR that is getting pushed to the dark, forgotten realms of the site with almost alarming quickness, I am not sure it is worth asking to have these merged but I do want to add a reference to a very similar FR I created that is more focused on answering the part of Brian's FR that I quoted above.  The votes should go with this one (Brian's), though--I do not want the votes to get split.

https://community.cireson.com/discussion/3856/configurable-response-to-old-bad-groomed-ticket-urls#latest

In this FR, I tried to explain one way to accomplish this linking, because that is the only aspect of this that is important to me and my particular user base.  My intention is not to hijack this FR, but to bolster it.  If this gets pulled into the backlog, consider this a footnote for one possible way of approaching the solution that also solves the problem for demanding, non-technical user bases who want it to "just work" (thanks for that, Apple).

I am not sure if this anecdote will be helpful or not, but my users get angry and start lobbying for us to replace our entire ticketing system when they see that error message.  Not theoretically--it has actually happened.  I then have to take time out of my day(s) to fight off the proverbial torch- and pitchfork-carrying mob for two reasons: 1.) indulging their request would require large sums of time and money to re-create what we have already created for very little gain and no progress during that whole project, and 2.) because it seems like it would be easier by several orders of magnitude just to solve this simple problem with some code.  They cannot fathom how software built in the last ten years could just throw a generic error for a link that worked [insert recent measure of time here].  To be honest, I empathize with them on a certain level, even as I fully understand why it is happening.

Most participants on this site understand the issue very well and are not phased by this, but that is because we understand the complex architecture of SCSM at least at a basic level.  That is, in all fairness, too much to ask of most users.  It is too complex to disseminate (why would they care?) and its complexity is too often made into an excuse for allowing a subpar user experience.  But we know better, right?

I am not arguing that Cireson should have magically made their portal open records that are no longer in the database (although that would be great! ) and shame on them for not bending time and reality to their will, etc.  What I am saying, however, is that "little" problems like this are actually big in the eyes of many users, and that an improved error message, while certainly better and perhaps sufficient in other organizations, is not going to convince these particular users I am speaking of to lay down the torches or pitchforks.  I know better than to think that Cireson could have provided a solution that "just works" out of the box for all customers, but I do believe that it should be possible for us as product owners to create an "it just works" solution using the product in a supported manner.  Brian mentioned two ways of doing this, and I have expanded on one of them.  I really hope this gets traction.

Let's make this better.

Adam_Dzyacky

Tom_Hendricks said:

Let's make this better.

Second.

Justin_Workman

Thanks for that thorough explanation @Tom_Hendricks.  I can certainly see where you're coming from.  I'd like to add that I think @Brian_Wiest's point about helping with troubleshooting permissions is spot-on.  Personally, I appreciate the candid feedback from both of you guys!