Glenn Golden

Sites are the definition of the different visitable areas of the system. Realms are packages of security grants. Realms are implementation of the Security service, even though it's a service itself. As such, it's not to be relied upon, and likely to be changed or removed once we move to the Sakai security service. Meanwhile, you do need to use it to grant users abilities to access Sites and other resources in Sakai.

Whether a user can create sites is controlled by the site.add permission in their realm. Their realm is determined by their user type - the type on their account. You can see the type using the admin User editor and edit the account. There is a type field there. User's with no type get the realm !user.template. Users with a particular type get the realm !user.template.<type> if there is a realm for their type, else they get !user.template.

There were some changes made for 1.5 in what users get as a default. Earlier versions had the default set such that users created with the New Account tool on the Gateway did not have site.add permission. Their account type had to be set to maintain in order to get the ability to create new sites.

1.5 changes that so that the New Account tool creates an account of type registered, and there is a !user.template.registered realm that has site.add checked on. So users self-creating accounts get by default the ability to create new sites in 1.5. New users created by virtue of adding them to a site using Add Participants in Site Info are created with type guest, and they do not by default have the ability to create sites.

You can create a user - either with the New Account or Admin User tool - and make sure or set the type on the account to registered, and then make sure site.add is checked on in the !user.template.registered realm. That user should then see the New... button in their My Workspace Worksite Setup tool's toolbar, and be able to create new sites. Though any user created with the New Account tool should be created with type registered automatically, and should be able to add new sites.

If you add users using the Admin tool, you just need to put in the appropriate type to either allow or prevent them from having the ability to create new sites.

When creating sites, you should use worksite setup rather than the admin sites tool in general. That prevents the problem of entering something incorrectly in the role to assign joiners field. That role has to be one that is actually in the site (access or maintain for Sakai OOTB). When you use Worksite Setup, the role to assign joiners is selected from a dropdown that forces a correct entry.

The users type must also match types known to the system (e.g., there is a cooresponding !user.template.<type> realm. Otherwise, the user gets the !user.template realm (the default realm to use for accounts with a type that doesn't have a cooresponding !user.template.<type>), which doesn't have site.add, so such a user can't create new worksites.

Update for Sakai 2.1

SAK-2132 work includes some changes in the Site and Realm APIs. Edits and Locking are gone. Realm is renamed AuthzGroup (authorization group).

Any code in the svn/trunk/sakai has been changed to reflect this. If you have code that deals with these APIs, take a good look at the new APIs. It should be pretty clear what to do, and if not, if you have any questions at all, pleas feel free to email me.

Also, if you see anything strange with site or realm related functions, or permissions functions, let me know, as there may be some rough edges to the work still.

Make sure you get fresh new Sakai code with an svn update!

Notes:

If you have a "RealmProvider", it's now a "GroupProvider" - check the new API. Register the component as "org.sakaiproject.service.legacy.authzGroup.GroupProvider"

If you work with AuthzGroups or Sites, there's no editSite() or editAuthzGroup() call, just getSite() and getAuthzGroup(). You don't have to worry about what you do to clean these up, there's no cancel () call anymore. If you want to make changes, go ahead. If you are ready to make those changes stick, call the service save() method. save() will throw PermissionException, and get() will not - so you might want to call an allowUpdate() method up front to make sure the end user has permission.

Key term changes with Realm, um, I mean AuthzGroup:

Was	Becomes
Realm	AuthzGroup
Role	(unchanged)
Grant	Member
unlock	isAllowed

The term changes have no functional changes to the service.

"realm" is still used in the table and field names, and in the permissions. Might or might not change this, as it requires a db conversion.