Description of problem: Currently we display warning on all non recommended browsers. We should change this message to reference wiki page from BZ #1188226 for all non ESR firefox versions. This message should be general and refer users to reading the wiki page.
see bug 1188226 for updated support matrix.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
oVirt 3.6.0 has been released on November 4th, re-targeting to 3.6.1 since this bug has been marked as high severity
Created attachment 1095788 [details] supported browser message - current state vs suggestion
Moran, can you please take a look at attachment 1095788 [details] (that compares the current state to my suggested solution) and confirm that you approve the suggested solution? let me know if you have any questions or comments. thanks.
(In reply to Einav Cohen from comment #5) > Moran, can you please take a look at attachment 1095788 [details] (that > compares the current state to my suggested solution) and confirm that you > approve the suggested solution? let me know if you have any questions or > comments. thanks. In general, looks good to me. just double checking message will appear only for non-tier 1 browsers right?
Created attachment 1100510 [details] supported browser message - current state vs suggestion
(In reply to Moran Goldboim from comment #6) > (In reply to Einav Cohen from comment #5) > > Moran, can you please take a look at attachment 1095788 [details] (that > > compares the current state to my suggested solution) and confirm that you > > approve the suggested solution? let me know if you have any questions or > > comments. thanks. > > In general, looks good to me. just double checking message will appear only > for non-tier 1 browsers right? that's right - I had a mistake in the original attachment. attachment 1100510 [details] is now corrected accordingly. thanks.
Just to make this more fun than it already is. For master we now have a fully implemented SSO page. The SSO page doesn't display that message at all. So this should only be in the 3.6 branch right?
(In reply to Alexander Wels from comment #9) > Just to make this more fun than it already is. For master we now have a > fully implemented SSO page. The SSO page doesn't display that message at > all. So this should only be in the 3.6 branch right? for master, it would be great if we can have this message on the SSO page - is it possible? for 3.6, we should have this message in the web-admin login page.
AFAIK on the new SSO page we do not have the infrastructure to detect the browser version at this point in time (I believe it is a fairly straight forward html page without much javascript). I am sure it is possible to add, but not trivial. In essence it will be 2 completely separate patches. One for the old login screen in 3.6 and one for the new login screen on master. However I don't know if it makes sense on master, as the SSO login is not just for webadmin/user portal but other things as well which may or may not have the same compatibility requirements.
(In reply to Alexander Wels from comment #11) > AFAIK on the new SSO page we do not have the infrastructure to detect the > browser version at this point in time (I believe it is a fairly straight > forward html page without much javascript). I am sure it is possible to add, > but not trivial. > > In essence it will be 2 completely separate patches. One for the old login > screen in 3.6 and one for the new login screen on master. However I don't > know if it makes sense on master, as the SSO login is not just for > webadmin/user portal but other things as well which may or may not have the > same compatibility requirements. Moran - any thoughts? before implementing this for 3.6, we need to decide what to do for 4.0, which doesn't have individual login pages. can we simply skip this feature for 4.0? put a message elsewhere?
(In reply to Einav Cohen from comment #12) > (In reply to Alexander Wels from comment #11) > > AFAIK on the new SSO page we do not have the infrastructure to detect the > > browser version at this point in time (I believe it is a fairly straight > > forward html page without much javascript). I am sure it is possible to add, > > but not trivial. > > > > In essence it will be 2 completely separate patches. One for the old login > > screen in 3.6 and one for the new login screen on master. However I don't > > know if it makes sense on master, as the SSO login is not just for > > webadmin/user portal but other things as well which may or may not have the > > same compatibility requirements. > > Moran - any thoughts? before implementing this for 3.6, we need to decide > what to do for 4.0, which doesn't have individual login pages. can we simply > skip this feature for 4.0? put a message elsewhere? It's not worth the effort for 4.0, we have a well defined browser list in the docs. It should be good enough. The login can also be to other services that may have different browser support and this can become complex, let's avoid this.
if having a well defined browser list in the docs is good enough for 4.0, is it good enough for 3.6 as well? i.e. can we simply remove the message altogether? I'm trying to avoid the (minor) complexity of supporting different "this page" URLs for upstream and downstream [see Suggestion in attachment 1100510 [details]].
(In reply to Einav Cohen from comment #14) > if having a well defined browser list in the docs is good enough for 4.0, is > it good enough for 3.6 as well? i.e. can we simply remove the message > altogether? I'm trying to avoid the (minor) complexity of supporting > different "this page" URLs for upstream and downstream [see Suggestion in > attachment 1100510 [details]]. Sound ok by me. Moran?
(In reply to Yaniv Dary from comment #15) > (In reply to Einav Cohen from comment #14) > > if having a well defined browser list in the docs is good enough for 4.0, is > > it good enough for 3.6 as well? i.e. can we simply remove the message > > altogether? I'm trying to avoid the (minor) complexity of supporting > > different "this page" URLs for upstream and downstream [see Suggestion in > > attachment 1100510 [details]]. > > Sound ok by me. Moran? do we have another place we can present this warning to the client which isn't the welcome screen and that will address this specific user and not be reflected on the general event log? do we have such infrastructure?
(In reply to Moran Goldboim from comment #16) > > do we have another place we can present this warning to the client which > isn't the welcome screen and that will address this specific user and not be > reflected on the general event log? do we have such infrastructure? we have recently introduced the contextual UI alerts feature [1] as part of addressing bug 1275760. Today we are using only the 'Danger' type and only displaying this alert when a client-side (javascript) uncaught exception occurs, but the infrastructure is in place to display any alert type that we want whenever we want. Is this the type of solution that you were looking for? [1] 'Danger' alert http://i.imgur.com/xcZhcaK.png 'Warning' alert http://i.imgur.com/Jgdl6vA.png 'Success' alert http://i.imgur.com/U9EGejw.png 'Info' alert http://i.imgur.com/llLVR9d.png
(In reply to Einav Cohen from comment #17) > (In reply to Moran Goldboim from comment #16) > > > > do we have another place we can present this warning to the client which > > isn't the welcome screen and that will address this specific user and not be > > reflected on the general event log? do we have such infrastructure? > > we have recently introduced the contextual UI alerts feature [1] as part of > addressing bug 1275760. Today we are using only the 'Danger' type and only > displaying this alert when a client-side (javascript) uncaught exception > occurs, but the infrastructure is in place to display any alert type that we > want whenever we want. > Is this the type of solution that you were looking for? > > [1] 'Danger' alert > http://i.imgur.com/xcZhcaK.png > > 'Warning' alert > http://i.imgur.com/Jgdl6vA.png > > 'Success' alert > http://i.imgur.com/U9EGejw.png > > 'Info' alert > http://i.imgur.com/llLVR9d.png Trying to summarize the requirements: -we need an a solution that will fit both 3.6 and 4.0 for warning the customer about the browser he's using if it is not on our tier 1 support -the level of the warning/error/alert has to be based on the support tier -the warning message needs to be linkable (to documentation) -the warning message needs to be presented *once* upon login and can be removed from the screen -the customer will have the option to disable this type of alert (IT dept cooperate browser limitations usecase) so all the company users won't experience it every time they login If we can make sure all those requirements can be supported, i think we can approach it this way. anything i forgot?
(In reply to Moran Goldboim from comment #18) > > Trying to summarize the requirements: > -we need an a solution that will fit both 3.6 and 4.0 for warning the > customer about the browser he's using if it is not on our tier 1 support ack - a warning will be issued upon login to the web-admin when relevant. > -the level of the warning/error/alert has to be based on the support tier too complex - this will require us to maintain the full support-tier matrix in the UI code, rather than maintain only tier 1, as we do today. I recommend issuing a warning [http://i.imgur.com/Jgdl6vA.png] when browser is not tier 1, and issuing nothing otherwise. > -the warning message needs to be linkable (to documentation) ack (will require a new config value to differentiate between upstream link and downstream link; alternatively, we can use the branding mechanism to do that, which will require building also a new branding package -> may require an additional BZ). > -the warning message needs to be presented *once* upon login and can be > removed from the screen ack [note the "x" on the right-hand side of the warning as seen in http://i.imgur.com/Jgdl6vA.png] > -the customer will have the option to disable this type of alert (IT dept > cooperate browser limitations usecase) so all the company users won't > experience it every time they login ack (this will require introducing a new engine-config value, which may complicate the patch a bit; if this is not a hard requirement, it will be great if we can drop it). @Moran - thoughts? ack to all of the above?
(In reply to Einav Cohen from comment #19) > (In reply to Moran Goldboim from comment #18) > > > > Trying to summarize the requirements: > > -we need an a solution that will fit both 3.6 and 4.0 for warning the > > customer about the browser he's using if it is not on our tier 1 support > > ack - a warning will be issued upon login to the web-admin when relevant. > > > -the level of the warning/error/alert has to be based on the support tier > > too complex - this will require us to maintain the full support-tier matrix > in the UI code, rather than maintain only tier 1, as we do today. > I recommend issuing a warning [http://i.imgur.com/Jgdl6vA.png] when browser > is not tier 1, and issuing nothing otherwise. > > > -the warning message needs to be linkable (to documentation) > > ack (will require a new config value to differentiate between upstream link > and downstream link; alternatively, we can use the branding mechanism to do > that, which will require building also a new branding package -> may require > an additional BZ). > > > -the warning message needs to be presented *once* upon login and can be > > removed from the screen > > ack [note the "x" on the right-hand side of the warning as seen in > http://i.imgur.com/Jgdl6vA.png] > > > -the customer will have the option to disable this type of alert (IT dept > > cooperate browser limitations usecase) so all the company users won't > > experience it every time they login > > ack (this will require introducing a new engine-config value, which may > complicate the patch a bit; if this is not a hard requirement, it will be > great if we can drop it). > > @Moran - thoughts? ack to all of the above? ack on all of the above - i would still like to have the option to disable this warning in general, since it can introduce of lot of noise over specific customers.
@Moran, The associated patch includes everything for master, there is one question I have left before I backport part of it to 3.6. Where should the downstream link point to. I can't really point it to the oVirt wiki.
Can you please provide the expected final link to the updated tiered browser support?
If no answer on that today, I'll push this to 3.6.4.
(In reply to Yaniv Dary from comment #22) > Can you please provide the expected final link to the updated tiered browser > support? When this content is published for 3.6 GA, it will be available from the following link: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Installation_Guide/chap-System_Requirements.html#Red_Hat_Enterprise_Virtualization_Manager_Requirements (See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html/Installation_Guide/chap-System_Requirements.html#Red_Hat_Enterprise_Virtualization_Manager_Requirements for the working Beta link.) Please let me know if you need any further information.
This shouldn't be a blocker. Putting exception.
I double checked and this information appears to be in the docs rpm as well at the same location so I am going to link to the installed docs instead of the access on (Looks like both came from the same source).
Verified on 3.6.3-4