Client.data.get('ticket') returns stale data

I’m currently developing a FreshService app that posts ticket data to an external API when a ticket is updated. Right now I’m in the testing phase and have noticed that the method to get ticket data seems to return stale data.

I have the following code in an app that runs in ticket_background:

document.addEventListener('DOMContentLoaded', appInitialized);

function appInitialized() {
    app.initialized().then(client => {
        window.client = client;
        client.events.on('app.activated', appActivated);
    });
}

function appActivated() {
    client.events.on('ticket.propertiesUpdated', propertiesUpdatedCallback);
}

var propertiesUpdatedCallback = function () {
    var ticket_data = client.data.get('ticket')

I’m running this code on my local machine and testing it by adding ?dev=true in my browser.

After some testing I’ve noticed that the data that I’m getting is the ticket data as was present when the page was first loaded. Any changes to any ticket property after the first load are not reflected in the return value of this call.

This is problematic as I have to decide what action to take after loading this data, and this decision should be made based on the latest updated data, not on old data.

I know I can access updated fields through the 'ticket.propertiesUpdated' event, but that is problematic as well, as the keys on that data do not match the keys on the ticket data. (a custom field in the event data is represented by just the field name, but in the ticket data is represented in a special custom_field object and appended with the freshservice customer id) If possible I would like to avoid the technical debt of having to match the event data to the ticket data.

So my question is if I there is a way I can get the updated ticket data in one go? Or is this an artifact of the way the testing works and will that call return up to date ticket data in production?

Hi, @Gneg! Welcome to the community!

You could get the data using API: View a Ticket
This way you would have the updated data.

3 Likes

Hello @Gneg,

Are you making updates to the ticket and then refreshing the page before executing the code again? I have noticed that if you don’t refresh the webpage the data you are getting is prior to the change. Just a thought.

@samuelpares suggestion is legit and perhaps a more solidified solution.

Hmm… I would like to avoid API calls if possible, as I’m probably going to need the API for other functionality and fear reaching the API limit in the future.

But I guess it’s the only solution, as I am not refreshing the page as Zach suggests, so the data I’m getting with the client.data.get('ticket') call is old data.

@Gneg,

I think the issue is how you are executing your application. For front end apps, the app is initialized but the callback is not ran until you activate the application (load app window, click button, etc.). So when you activate the app it is giving back the current data which only shows the current properties of the ticket because even though the ticket.propertiesUpdated event happens the application is not activated again. When you refresh the webpage (ticket now shows updates) and then activate the app, the data will reflect the correct ticket information.

@samuelpares would that be your understanding too?

Maybe a better solution would be to build a serverless application that looks to execute your code using the “onTicketUpdate” serverless event at the moment the ticket is updated which includes property updates. You can find the documentation here. Good luck! :slight_smile:
-Zach

2 Likes

I did look into the onTicketUpdate serverless event, but according to the documentation this event is not fired in case of an update to a custom field, which rules it out for me unfortunately.

@Zach, @samuelpares thanks for the quick responses btw, very much appreciated!

2 Likes

@Gneg,

Ahh yeah thats a bummer. I know that not having custom fields trigger serverless events is a hurdle for sure.

This post expresses that as well.

I added a comment to up vote the need to add custom field triggers as a feature request. Perhaps if we get enough devs to push for this, the product team will think about making a change to the platform.

3 Likes