Searchable defects

[LaurenBrodt]

I am proposing a way to search identified and resolved defects.  Currently the only way is to search through release notes, and even that does not include anything identified later.  As a result, it is not easy to know if you are experiencing an issue that has already been identified as a defect.  I am proposing defects be including with knowledge base searches, with the following information:

Defect number

Component

Description

Status

Affected versions

Date identified

Date resolved

Resolution

[VargheseJacob]

When it comes to Engineering request, it would be nice to see other tickets apart from my own. (without showing sensitive customer information). So that we can also vote like Ideas...

[ScottHagemeyer]

Varghese Jacob,

Customer reported tickets are already "voted on" when your company is added to the internal Jira ticket, as the number of customers associated to the Jira are one of the factors that raise it's priority for fix.

[LaurenBrodt]

I am one of those people that will browse through link questions, just to see what others are posting. Sometimes I don’t realize I have an issue, until I see it’s an issue, if that makes sense. Things that I notice that are a little quirky, but not that big of a deal I may not submit, or attribute to server issues, browser issues, or simply not think much about. When I see other people talking about it though, I often take the time to check it out, and see how much it affects me or realize it’s part of a bigger problem. I do the same for ideas, and would likely do the same if between version already identified engineering issues were available. Sometimes people even post the JIRA they’ve been assigned, which makes it easier to ask support to add us to the ticket.

As has already been posted, it would save a lot of time troubleshooting, both on the admin and support side.

[MargoBrosnan]

Scott, if we can't see the full list of issues, we might not know a problem exists.  We wouldn't know to ask to be added to the ticket until we see the issue in production.  I'd prefer to be able to "vote up" the issue before it becomes a problem.

It would also be a great first stop if we discovered a potential issue.  Rather than asking the community if anyone has seen it, or working with support, we could search for the bug, find the Jira ticket number, and ask support to add us to that Jira.  It would save a lot of time for both customers and support.

[LaurenBrodt]

I just want to share a recent experience with everyone that supports the need for this.

Recently I submitted a case for what I felt was a bulk update and faceted search issue.  Support initially told me that it was working as intended, but I kept pushing.

In the meantime, I submitted an idea for something related and mentioned this "issue" as part of it.  Scott informed me that was identified by engineering during 6.7 testing and will be fixed in 6.7P1.

Because the JIRA was identified internally by engineering, support couldn't see it.  This is a prime example of how having access to identified defects could reduce troubleshooting on both admins and support.

(Thanks Scott Hagemeyer‌ for giving me the information on that JIRA and saving me more rounds of back and forth!)

[KatieBacon]

Lauren Brodt or Scott Hagemeyer, would you please share that JIRA number so that I can get us added?

[LaurenBrodt]

ARCHER-72588 (Bulk Delete) and ARCHER-76850 (Bulk Update) 

Mentioned in  

[KatieBacon]

Scott Hagemeyer‌

So is Rambo 3 the same as 6.7 Patch 1 coming out by the end of November?

[ScottHagemeyer]

Katie Bacon,

No, it is not. Patches don't have code names, only the major and minor releases do. Rambo3 is the Spring 2020 release.

Did this code name show up on your dashboard as well?

[KatieBacon]

No, I asked Support to add IMF to ARCHER-72588 (Bulk Delete) and ARCHER-76850 (Bulk Update).  They told me that they couldn't because they were closed and scheduled for Rambo 3.