On the OPAC main page (opac-main.tt) if CAS or Shibboleth are enabled than we remove the login box on the right side of the page (#login). I am wondering if this is necessary: 1. It does not remove local login functionality as you can still login via the modal in the top right corner. 2. In multi library systems this can be a problem as some might use a SSO service while others would like to see the login box on the right side. 3. Maybe it would be simpler to keep the login box regardless of sign in method and hide it via CSS for libraries that don't want it?
I think the reasoning was that when you have a lot of different authentication methods activated they would clutter up the right column. Or the user would not find the Shibobleth/CAS options as they asssume they have to enter it there (where the other links don't show). Hope that makes sense.
(In reply to Lucas Gass from comment #0) > 3. Maybe it would be simpler to keep the login box regardless of sign in > method and hide it via CSS for libraries that don't want it? This is my inclination. Some libraries want both local login and SSO, while others don't. CSS is the easiest way to control this on a per-instance basis. Bug 31064 was designed to make it easier to control the display of the local login. That said, it looks like there are quite a few lines like "<p>If you do not have a Google account, but do have a local account, you can still log in: </p>" which are missing selectors at the moment...
Is this one still valid? I don't use CAS or Koha's Shibboleth implementation... just OpenID Connect and other mechanisms
(In reply to David Cook from comment #3) > Is this one still valid? > > I don't use CAS or Koha's Shibboleth implementation... just OpenID Connect > and other mechanisms Yes this is still valid.
Created attachment 177144 [details] Screenshot showing proposed form update It sounds like what we want is to show all login options unless 'opacShibOnly' is true? The attached screenshot shows updated buttons (making the Google button consistent with buttons for custom identity providers) and a generalized note to be shown if OAuth and/or other identity providers are enabled. I think we could even simplify the hint further: "If you have a local account you can log in below"
Created attachment 177145 [details] Alternate proposal Here's a different version which follows other examples I've seen on the web.
(In reply to Owen Leonard from comment #6) > Created attachment 177145 [details] > Alternate proposal > > Here's a different version which follows other examples I've seen on the web. I like the alternative proposal, Owen. Many libraries like this style of login.