Monthly Archives: September 2006

Open Letter – About the “Roadblock People”

This is a letter to anyone who feels that the “Central Sakai People” – Chuck, Glenn and Lance as examples – are roadblocks to progress – and those people who keep harping on this in public and private mail.
I wrote this a few weeks back and then left it in drafts – to let myself cool down and and re-read this before blogging.
Usually the mail goes something like this: You central people are such a bunch of roadblocks – could you do X for me?

Continue reading →

Sakai Status Update

Well it is the end of summer, and then end of Integration week for Sakai 2.3 – probably a good time for a status report.
Focus on User Delight
With the 2.2 and 2.3 releases, Sakai’s framework is pretty stable. There is a lot of innovation in the area of tools going on around the world and we can have some time to take a breath and work on the “user delight” aspects of Sakai. I am working to increasingly put the focus of our thinking on the uses and users of Sakai.
The requirements effort has helped to communicate the “will of the community” to our volunteer development team – in 2.3 (8 weeks of development) there are a number of areas of the requirements that were addressed. As we move toward 2.4, we need to revisit the requirements and make sure that the will of the community is well represented in the requirements so that developers can address many of these requirements over the next four months as we prepare Sakai 2.4. Mark Norton has been retained to lead and facilitate the requirements process.
I truly enjoyed my visit to Lubeck University and the EU Sakai days. they produced video summaries of the meetings:
http://www.oncampus.de/index.php?id=819&L=1
From the discussions at the meetings, it is clear that Europe will bring many new ideas to how we all will use Sakai to teach and learn. The Bologna process:
http://ec.europa.eu/education/policies/educ/bologna/bologna_en.html
may have a significant impact on the need to evolve the technology used in teaching and learning across Europe to meet these new EU requirements.
In my hobby as film maker, I am increasingly looking for “end user” Sakai stories to mix in with my Sakai developer stories. My first video in this new series is from Roskilde University.
http://www.dr-chuck.com/media.php?id=65
It focuses on how Sakai is used in and out of the classroom in a database class at Roskilde University taught by Henrik Bulskov.

Continue reading →

Protal Improvement

We have a bunch of requirements about “saving state across navigation”
Legacy tools should not save state
http://bugs.sakaiproject.org/jira/browse/REQ-285
Sakai remembers state – optional?
http://bugs.sakaiproject.org/jira/browse/SAK-737
Sakai Saving State – Moving between tools and within pages of a tool should behave conistently for users.
http://bugs.sakaiproject.org/jira/browse/REQ-37
Basically the use case is simple – every time you move between tools or between sites, the tool that you “come back to” needs to be at its initial screen.
In Sakai 2.2 – when you “come back” you are brought back to where you left and the tool is in the state you left it.
As an example:
Go to resources – press the Add button – Go to Home – Go Back to Resources – what do you see?
In the state saving approach – you are at the Add screen – in the state clearing approach you are at the top of the resources hierarchy as if you pressed Resources for the first time.

Continue reading →

How to make an All Hands Group in Sakai

Welcome to the experimental All Hands provider.
The goal of this code is to allow the creation of Sites in Sakai in which
all users are automatically added.
The basic idea is to make an external group provider id called “sakai.allhands” and then either produce a GroupProvider that indicates that all users are members of that group or add the code to an existing group provider.
If you have an existing GroupProvider, simply add the following line of code:
public Map getGroupRolesForUser(String userId)
{
Map rv = new HashMap();
rv.put(“sakai.allhands”,”access”); // Add this line
return rv;
}
If you do not currently ave a GroupProvider, use the AllHandsGroupProvider provided herein.
To enable this group provider, simply edit the file
component/src/webapp/WEB-INF/components.xml
And add a bean entry as follows. Redeploy your Sakai and Viola!






There are print statements in the code so you can be confident of that is happening. Remove those statements before you go to production.
HOW TO USE THIS
Make a new site. Either Setup or WorkSite Setup can be used.
Log in as Admin. Use the Sites Tool to find the site you just added. Grab the site ID using copy.
Go to the realm’s tool and past in the site ID and press “search” you will find the
realm associated with the site.
Click on the realm – In the field “Provider Id” Enter “sakai.allhands” (no quotes) and save.
Now as people are logged in they get added to this site as “access”. If you change someone to maintain – they keep maintain.
WHY THIS WORKS?
When the user logs in, as part of their login the provider method
getGroupRolesForUser(String userId)
The real question being asked here is “For this user, what is the list of Provider IDs does this person belong to and what roles does that user have for each ID”. We indicate that “for all the sites with sakai.allhands the current user deserves access”. So authzGroups above us does magic SQL to make this so it looks for all of the sites with the provider ID “sakai.allhands” and simply pokes the user into those sites.
Look in this file:
authz-impl/impl/src/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java
Line 1554 to see the fun:
// for each realm that has a provider in the map, and does not have a grant for the user,
// add the active provided grant with the map’s role.
/Chuck
Sat Sep 9 00:34:37 CEST 2006

Continue reading →