Maintain the context inside Freshdesk custom app when multiple tabs are opened in a browser

We are developing a custom app that triggers when an agent opens a ticket on freshdesk.

Now it’s possible that the agent is working on multiple tickets in different tabs of the browser.

We want the“ticket”) to return the data only of the ticket that is currently open or the tab that triggered that request via an event like button click.

Basically create sort of a context, so that the events and data do not interfere between multiple tabs of the browser.

This is how the main piece of app looks

$(document).ready(function () {
    function (client) {
      console.log("App started");
      window.client = client;"ticket.replyClick", ticketProperties);
    function (e) {
      handleErr(e, event);

Let’s say there is Tab 1, Tab 2, and Tab 3 have 3 different tickets.

What happens when app does"ticket") in tab 2? while others are open

Inside your ticketProperties method , in the starting you can try to check whether the current tab is open or not using Javascript or jquery .If the tab is not selected you can simply return from that method.
To check whether the current tab is selected or not you’ll have to check what is supported in various browsers. This link might help :- javascript - How to tell if browser/tab is active - Stack Overflow

1 Like

There is an issue (very rarely occurs) where one ticket affects the data of another probably because of the custom app.

In the documentation for app.initialized() App Lifecycle Events

The following is mentioned

Unless you are building an app that is completely isolated (independent of the data on the page), the core logic of the app should not be within the app.initialized() callback. It should be within the app.activated() callback to ensure that the app can react whenever the ticket or contact context changes. For example, on the Ticket Details page, when you navigate from one ticket to another, app.activated() is triggered and the corresponding callback is executed.

What does this mean? And could this be the issue of not having a separate context for each ticket?

Let me try to clarify this a bit:

App lifecycle events are broadly three events: initialized → activated → deactivated

The app developer can author the behavior to happen based on placeholders. For example, (in your hyperlinked documentation), an app rendering in the ticket sidebar will have its thread of execution invoke your authored code when the user expands the app voluntarily. However, suppose you choose to put the code under initialized execution context — the thread of execution invokes the authored code once when Freshdesk is first loaded/refreshed in its entirety.

This makes an extreme difference in some cases. For example, your app wants to show the agent the shipping information. You can author to make an API (to get+render shipping information) call under initialized or activated execution context. Users will collapse or open the app in the sidebar more frequently than refresh the entire window. As a developer, it makes sense to put desired logic within the activated phase.

  • Now, this is more like a thumb rule. The business solution you imagine has the app’s rendering content change based on what’s contextually within the module (for example, the ticket details page), using app.activated() allows your APIs (Platform like or Any) to invoke more often and thus dynamic.

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.