User Access Restrictions
14 Jun 2009I'm a big believer in the open culture movement. My work on open-source software and open content education materials should be demonstrative of that. However, I know that "open" isn't good all the time, and there are some legitimate places where openness is a bad thing and a few access restrictions are necessary. That said, I will say that organizations tend to go overboard in this department, not able to separate which restrictions are truly "necessary" and which only seem that way to people who don't know how liberating openness can be.
The work I am doing for WiTTIE is proving to be quite challenging because we are having to add lots of custom user access permission facilities to the wiki. The problem is that we are working together with classrooms from around the world, and teachers in different places are bound by different rules and laws and needs. Some teachers are going to need to prevent all public access to the materials that their kids write (even read access!), some will not. In all cases we are preventing non-users from editing, and we are preventing non-participants from getting accounts in the first place, so hopefully spam and evil nonsense will be completely non-existent.
The problem is that we are trying not only to use wikis for a particular educational experiment, but also to sell it as a viable teaching tool that teachers can rely on going forward. If we try to push a radical ideology in addition to a strange new software tool, we're likely to sell very few teachers on either. We have to take into account the needs of our target audience and let some bits of the ideology fall by the wayside. It's my hope that the continued successes of wiki platforms in promoting open collaboration will incrementally change the minds of people who demand closedness as the only path forward, but some people can be so entrenched in their processes and beliefs that such incremental changes will never happen.
MediaWiki, if you are willing to disable caching and a few extra services can provide a very robust platform to manage read and write access to pages based on a matrix of user groups versus namespaces. This is what I am calling course-grained control. Groups of users have certain permissions across an entire group of pages. All members of the group have the same sets of permissions to each page in the namespace, and this schema works very well in MediaWiki. The problem arises when we need more fine-grained controls, specifying that individual users have different rights from the rest of the group for particular pages.
Consider the case of where a student is tasked to perform a particular assignment without any collaborative assistance. You want to see exactly what the student can produce without relying on help or input from other students. In this case, you would want to make the page read-only but whitelist the particular student so he would be able to get around the permission for that one page. Or, consider the case where a teacher posts grades for completed assignments on the wiki, and only wants each student to be able to view their own. In that case we would make pages completely read restricted, but allow students to be whitelisted to view the pages that contain their particular grades only.
And because these kinds of permissions are going to change over the course of a semester, we need a decent interface for teachers to be able to set them. Notice that what is "decent" for a tech-savvy coder like myself is far different from a tech-n00b teacher in rural Africa, or India.
I've kicked around a few ideas for how to make pages secure using this kind of fine-grained mechanism. We're looking at a lot of existing user-access extensions now to get more ideas, and hopefully we can find one that does exactly what we need. I doubt it, but it is possible. What I suspect we are going to end up with is a whitelisting mechanism where pages in certain namespaces are locked down for zero access by default, but add a teacher-editable whitelist page to specify certain users are allowed to bypass those restrictions.
So if we have a namespace Permissions: that was only editable by teachers, it could pages for each page in other namespaces. So the permissions page for "User:Whiteknight/" would be at "Permissions:User:Whiteknight/" or even "User permissions:Whiteknight", etc. For ease we might just create a new database table entirely and use a special page Special:PageWhitelist to deal with our needs. Each page would then have a tab that points to the associated permissions interface. From there you would show the default access settings for all pages in the namespace plus a user-editable whitelist. I've been hoping to find a way to unify this fine-grained functionality with the existing page protection mechanism (since that gives us a per-page editing restriction), but I'm not sure it will be doable that way. I'll keep looking at that, and would be very grateful if somebody more knowledgable then myself could give some insight about it.
Jason is getting started with the feedback and peer-review extension, and Nick is starting to take a look at existing extensions to tackle these user access restrictions. We've also added a new member to the team, Michael, who is a student in Jen's class and will be helping primarily as a translator between teacher-speak and coder-speak. He'll also be helping to get requirements for our various components nailed down, because there is still a lot of wiggle in the specifications at this point. Once we get specifications nailed down I have high hopes that we will be able to find suitable solutions quickly.
This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.