Bug 1328988 - UI Session timeout and Advanced Setting timeout are not persistent and can revert to default setting
Summary: UI Session timeout and Advanced Setting timeout are not persistent and can re...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.6.0
Assignee: Jason Frey
QA Contact: Jeff Teehan
URL:
Whiteboard: appliance:timeout
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-20 19:55 UTC by Jeff Teehan
Modified: 2016-05-12 22:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-12 22:47:51 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Description Jeff Teehan 2016-04-20 19:55:51 UTC
Description of problem:
When I change the session timeout to anything other than 1 hour, the advanced settings Session: always says 3600.

If I change advanced to say 300, then the UI timeout will say 5 minutes, but the advanced reverts to 3600 immediately upon Save.

This only becomes an issue if the appliance timeout is set to something other than 1 hour, and the user changes any other advanced setting.  When that happens, the timeout will update back to 1 hour without notice.

Version-Release number of selected component (if applicable):
5.6.0.1 Beta 1

How reproducible:
Always on this appliance

Steps to Reproduce:
1.  Change UI timeout (Configuration/Authentication) setting to 5 minutes and Save
2.  Go to Advanced  session: timeout:  it says 3600
3.  Change the smtp field below to bob.com or something and Save.
4.  Go to Authentication and the timeout has reset to 1 hour.
5.  You can try to change the 3600 to anything else and save and you'll see that the value does not persist.

Actual results:
Line 4. above

Expected results:
The UI and the Advanced session should remain linked.

Additional info:
I only set it so low to track down a timeout bug.

Comment 2 Jason Frey 2016-04-21 19:41:02 UTC
I'll take this since it sounds like config revamp.

Comment 3 Jason Frey 2016-04-21 19:41:33 UTC
I'll see if this is reproducible on beta2

Comment 4 Jeff Teehan 2016-04-21 19:48:16 UTC
It's in beta 2.  I just check 2.1 with the new UI and it's still misbehaving.

10.16.8.108 if you want to look.

Comment 5 Jason Frey 2016-04-21 20:20:39 UTC
Nick and I tested this all over on the beta2 candidate and can't reproduce.  We tested on 2 separate appliances.  I'm not sure why you are seeing it but I'll investigate.

Comment 6 Jason Frey 2016-04-21 20:39:53 UTC
I can't seem to hit that appliance, Jeff.  Is it still running?

Comment 7 Jeff Teehan 2016-04-21 22:08:35 UTC
hit me up in cfme-qe or cfme-eng under jt and I'll fire up bluejeans.  Otherwise, not it's not up because I gave you the wrong IP.  D'oh.
https://10.16.6.108

Comment 8 Jeff Teehan 2016-05-06 16:34:45 UTC
It's still not working in 5.6.0.4 and it's working fine in 5.6.0.5.

I'm happy to close it, but it would be nice to know what changed, if anything.

Comment 9 Jeff Teehan 2016-05-12 22:47:51 UTC
Well, whatever it was, it's gone now.  Closing as worksforme.


Note You need to log in before you can comment on or make changes to this bug.