22 December 2013, 16:46

This is a feature discussion posted on behalf of Christian Kleinhanss.

It would be nice if it were possible to make certain extensions / plugins only available to a certain group of users. A "group of users" could be defined similarly to a group that has certain publishing possibilities.

For example, beginners of Mahara will only receive a basic set of possibilities to interact with the site, e.g. creating text boxes, inserting images. Whereas more advanced users can also link to external content or create a journal.

01 January 2014, 11:45

A smart feature IMHO also.
Often I find school administrators wanting to do different things. While some want their users to do more group focused work, others want to do more of a file housing and collection building processes. Then in a following year, they may want to focus on other areas and add more features. Although I have never done it in a meaningfull way, I wonder how the mahara experience is when features are turned off.
I think I would implement this on the institution level so not to confuse users who are in multiple instituions.

Dirk

01 January 2014, 13:01

Hello Dirk,

I don't know if limiting the feature to the institution level would make a big difference. On instances where a user can be in multiple institutions, they'd still run into the issue of one institution allowing something whereas another doesn't. That's what makes some of the permission implementations quite tricky in Mahara. Granted though, most sites that have multiple institutions probably either don't allow users to be in multiple institutions or only a relatively small number of users is actually in multiple institutions.

One question though for me that comes out of your comment is who would have the power to decide which features are available to whom. From what I understand from Christian's wish, it should be fairly flexible, e.g. a teacher or even peers could get a vote. That might get quite tricky because one teacher would allow a student to publish a page wheras another teacher might not see that the student is ready to do so yet. Would the student then still be able to publish a page publicly?

In contrast to a LMS where access to resources and adctivities is based on a course (at least in Moodle) and students only have as much or little access as the teacher in that one course allows them to have, the portfolio on Mahara is not course-bound and there is no control mechanism that would allow the creation of a public page for course A portfolio but not course B portfolio because we do not make that distinction. Should we or would it get more complicated on top of our current permissions framework?

Cheers

Kristina

06 January 2014, 16:43

Indeed, as we've begun adding more configuration options to institutions, the question of how to handle multiple institutions comes up more frequently. So far, it's been dealt with on a case-by-case basis.

In the case of Skins (where the setting is simply ON/OFF), I thought it made sense that if you belong to at least one institution that allows Skins, you can use them. For other features, it could make sense that if you belong to at least one institution that forbids it, you forbid it. I suppose if we wanted to be more robust, we could expand the option list to something like this, to allow site admins to go either way:

• "Site Default"
• "Forbid (even if another of the user's institutions allows it)"
• "Allow (unless another of the user's institution forbids it)"
• "Off (unless another of the user's institutions allows it)"

But that seemed like overkill, given the assumption that even in sites that allow multiple institutions, most users will likely be in only one institution.

Cheers,

Aaron

06 January 2014, 16:30

This is actually partially implemented in the anti-spam measures that I put up on mahara.org. Certain activities (posting external links and images, creating public pages) are not available to newly registered users. Only after a user has made a forum post that receives a certain number of responses from other experienced users, or after they've been manually approved by a staff or admin, do they gain access to those features.

It's not exactly what's being requested here, but it's similar enough that I thought it was worth pointing out.

As mentioned further down in this thread, the tricky part with these permissions is always in how you maintain the groups. Moodle has a completely flexible roles, contexts (which exist in a hierarchy, root -> course-category -> course -> assignment), & permissions system that allows you to grant permissions to roles, and grant different roles to a user in different contexts, and inherit a user's permissions from their role in a context's parents. It's perhaps one of the more conceptually complex parts of Moodle, and its implementation was quite an optimization challenge.

If we were to do something similar in Mahara we'd want to consider:

1. What "contexts" does Mahara have?
2. What "permissions" does Mahara have?
3. Can we implement this in a way that doesn't bog down in a large site? (One key to that is being able to still figure out a user's permission in a particular context with a single SQL query, which tends to be difficult when you have hierarchical permission contexts like Moodle does)

Cheers,

Aaron

24 September 2015, 22:37

Hi

I'd be really interested in this feature also.  In our case, we support both HE and FE students and we have features switched off (plugins like Facebook Like etc) that we believe would be useful to HE students but would not be appropriate for use with some FE students.  Other features possibly affected would be public pages, allowed iframe sources, social profile etc.

This could be handled by setting FE and HE in different institutions, although we haven't done that up to now, so the ability to release features per institution would be good.

Regards

Marion

25 September 2015, 11:30

Since I last looked at this thread, I've become aware of the (previously undocumented) local hook function "local_get_allowed_blocktypes($category, $view)", that lets a site customize which blocktypes are available on a given page.

Using this, you could put together a custom system for restricting blocktypes to certain users. The pseudocode for it would be something like this (in htdocs/local/lib.php):

function local_get_allowed_blocktypes($category, $view) {
    global $USER;
    if ($USER is type1) {
        return list_of_blocks1;
    }
    if ($USER is type2) {
        return list_of_blocks2;
    }
    // Return null to use the default list of blocktypes
    return null;
}

Cheers,

Aaron

25 September 2015, 19:48

Hi Aaron,

That looks promising. By default is that based on role (eg user/tutor/admin) or is there an existing way to specify who belongs in type1, type2? I was thinking a similar option to group shared access to pages might be a simple way to restrict access to specific blocks. We use course groups extensively to give viewing rights to content we want cohorts of students to look at but not edit (unless as a copied template). It means all of our users only need to join one group then get access to around 30 other groups.

I'm also wondering how it will appear visually - I'm anticipating that the block will be completely invisible if users aren't in the permitted type list as it simply doesn't render onto the page? It would be frustrating if they could see the header but nothing else. Selective visibility of blocks would solve another issue with my own content, which is accessed by students from different years and different degree programmes - our 'portal' page on Mahara pointing students at the relevant content is a 2-step process (which programme, then displays relevant shortcut icons to groups). If it was possible to put all the links on one page but only display relevant blocks to each programme it would remove the first click. It would also please staff used to being able to hide individual resources on Moodle if they could do the same on Mahara - presumably if a similar approach to sharing access was used the visibility could also be switched on/off on a date basis too.

Regards, Gordon.

28 September 2015, 11:18

Hi Gordon,

The "local_get_allowed_blocktypes()" is just a hook function, which is sort of a placeholder. By default this function isn't defined, but if you do write up a function with this name, and put it in your htdocs/local/lib.php file, then Mahara will call this function when deciding what blocks to display in each category of the block chooser. So, this is a solution that requires some PHP programming knowledge.

Specifically all this method is for, is limiting which blocks a user can choose to place on pages. That is, it can take away blocks from the block selector you get on the "Edit page" screen.And since it's a hook function, you can use any method you want for categorizing users and determining what blocktypes they should see. $USER is a global variable that represents the current logged in user. Probably what you'd want to do is $USER->get('id') to get the user's ID, and then do some database queries to find out other things about the user, like whether they belong to a particular institution or group.
(The main advantage to Mahara of just having a hook function like this, is that we don't have to come up with a general-purpose one-size-fits-all approach to user roles.)Cheers,Aaron