Locked feature requests

[bahusafoo]

Can the feature requests not be locked when they are marked not planned? I submitted Mouseover User Information on ticket while logged in as customer

• It was marked unplanned and had the comment “it is not in the interest of a helpdesk to leak individual information about the agent”. It’s locked, without an opportunity to even respond or present a “why it’s valid” argument to that.

In YOUR specific use case, It may not be in the interest of YOUR specific helpdesk to “leak individual information about the agent”, however, in my use case and several others I know (especially in more self-service oriented implementations for ticket systems), customers are supposed to be able to see who is working on their tickets. Nothing would be exposed that is really “personal” information. When applying for a job on my support staff, it’s an expectation that the support staff will be able to be known/contacted, etc. - It’s been this way literally everywhere I have worked (several large healthcare systems).

Here is a valid scenario: I run an MSP that hosts a Zammad instance for my customers - they are all set up as different organizations, and their IT role agents have the ability to see MY company’s groups and “escalate” tickets to us they need help figuring out, or that end up being issues we manage for them. If I respond to a customer’s ticket, they may not be familiar with me (odds are they aren’t), it’s helpful for them to be able to hover over my avatar and see who I am - it prevents an additional call to their local IT staff and eliminates confusion.

Zammad should be built as a platform that is dynamic and adaptable to many different use cases, not pigeonholed into fitting only one specific scenario. Different companies have different goals and mentalities about them. The option to enable this or not, with the current behavior being the default is a perfectly reasonable request to make. It’s not good to just close/lock discussion on a use case because it doesn’t match what some others’ use cases are.

[Mirtaaa]

This must be a mistake on our side, as answers should still be possible. I will have a look into that.

On the other hand, I hope you understand that we have a massive amount of feature requests and even though we would love to, we have no chance of implementing them all. This forces us to strongly prioritise some requests and with that, also deny others.
Please do not create duplicate requests of those that were denied, as this won’t change our decision and just slows our work down more.

[bahusafoo]

It seems like this would have been a fairly “quick win” type of feature that would have made Zammad more flexible to different workflows - some global boolean “ShowAgentInfoToCustomers” could be added as a system preference, and the “if role != customer” check on the mouseover code would just change to “if (ShowAgentInfoToCustomers != true) -and (role != customer)” - the code for actually displaying it must already be present since agents already do see it.

My issue wasn’t with how busy you are as a group, I understand resources and time are limited - it was with how quickly a very useful idea was shot down out of unwillingness to account for different organizations’ needs than you are familiar with.

I can understand a public facing help desk (such as a large international web host) not exposing agent information to end customers, however, many support teams using ticket systems are internal to an organization, and withholding agent information is counter-productive in many of those cases. In an internal company ticket systems are often more self service oriemted, and if an end-user (customer) is not able to find information on who has their ticket they will simply submit duplicate tickets, etc.