Open for Voting
over 1 year ago

FEATURE REQUEST - return ability of all clients to see all request types

A recent 'point' upgrade of Web Help Desk (v12.6) has removed the ability of Client accounts that are also Tech accounts to see all request types.  This means our Techs in the Facilities group can not see the IT Requests and the Techs in the IT group can not see Facilities requests.  This is very annoying and is causing us a lot of grief, and unwanted anger from all the Tech's.  This was not mentioned in the release notes for 12.6 otherwise we would not have updated.

Case # - 00189333

  • support have told me "its a bug" but also told me they weill not be releasing a fix for it anytime soon, what a let down, a new version of Ipmonitor was release and I stupidly isntalled that and guess what, it has broken that product too.

    very disapointed in the quality control.


  • Thanks for your reply. emoticons_happy.png

    Yesterday afternoon, I heard back from our tech at Solarwinds who mentioned that this was being tracked as a bug, so there is potential that this gets addressed as a hotfix, or in a quick minor release.

    But I echo your comments on pace and quality of development.  I think Solarwinds has a hidden gem with WHD and that is only a few tweaks away from making it big.  Our institution is evaluating for an enterprise wide help desk system (to replace the 5 - 10 systems currently deployed) and I have presented on WHD twice.  I think it just needs a little more depth in a few key areas and we would be all set.

  • Thanks to each of you for the detailed replies, and for pointing out that this very poor behavior is actually pointed out in the Release Notes.  Admittedly I missed that when reading over the release notes before upgrading.  I'll certainly echo the sentiments that have been written by each of the two individuals who posted above.  We are heavily invested in WHD and use it in precisely the same fashions.  We're fully LDAP-integrated for logins (which we *will not* change) and in some instances a user needs to act as a technician who manages certain request types, but in other instances he/she needs to be able to act as a client who requests support for other request types.  I cannot see any instance wherein the newly-revised behavior is desirable, but rather see all the downside that has been identified above.

    I had an open case with Solarwinds Support on this issue (Case 00192435) which was summarily rolled into a bug report for the developers and closed.  So, I'm of the understanding that this is being addressed as a bug that needs to be fixed.

    On a related note - I've expressed my continued and ongoing disappointment with this product that I believe has continued to go significantly downhill in recent years.  The number of bugs that have been introduced, reported, admitted, and then summarily ignored in recent years are numerous.  We have so much time and effort invested in this product that, as frustrating as it is, it remains worthwhile for me to keep protesting and insisting that the quality of software development and listening to customer feedback needs to improve.  I've spoken to at least 2 product managers over the past few years, and have expressed significant discontent to every technician with whom I've spoken.  I would recommend that all other heavily-invested users do the same, so that hopefully we can get some significant change to come about.

  • What's interesting is that they listed this as a feature change in the release notes yet I can't find any reference where this was requested as a feature.  I'd like to know who thought this was a good idea and why an option wasn't included to disable this under the tech options.  This has now limited our ability to upgrade, leaving us at 12.5 for the time being.   Would be greatly appreciated to add an option to enable/disable this in the next release or as a hotfix immediately.  We use CAS as a SSO for accessing WHD and although we could go to separate accounts to handle this, it does make this very cumbersome for our users.  We are highly integrated into WHD and making users log off and log back on just to submit tickets is not going to fly in our office.

  • I reached out to support, and this is indeed working as designed.  There is a mention of it in the release notes, and luckily I caught it on the second time around before we completed the upgrade (which was to be next week), as it would have completely broken our installation.

    We rely heavily on this ability to toggle between techs and clients and I'm not interested in creating additional AD or CAS accounts for each of our techs so that they can submit tickets as clients.  For background for anyone else who is looking at this, here is our use case that I put into the support ticket:

    We are pretty heavy users of WHD and have a number of departments and teams using the system for various reasons. We have project tracking, change management, quality management, technical support, leave management, etc... Users are often techs in one of these areas, but need to interact with other teams. We currently create an internal tech account, and link their Active Directory account to it as the client. They can then log in with their Active Directory account, and submit tickets to any of the needed teams as a client, or switch to the tech interface, and process the tickets they have to do as a tech.

    The 12.6 change completely breaks that workflow, and users are no longer able to submit tickets to teams they are not techs for. What I would like is to add this as a toggle-able option, so that our institution can disable this behavior (as I assume there was a reason that you put it there in the first place), or rip it out completely, if no one actually wanted it.

    In addition to this, we use CAS for our authentication, and our attempts to figure out a workaround have thus far failed.  So short of using the API and writing our own custom interface for ticket submission and review, we are stuck on 12.5 until this is addressed.  Or will have to switch to another product that can suit our needs.