Bug 1328988

Summary:	UI Session timeout and Advanced Setting timeout are not persistent and can revert to default setting
Product:	Red Hat CloudForms Management Engine	Reporter:	Jeff Teehan <jteehan>
Component:	Appliance	Assignee:	Jason Frey <jfrey>
Status:	CLOSED WORKSFORME	QA Contact:	Jeff Teehan <jteehan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.6.0	CC:	abellott, jfrey, jhardy, obarenbo, psavage
Target Milestone:	GA
Target Release:	5.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	appliance:timeout
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-05-12 22:47:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.