Forums | Mahara Community
Customizing login screen
08 September 2013, 12:42 AM
I have a question from my continuing exploration of a multi-institution Mahara.
When you click on a deep link inside Mahara, such as a non-public institution page, you get a specialized login page, designed for the whole site...
What are the opportunies for customizing this?
Ideally,in a multi-institution site, it could be customized to the specific institution.
Failing that, some way of changing the login prompt to reassure users that they will end up in their institution would be good...
Edits to this post:
- Aaron Wells - 10 September 2013, 11:55 AM
08 September 2013, 2:02 AM
Sorry, subject line should have read:
"Customizing Login Screen"
10 September 2013, 12:45 PM
I've fixed the subject line.
I reviewed the Mahara login process in depth a few weeks back as part of a bug fix. Basically, there are two main ways you can log in:
1. If you're viewing the site's home page and you're not logged in, you'll see the login form in a sideblock.
2. If you're not logged in and you try to access a page that is not public-accessible, you'll see what we call the "transient login page". This is a page where the only content on the page is the login form.
What you're describing, sounds like, when you get the "transient login page" while trying to access a (user-created) Page, it should display a different theme depending on which Page you were trying to access. There's currently no Mahara feature for that, and the way it's written it would be a little tricky to implement... it actually happens in two page loads: the first one instantiates the View and asks it if you can see the page. If the answer is no, then it throws an AccessDeniedException, which does a redirect to the same URL but with "&login" on the end; that then gets picked up by the call to auth_setup() in init.php at the top of the page, which causes the transient login page to display. The crucial bit is that it happens on that page load before the View is instantiated, hence you can't ask the View what theme it wants to display.
You could maybe hack something into the optional function "local_init_user()" in local/lib.php. You can also customize the contents of the login sideblock and/or the transient login page by editing their templates, which are 'sideblocks/login.tpl' and 'login.tpl' respectively. Probably the easiest way to do that would be with a local theme override. To do that, you'd copy for instance htdocs/theme/raw/templates/login.tpl into htdocs/local/theme/templates/login.tpl, and then edit the copy to contain whatever content you want.
12 September 2013, 2:06 AM
Thanks Aaron, this is very helpful.
It is indeed the transient login page that concerns me. Thanks for breaking out issues and potential solutions.
28 October 2013, 5:03 AM
Still thinking about this one; what's involved with adding a login block to an institution's home page? Is that a hack, or a feature request? 8-> If a hack, would it need to be done for every institution?
31 October 2013, 3:36 PM
Hm, interesting idea. You could do that with an extension. Currently the login form (as seen on the front page) is a "sideblock", which despite the word "block" in it, is actually an internal Mahara API separate from Block plugins.
But you probably could write a Block plugin that displays the login form. It would just need to call auth_get_login_form(), which according to my notes is the function that the sideblock and the transient login page use to generate the login form. Then you could add that block to any Page you want to create a custom login page for different institutions. One wrinkle to this is that you'd have to figure out what to show for that block when a logged-in user looks at the page; perhaps some kind of post-login message.
09 November 2013, 1:32 AM
Is that a lot of coding or a little, do you think?
Continuing to think this through, the UX issue I see at this point is that the login will send the user to the sitewide Dashboard. It will take some thinking to make that non-disruptive, but I'll noodle on that.
Stepping back a bit, I'm with Gordon Macleod that an institution-specific dashboard would be very cool. How non-trivial is that? Might that be on the MyPortfolio wishlist?
11 November 2013, 8:47 AM
An institution dashboard is not on the MyPortfolio wishlist as far as I know. If changes to the dashboard are made, I think we should rethink how the dashboard is generated and potentially make more far-reaching changes, e.g. have an admin interface to decide which blocks to display by default.
11 November 2013, 11:50 AM
Making the default Dashboard admin-editable sounds like a great idea to me. I'd guesstimate it as a medium-small effort. (The default Dashboard is currently stored in the DB as a normal Page belonging to the "root" user with ID 0)
One thing about custom default Dashboards for Institutions, is that the user's Dashboard page is created at the time the user account is created. So, if a user switched Institutions, they would not get a copy of the new Institution's default Dashboard, unless you added special code for that. (And if you did, you'd be clobbering any customizations they've made to their Dashboard.)
11 November 2013, 4:16 PM
Since the institution can only control the default settings of the dashboard, I don't think we should attempt to overwrite things when a user switches institutions. We don't do that in other places either, e.g. user quota, default user settings etc.
There may be a difference between an institution default dashboard and a dashboard that users could actually not customize. Right now we are more on the former than the latter side to allow users to make changes to their dashboard and display the content they want to show and not what an admin wants them to see. Changeable content can be placed above the "homeinfo.tpl" which of course right now is site admin controlled. If that should also be institution controlled, we'd need to ensure that the site admin has a place somewhere on the logged-out and logged-in page to post notices that need to be site-wide and that institution admins aren't allowed to overwrite.