Forums | Mahara Community

Support /
Best Practice for managing a Mahara instance


David Kane's profile picture
Posts: 5

28 June 2017, 1:17 AM

Hello

I have recently become the Mahara sysadmin in my University and I am looking for some guidelines around user account management for Mahara. We started running Mahara as a pilot a number of years ago and it has grown to the point where we have about 3000 users in 10+ institutions. A recent curriculum review recommended increased use of ePortfolios, so I want to be prepared for managing more users.

Is there a best practice guide available? I am particularly interested in the following:

Does anyone allow 'self-registration' via the Register link on the login page? (How can I turn this off globally?)

Do you have any advice on matching Institutions to University structures?

How do you place users in the correct institution? As I understand it, if a user who exists in our LDAP logs in to Mahara with their LDAP credentials, they will be set up under the 'No Institution' institution and it is up to 'someone' to assign them.

How do you disable/delete users? I would like to be able to automate this based on student registration status rather than last login date. Does anyone purge the database of deleted users, and if so, how?

Thanks
David

Kristina Hoeppner's profile picture
Posts: 3396

28 June 2017, 1:14 PM

Hello David,

Congrats on your new job! We don't have a best practice guide available as there are lots of different scenarios, but there are certainly a few things that I can think of (very much relating to your questions) that could go into a guide or check list for admins to go through when setting up or reviewing a site. So we can look into adding some of that in a future iteration of the user manual.

Self-registration

If you don't want to allow it, you'll need to disallow it for each institution. You can only globally require the registration confirmation. As soon as one institution allows registration, the link is shown on the homepage but people would only be allowed to register for that one institution.

Matching institutions to a university structure

That's a tough one as there is usually not a 1-to-1 relationship but many different possibilities.

If you don't use MNet, you have more flexibility. MNet only allows you to add one Moodle to one Mahara instance rather than multiple.

Not using MNet, the structure that would make most sense to me would be to set up one institution per school / faculty / department so that they can then support their own users more closely if needed without you having to give tons of people site admin access. Putting people into individual institutions can serve the following purposes:

  • Put templates into new user accounts automatically. Having multiple institutions you can then do that for engineering and education. If all are in one institution, either everyone gets the same templates or students will need to copy them themselves.
  • Have different dashboard messages for different departments or also for alumni.
  • Allow certain uni admins to view the institution settings or manage users when they need to do some troubleshooting.
  • See statistics for users in the individual institutions easily.

Having students / instructors in separate institutions does not impair them in sharing portfolios with others. They can still do that across institution boundaries.

Limitations:

  • I think it wouldn't work with single sign-on via SAML without customizations. I think it complains if you leave all basic parameters the same, in particular the domain.
  • While it is possible to put students into multiple institutions, it often causes more headache than it solves things. So if you have a lot of overlap between the institutions / departments, it may not be the best way forward. But Mahara can always be improved to accommodate that better.

Students into correct institutions

I suspect that your LDAP settings are incorrect. We had a client who wanted all primary school students in one institution and all secondary students as well as teachers in their respective institutions and that was easily done by providing the correct LDAP tree information in the settings. Nobody ever ended up in "No institution".

When you set up an authentication method in Mahara, you specify who can log in how. Authentication methods map to their respective institutions, meaning that I can't set up the exact same LDAP details in two institutions as Mahara wouldn't know where to put them. But if I distinguish between one group of users and another, it's possible. The same goes for LTI for example: If I want to allow LTI in two institutions, I need to set up two connections and provide the correct consumer keys and secrets on the other end.

If a student is in two institutions, they will still only have one primary authentication method and that sits within one of their institutions.

Disable / delete users

If you use LDAP, you have some user sync options available.

Otherwise, you can auto-expire users, expire them manually or suspend them. If you expire your users from an institution, the only thing that happens is that they are removed from their institution but would still have an account in Mahara.

I'm not aware of any other option in core besides these two at the moment.

When a user is deleted, their content is purged except for forum posts and other things they did in a group as it's the group's content. However, their name will not be displayed next to forum messages and comments anymore.

Hope that helps to think more about what you'd like to do.

Cheers

Kristina

 

 

David Kane's profile picture
Posts: 5

29 June 2017, 1:50 AM

Hello Kristina

 

Thanks for your very detailed reply.  It has helped me to identify where I need to focus my efforts to make our instance a better fit for the users.  We do have LTI from Blackboard, but not everyone uses it.  I will need to have a closer look at how LDAP is configured and whether we can leverage it to auto populate the Institutions, I think the tree is quite flat (just staff and student branches) but there may be attributes we can look at.

I may be back with more questions.

Thanks again

David

 

3 results