FSM Mobile - Updating Travel/Work times on (baseline) task status change

@drooij

You need to create new custom screen to do this requirement.use that screen to chage task status.

When changing the task status you can calculate extract time between two task status.

Hi @shalikakk Thanks, But I need something simpler. Only need the the status datetime. So when I set the task on status Travelling, I want the datetime of the moment I changed it.

I know I can create custom buttons, which change the status and set the datetime to the field. But I actually want to use the basline functionality

@drooij 

can’t use baseline task status change function for this. Because can’t add client script to to quick action bar buttons.

Hi @drooij ,

As @shalikakk  said, you cannot capture baseline task status changes for this requirement.

The best possible option is to remove the baseline task status change button and implement a new task status change mechanism. Then you can capture value changes on the mobile device using scripts.

If not, you will need to wait until the next sync cycle to receive the changes.

@Chethana, Thanks. That’s the solution we currently have. But we would like to implement the ‘Confirm message’, a functionality via the Status Flow. Unfortunately you can’t script a ‘Confirm message’ in mobile.

Hi @drooij , You can use the confirm message option through the current baseline task status flow. It is available for all task statuses.

@drooij,

you can capture the above baseline status by using a refresh script on the debrief overview screen (might work in other screens as well).

Haven’t tested this in the latest versions, but following is a structure of the script (might not be the correct syntaxes)

//Other refresh script functions goes here


//Please note that the syntaxes might be not correct, refer the help doc for exact syntaxes

//Create a unique cache key value for current task
var curTaskId = getControlValue('task','task_id');
var cacheKey = "CACHED_TASK_VAL_" + curTaskId;

var curTaskStatus = getControlValue('task', 'task_status');
var cachedTaskStatus = getFromCache(cacheKey);

//Add some null checks to here as well for exception handling
if (curTaskStatus != cachedTaskStatus) {
    //task status have been changed

    //Write your own logic here for the relevant action

    //Update the cached task status with the new status
    setCache(cacheKey, curTaskStatus);
}


//Also once your required task status if finished in the task status flow, suggest to clear out the 
//cache values so it won't affect the performance 

In your case, please do keep in mind to verify the business rules/logic as updating the same column in both mobile and server at the same time might lead to exceptions.

@Chethana 

“You can use the confirm message option through the current baseline task status flow. It is available for all task statuses.”

Yes, but the confirm message will only work if you use the baseline functionality for changing status in mobile. As far I know, you can’t use it if you change the status via a client script. Which is needed, because we want to fill in some date fields on status change.

@IniNimesK I’m a little confussed, the code technically works. But can you explain this part?

You create a cache value like “CACHED_TASK_VAL_1234”

//Create a unique cache key value for current task var curTaskId = getControlValue('task','task_id');

var cacheKey = "CACHED_TASK_VAL_" + curTaskId;

Then you get the status value from the task_status field

var curTaskStatus = getControlValue('task', 'task_status');

But then with the next line, the cache “CACHED_TASK_VAL_1234”  becomes a task_status somehow

var cachedTaskStatus = getFromCache(cacheKey)

@drooij,

Basically from the above code, what we do is, store the previous task_status for a specific task in the cache. So that it can be compared once the status changes.

• The logic behind creating a unique cache key is to preserve this previous task_status value (as the technician can move between tasks and if used a generic key for cache, it will overwrite the previous value for a specific task)
• Then once the refresh script runs, we get the current task status value and compare it with the cached value (this most of the time will be equal/same as the cached value as the technician hasn’t changed the status). But once the technician changes the status and the refresh event gets triggered, the if clause will become true.
• And within that if clause you can write you own logic along with the line of code setting the current task status as the cached value