13 October 2009, 7:10

Hi All,

Some months ago we ran a pilot Mahara install with about 20 schools in CLEO in the UK. The outcome of this work was mostly inline the school related work which is mentioned on the Mahara roadmap, though some of our feedback was a little bit more draconian than the features there .

We are now beginning to start work on the requests which have come out of our pilot. We are very keen to work with the community as much as possible to ensure what we implement can get merged if it fits with the mahara vision (we are aware that some of the features may be quite 'against the grain' of the mahara philosophy).

At this stage we are still doing initial exploratory work and gathering requirements (we are fairly new to mahara development and not particularly up to date with whats in 1.2).

 Here is a high level overview of the first few features (/restrictions!) we are looking at implementing:

Controlling Group Creation

When a student creates a group it has to go through some sort of approval by a member of instiutional staff/admins before it is made live.

Per institution front page

Schools would like the initial front page which users see when they log in to be customised by institution rather than globally (not sure if this can be achieved with institutional views at the moment?)

Wall and Messaging Disabled By Insitution

Some schools just don't want these features enabled.

Friendship Controls

Restrict friendships to a single institution and only institutional level friendships and allow institutional staff/admins to moderate other friendships.

I think we have two key questions at this early stage:

• How to implement 'permissions' as a concept - this is the main focus of our work. Using the existing institution staff/admins seems like the place to do this, but does it make sense?
• How to implement per-institution settings as some of the controls will need to apply at this level. It probably gets quite interesting considering that mahara is user rather than institution centric..

13 October 2009, 19:08

Hiya Dan - good to see you again. I have a quick question for you before I answer - did you receive any feedback from these schools that would be able to be fed into the roadmap pages? I note you said "mostly inline", any other feedback you have would be most valuable 

Controlling Group Creation

This is actually a long asked for feature, although normally expressed as "Can we prevent students from creating groups?". There's no conflict with the pedagogical aims of Mahara to have such a feature, I feel - so code for it would be welcome. You add another layer to that - the idea of approval. I like it - want to sketch up some mockups of how you think it would work? 

Per institution front page

Firstly, no this can not be achieved with institution views (which haven't changed in 1.2 btw). Institution views exist at the moment soley so that institutions can make templates for others to copy.

You touch on two things that the dev  team have bounced around as ideas from time to time:

1. The idea that institutions currently are rather nebulous in the system, and it would be nice if they had a more concrete presence - e.g. through having their own pages that people can browse to, and being available to choose for view access.
2. More things in the system should have pages, preferrably built with the View editor 

In other words - institution home pages are a good idea, and they should be implemented as Views 

Given that friendships don't really "mean" anything (e.g. two users who are friends don't all of a sudden get to see more about one another or see any of their stuff), what's the logic behind trying to restrict friendships? Not a criticism, I'm interested in the thinking behind it is all 

Mahara doesn't have an all encompassing permissions system like Moodle has, and to be honest I think this is a good thing. After watching the Catalyst Moodle team struggle day in and out with the performance headaches caused by it, and hearing horror stories from teachers, I'm not sure we want to go down that road  (having said that, I'm sure we could design a better one.. but right now I don't see the need).

We currently have a simple permission model, as you've spotted. Site admins tend to be able to do everything, institution admins can do most things to institutions.. etc. I think the stuff you've listed here will fit into that structure nicely 

13 October 2009, 20:16

Hey Nigel,

Thanks for the useful (and positive!) feedback, just a few comments about our thoughts from discussions today before I go to bed, I will follow up more tomorrow..

We were discussing the ideas around the various restrictions we've been tasked to do and talked more about what is trying to be achieved and think most of the tasks would fit into a 'walled garden' concept of institutions as you mention.  That is that an institution could elect to be a 'walled garden' where by the ideal is that a single institution functions as though its in its own personal Mahara instance. Users from this institution can only message/make friends/interact with other users in their own institution. Similarly users from other institutions can't interact with them.

Another option might be walled garden with approval process. That is that a user could only interact with people in their institution by default, but to make friends with a user from another institution it would need approving from their institutional administrator/staff. Obviously this would be rather complex and difficult to scale for big institutions, but I think the reasoning behind it is to allow cross-institution collaboration where this makes sense, without making mahara into the social network for the whole region (the question there is, who is going to monitor this?).

So we were thinking of 3 'levels' of institution interaction settings:

• Open (as now)
• Walled garden (can interact with everyone in your institution)
• Walled garden (can interact with everyone in your institution) with approval process for users in different institutions.

With regard to restrictions which apply to a user in multiple institutions, we had the same thought as you -  the most privileges you have in an institution wins. How to make this scale is another question!

But there are also the big caveats of non-insitution things like groups.. How does a walled garden control access to that? 

Dan 

13 October 2009, 21:37

Hi Dan,

The other thing we have been thinking about in terms of walled gardens is, allow these institutions to interact with those institutions only. So say you have institutions A, B, C, D, E, F:

• A can't see anyone
• B and C want to just see each other
• D, E and F haven't set any preference so they can all see each other - but they can't see A, B and C as they have their own walled gardens.

The approval process stuff.. I smell complexity that I think you're right about regarding scaling it. With two thousand students per institution, who is going to care when user X wants to be friends with user Y from another institution? It'll be a very unused function, I think. Feel free to correct that assumption though 

14 October 2009, 0:39

14 October 2009, 1:31

14 October 2009, 17:26

Hmm, having arbitrary groups of users in "walled gardens" which don't have a direct mapping to institutions really does add complexity, if it was an arbitrary list of  users which could cross institutions, you'd need a user to administer that walled garden (rather than say, the institution admin). There would also need to be a good way to decide who was in what garden, a simple way to add users and keep them in sync etc.

14 October 2009, 17:48

User bob was in institution a and b and because these plugins  are disabled in both his institutions, the wall block was unavailable for him, whilst the externalfeed and blog were still available because they were not blocked in both institutions.

Then we realised that sending a message to another user is not a plugin and so is this sort of approach overkill?

14 October 2009, 22:06

Well I don't think that the data model is a bad idea. It's a nice structured way to store enabled/disabled information on a per institution basis. I guess one thing it brings up is whether the admin sets it, or the institutional admin can. I can see circumstances where the site admin might not want the institution admins to set a plugin on and off. But I guess that's a lesser use case than the default, which would be to allow institution admins to do that themselves.

Despite it being overkill for you, I think upstream we'd be interested in it being implemented this way, plus adding a way for institutions to turn all plugins off of course. If this was too much work for you guys, then you could easily hack in a checkbox on the institution edit screen to control the wall (& messaging).

Messaging is interesting because it's not a plugin. I think whether you do plugins nicely or not, you're gonna need custom code for that..

We discussed walled gardens in IRC, and came up with a proof-of-concept data model for it. As discussed, this would be a lot of work to implement - however there's interest in this from more than just you guys. You might want to liase with Richard Wyles about this, he's talked on and off about us doing this for some time.