[FEATURE REQUEST] Programatically update IDLE_TIMEOUT value from my app

[alexdiliberto]

I have a domain specific issue that doesn't seem to fit into the current allowable configurations for this addon.

My use case would be to have a way to programatically change the IDLE_TIMEOUT value from my consuming application based on some application state flag. I have a part of my app where the timeout is one value, then another part of my app where the timeout is a different value...I was hoping to use the same service for both and be able to change the timeout value

Simple example: Lets say I'm in my consuming application. I have overwritten your addon's default IDLE_TIMEOUT value by simple extending your service and set it to 1 minute. Now I'm on route /foo where the IDLE_TIMEOUT still equals my default 1 minute...but when I navigate to route /bar I need to update my overwritten IDLE_TIMEOUT value yet again to 2 minutes.

Let me know if I'm simply overlooking anything or if there would be a way to allow more configurable behavior here. If there's anything I can do to help let me know. Thank you!

/cc @crodriguez1a

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/37424509-feature-request-programatically-update-idle_timeout-value-from-my-app?utm_campaign=plugin&utm_content=tracker%2F34204874&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F34204874&utm_medium=issues&utm_source=github).

[elwayman02]

Looking at the code, it seems you may be able to just do this.set('userIdle.IDLE_TIMEOUT', X); when you change routes, since the resetTimeout method gets the timeout length each time it is triggered. Has programmatically updating your timeout service not worked for you?

[alexdiliberto]

@elwayman02 Seems like that should work but the timing is off. Here's a crude twiddle https://ember-twiddle.com/0faf8804c209997652670c88213d2e23?openFiles=components.auth-session-timeout.js%2C

/ route sets IDLE_TIMEOUT=1sec, /login-flow route sets IDLE_TIMEOUT=10sec, /dashboard route sets IDLE_TIMEOUT=5sec. If all i do is click between the 3 routes and set IDLE_TIMEOUT in some hook like didReceiveAttrs it will still hold the previously set value

Open the twiddle and the console panel. Now click on the /login-flow route...should timeout at 10 seconds but has previous value of 1. Now click the /dashboard route...should timeout at 5 seconds but has previous value of 10

The resetTimeout, specifically this line https://github.com/elwayman02/ember-user-activity/blob/master/addon/services/user-idle.js#L45 and this line

ember-user-activity/addon/services/user-activity.js

Line 91 in 2afdb58

this.trigger('userActive', event);

is already triggered with the "old" value before my consuming app has a chance to overwrite the value from a component's render hook or a route hook. the throttle call in services/user-activity.js triggers 'userActive' on the initial click of the {{link-to}} before the transition occurs

I tested this with and without eaglerly loading the service and I experience the same behavior. I also tested firing the set within the component:auth-session-timeout (like didReceiveAttrs) as well as various route hooks like didTransition, activate, etc

I have a local repo with some additionall logging here and you can see the order

// click /dashboard from /login-flow route

user-activity.js:93 TRIGGER `userActive` from service:user-activity#fireEvent
user-idle.js:45 resetTimeout triggered. IDLE_TIMEOUT= 10000
// note resetTimeout has already been triggered before the route hooks fire
dashboard.js:9 SETTING userIdle.IDLE_TIMEOUT=5000 from route:dashboard#activate

[alexdiliberto]

I was playing around with this a little more tonight and I have a workaround,

Anytime an app wants to set IDLE_TIMEOUT to some new value, they should then immediately call the resetTimeout() method from their consuming apps extended userIdle service....Not ideal from a consuming apps perspective, but it does seem to work.

updateIdleTimeoutValue() {
  set(this, 'userIdle.IDLE_TIMEOUT', myNewTimeoutValue);
  // This line is necessary to properly clear out the "stale" previous value
  get(this, 'userIdle').resetTimeout(); 
}

It could be useful as a future enhancement to provide an interface to the user like get(this, 'userIdle').updateIdleTimeout(value); or something like this.

Updated the previous twiddle with the workaround for anyone looking for a solution. https://ember-twiddle.com/0faf8804c209997652670c88213d2e23

[elwayman02]

I think this is a good future enhancement, going to reopen so it doesn't get lost! I'm glad you found a workaround for now, I'll definitely put this into the next release of the addon if possible.