I just want to point out again that we need a solution for working with multiple browser tabs,
i understand the technical challenge of the current stack
but the fact is that people work with slack/discord/rocket.chat or whatever and share links to tickets, this wont go away, and that is causing the biggest pain for us right now, cause clicking on those links in chat will open a new browsers tab/window to zammad
Is it maybe possible to to something like a ticket-focus-mode that is not the “main zamamd thread” and thus has less of the Single-Page-Apps functionality but allows you to view that ticket somehow? (i.e. no notifications etc)
I am just thinking for a workaround if its not possible to update the zammad core problem around this in the coming years. At least i am clueless how to otherwise solve that problem, but our teams are annoyed by that and they mostly assign / escalate tickets over the chat as this is the most forward approach for us and as they need to work with multiple browser/screens anyway cause they have an ERP side to side with zammad, they are used to “group” their tabs together so that the ticket corresponds to the other open windows
We are facing the same issue. I am honestly running out of arguments “why” it is not possiblle having multiple tabs open.
People without any technical knowledge care little about the reason why you cannot have multiple tabs open…
I do not know whether it would be a feasible approach but maybe some kind of “smart polling” could be an attempt?
Have one tab as “main” instance with the socket and the others are polling for updates and show a notification that the content has updated…
I have been studying Zammad for almost 1 month to implement it in my company and now I am facing the same problem. We use whatsapp as a chat in the area and we share tickets all day. Unfortunately not allowing multitab leaves me without much chance of getting Zammad approved for the migration from Osticket that we currently use.
A solution is requested for this, it is a priority since the team always sends the tickets.
A experimental change I’ve added to our instance of Zammad is a javascript snippet which ensures only one tab is of Zammad is ever open at a time. It solves directly opening links from other chat platforms.
It does so by sending out a window message with the current url to any other potential open Zammad tab and if any responds, it closes itself, while the already opened Zammad tab opens the received url. (Along with sending a notification if the window is not visible, so the window can be focused by clicking on it). I can make this a addon package and share it later on if there is interest.
It is not the best solution for sure, as it currently takes a bit for this whole process to happen while it probably still fetches lots of unnecessary data from Zammad simultaneously and it can’t automatically have the tab take focus, so I am thinking about writing a browser extension to archive this instead.
Just came to say, that this limitation is an obstacle I hit a lot when using the ticketing system. I like to see multiple tickets at once, compare them visually, check if they refer to the same thing or not.
I am very interested if you could share that code Stubenhocker!
Also currently I am only aware of adding (serverside) CSS. How do you add (serverside) Javascript? Or is it a clientside script? Could you share that approach too?
Working with multiple browser tabs per session is not supported.
Dirty workarounding may work but has serious drawbacks on Zammads performance and function.
Everyone doing this will not find me being sorry if something goes wrong.
You’re then walking outside of Zammads supported boundaries and thus will also receive 0 help.
BUT I cannot help to emphasize that this is not how users are using software (especially in a browser environment) today.
I am not keen to use this JavaScript ‘hack’ in anyway but I might have to as agents open links to tickets from multiple different environments and this causes some issues.
We do train our agents internally and mention this behaviour specifically but the results are always the same…
It is also frustrating that you cannot switch quickly between a knowledge base article and a ticket.
To provide a more detailed example:
Imagine you have an intern working on some tickets. To do so the intern has to navigate back and forth between the ticket and the corresponding knowledge base article in order to fulfill the requirements (as he / her is new to this particular workflow he / she is dependent on the kB article…). This is just not as “enjoyable” as it could be…
It is understandable that the technical limitations do require some sort of “single” tab environment. but in a “real” environment where you have to use multiple systems simultaneously this limitation causes issues and confuses users.
thanks for clarification. Seems a lot of new stuff is coming with UI2.0. Sounds great!
Is there a rough plan when UI2.0 will be available? Maybe later this year, or in 2023?
That’ because you probably never open a ticket by clicking the links in the notification mails. But that’s how others work in other places: Get a notification email that there has been an incoming post → click the link → work on said ticket. That’s how it should work, but it doesn’t, because - bummer - you get a session warning in the other tab, where you had worked on the other issues.
IMHO this is one of the major pains in Zammad and the (my current) workaround is to memorize the ticket number from the mail and manually open the ticket in the always-open Zammad (browser) tab.
IMHO the idea of @Stubenhocker sounds promising, as his “hack” - as far as I understand - redirects the (Zammad) tab to the already existing (browser) tab running Zammad, so that Zammad is always running only in one browser tab. I’d also be interested to try out/use this code. Can you share it @Stubenhocker?
You seem to work different.
We have to merge tickets very often for example.
Customer A of Organization opens a new ticket, where Customer B of the same Organization has an open ticket. So lacking the support of multiple tabs and a search function in ticket merging, I have to search the ticket, copy the Ticket# of the old ticket, remembering the Ticket# of the new ticket or use a lot of back/forward in the browser to get to the ticket i want to merge. Having tabs would be much easier here.
We are getting a lot Ticket Changes per mail. It’s easier to copy the ticket# from the mail and search for it in zammad, than clicking on the “open in zammad” link that causes a “you already have an open session”.
The other problem is, that every ticket I click on, even if I dont want to have it in my tickets list on the left side, gets to my tickets list. So working with a lot of tickets destroys that list very quickly and makes it unusable as an overview to us, and so its not an alternative for working in browser tabs.
Dont understand me wrong, I find Zammad great anyway. But different users will use it different way.
alternatively an electron app could work that could catch zammad links and pass them to your SPA instead of opening a tab
we are really searching for solutions @MrGeneration i know you are kinda in a one way road with your anti-multiple-browser-tab-antipattern, but for the time being it would be nice for a good solution that would allow for an easy way of opening a zammad-ticket-tab by an external link click, cause thats ultimately the problem
Look it’s very simple.
You want it, a feature request.
Use the first article to heart it as a vote. That’s the only way we measure - you can post and repeat yourselfes in one or several threads all day if you want, however, it won’t change the weight on a feature need.
While you only see me steering against it it’s simply because it’s not supported and currently out of scope.
It requires deep changes.
That’s the last time I’m commenting on such a topic, don’t worry.
I know. I just wanted to mention the way we work and why tabs would be very nice to us. But even without tabs, Zammad remains the best and easiest to handle ticket system I have seen until now.
