Hey All,
I am know this has been brought before and will be brought up again, but here is my two cents on the requests list page.
All I wanted to do was add the group a ticket was with, who it was assigned to, and make the drop down menus multiselectable. I was disappointed to learn that none of that was available as an available customization and that what was possible needed the duplication of data to custom fields paired with extra API calls, Javascript and a lot of head scratching.
This is just another disappointing roadblock in the customizability of what could be such a great feature to help keep the lines of communication open. It is a touch baffling that you would have such a useful tool in a system that is generally pretty customizable, yet the portal (which in my opinion should be the most customizable) is devoid of any real/tangible customization. Not being able to do simple things like making the menus multi selectable, changing status names, or adding the group and assignee to the requests list table without having to make a hacky workaround is simply frustrating. In my particular case, letting the end user see what group and assignee their ticket is with is very important to the direction we are headed as a company in regards to communication with our users. Things like using a templating language to make the code cleaner was a great idea, basing it off of a language that is super customizable like handlebars and then stripping away all the customizability is not cool. I understand the statement of "We can't let users run their customized code on our servers", this is a legitimate concern. My argument is that it doesn't have to be one way or the other, you can't tell me that there is not a great compromise in the middle of that void that we can all live with. Now, I know I have just a high level understanding of all the problems associated with this issue, along with the fact that I am one of the users wanting more options for customization. Not to forget the thousands of hours of meetings discussing the best roadmaps for software and not truly knowing what users are going need or think the need, or how they want to use the product (which may or may not line up with your vision for your own product). I guess I just feel like the compromise would be easier then not having the customizable options. My apologies for the rant, I will step down from my soapbox now 😉.
Thanks,
Jason Fouchier