Upgrading Experience, from 2.7 to 2.9


On this confluence page, we will be sharing our experience gained during our upgrade from Sakai 2.7.2 to Sakai 2.9.1 at the University of Murcia - SPAIN (Universidad de Murcia http://www.um.es - https://aulavirtual.um.es). Our goal is to provide some context as to why we have made some changes to the Sakai’s code, that we think that can be useful for other institutions and deployments of Sakai. We will be sharing those features with the community as we move forward in our upgrading plans.

We also want to share our route map so that others facing the same need for upgrade can use them, reduce their time and learn from it. At the same time, we would love to hear from you suggestions about tasks that might also be included in our upgrading process, or your advice for facing those tasks.

This page will be made by the technical staff and it is mainly focused on their concerns around the upgrade process. We also intend to mention all the other staff related to this process and the tasks concerned to them.



 


Upgrading Plan

After Sakai released its 2.9 version, we set a clear goal for our TEAM, move our deployed version (2.7.2) to the latest one. However, the first step is to write a simple plan, unfortunately for us and everyone in the Sakai community, Sakai upgrades do not arrives by clicking a 'magic button'. The main task concerns technical aspects, we have developed a lot of custom tools and have also changed some pieces of the original Sakai code. But, there are other tasks involved, so we are going to mention all of them at this master plan.

Evaluating Sakai 2.9

What do we really know about the new version? This is our first goal. We weren’t too close to the release of this new version, so we’ll have to review all the new things that comes with it, new properties, new features, new look, and so on.

Look & Feel

This is probably one of the most desired changes from the new version. The neoportal skin modifies some aspects of the general usage at the portal interface and we have to adapt our custom skin to the new portal look and feel. We hope that everybody gets happy with the new changes.

New Features

We also have to deeply understand all the new features and properties in order to configure our new environment right. We will need to modify our custom help and tutorial pages. The first thing is to have a look at the release notes confluence page. We are planning to make a custom release note page to notify users about the new functionalities.

We use a wordpress site for our online help, providing our users with short videos and short lessons about every tool that they have available. For the upgrade, We have used that same platform to communicate the new changes. We have made some screenshots with comments to show exactly what's new. Feel free to check them out!!

Major Code Changes

Because we had made custom changes to the original code of Sakai, we could be affected by the new code changes comming in the 2.9 version, not only caused by specific patches in particular tools but also because of the particular way of working that we have with the original code (see Deconstructing Sakai).

How different we are?

Talking about patches we have to collect all the changes made in the original code and classify them. Some changes could be applied to trunk and shared with the community, others maight already be included in Sakai and others might be incompatible with new version. This task give us an idea of the amount of code that we have to rewrite for the new version.

Why are we different?

In the other hand, we are not that different from the rest of institutions, most of the patches that we made solve general problems or add interesting features. Maybe this could be useful for the community. In our first deployment (2010) we were focused on the migration from our homegrown environment, a massive task, and we had no time to spend in contributing our work back to the community, but now we want to do it.

Developing Process. (Mar-Apr, 13)

We created a custom infrastructure to develop with Sakai (see Deconstructing Sakai), so we have to adjust this to the new version. Also we have to rewrite all the necessary patches in order to work in the new version. We hope that our custom tools won’t need major changes to work, as well as contrib tools that we use. All the patches that we considered interesting are going to be contributed, following the necessary steps, jira, cle team call,...

Testing Process. (Apr-May,13)

During the developing process we also do some tests, in order to check that every patch works right, but this is a key task, and we have to do different test with different scenarios. We are going to use a snapshot of our production database to perform functional testing, and this phase are going to spend a significant amount of time. Also we have to test database upgrade scripts.

Load testing

Checking the mailing lists you will discover some performance issues concerning to the new release (KNL-1011), and that’s the main reason to highly checking performance in our upgrade process. Apparently this issues are already fixed but not included in the 2.9 branch, so far. The next tag for this release could be the definitive tag to install for us.

Information Process.(?,13)

We want to involve in this process, as much as possible, all our Sakai’s users. Keep them informed about the new features, tools, possibilities, and the schedule will be positive and avoid later rejections about the change into the new version. We like to make a communication plan, something similar Duke's transition communication plan, countdown timers are fun (big grin)!

The Change. (Before Oct,13)

We don’t have a definitive date to make the final change, so far. It depends on the progress of all the tasks described in this plan. The deadline is 1st Oct. 2013, but we are going to work to make the change as soon as possible.

We are out!!! 31st of July 2013. 2.9.2 is ready at University of Murcia.

 

 


Deconstructing Sakai

In order to understand the reasons for some of the changes that we are going to make in the code you need to get some background of our work. We deployed Sakai from source code at tag 2.7.1, also checking out kernel and indie tools code from the respective tags.

We had to develop some custom tools, and we decided to do it with JSF framework, but Sakai included JSF 1.1, and we wanted to use at least JSF 1.2, so we patched Sakai to get this. Most of our custom tools are developed using JSF 1.2, so we also created a maven archetype to create a new tool.

We have a medium size development team so we need to use some infrastructure to facilitate the daily work, and avoid errors as much as possible. The key tool is Jenkins CI. Developers focus in trunk and Jenkins do the dirty job, compile all the code, merge between branches, deploy to concrete servers, perform unit tests, and so on.

During a year we were working with this infrastructure, modifying Sakai sometimes, and mainly modifying our custom tools, or adding contrib or new custom ones. Beginning of 2012, it’s time for a minor upgrade from 2.7.1 to 2.7.2. We realized that we have worked primarily in our code, but developers and specially Jenkins have to manage a big amount of code that never changes. We missed a less expensive way to change the code, and we thought up one way. The idea was to create a sakai-deploy, similar to kernel-deploy or core-deploy, and obviously an assembly. Once you have this you only need three pom files to deploy Sakai.

But, how to make a change in the code now? You can checkout the maven module you want to change, for example kernel-util. Then make the change and compile, so you have the modified artifact in our local maven repository. And now the trick, we developed a custom maven deploy plugin, based in sakai maven plugin, that look for modules changed locally and replaced them in more complex artifact like war or assembly artifacts, before deploy in tomcat.

During this process we noticed that we could extend this mechanism to all Sakai code. We download binary distribution and create an assembly artifact with the original code of Sakai, and a simple pom to deploy it. With our maven plugin we can detect the artifacts that we changed and replace them by the modified ones.

Role Permissions and Templates

Since the very beginning we have customized almost everything in Sakai to adapt it to our institutional needs. One of the first customizations was the creation of custom site types and custom roles with our own set of permissions. This help us to get a deep knowledge on how Sakai works and brings us full flexibility. It was actually a simple thing to do because we basically studied how Sakai was doing that and then adapted it to our needs. One of the first problems that we faced was to share all that customization with the development team so that each member could deploy (in the easiest way) all those sites, roles and permissions in their local environment.

We came out with the idea of using xml files
(realms.xml, sitiosplantilla.xml) + a quarz job (UMUINIT) to populate Sakai with all that information. At first, we only had 6-8 different site types and maybe 6-9 different roles. The file realms.xml was used to set all site.template and group.template with their roles and permissions. After a couple of years, this file was getting bigger and bigger and therefore, close to 'unmanageable'. Last month, realm.xml had 23.000 lines. Here is an example of the xml structure:



With the migration, we took the opportunity to ' ReThink ' how could we improve this process. 

 

You could check this HTML to see the amount of roles, permissions and templates that we have, and we have to manage.

Fortunatelly we created some pieces of software that reduces the complexity and let us manage this in a simple way. This pieces helps us to reduce errors in the final XML document (realms.xml) and bring up some logical to the permission and rol management.

Now we can add a permission easily by adding in the adecuate permission group, or we can add a new realm, by adding the adecuate roles and permission groups, this save us from many many errors y final result.

 

 

 

 


Final Conclusions

Migration tasks are always a nightmare but specially when you forgot about the community and you start to make changes in the source code without any control (You feel like it is your own source code). When the migration/upgrade comes, you are not only migrating a Sakai installation, you must have in mind so many things that could affect you in different ways, and all those problems are only yours...

This migration process has helped us to confirm that our thoughts were right, every change that we need to make in the source code should be contributed to the community. The contributing process will help you in many ways, first you can discover different ways to get your final goal, the way you found to do the tasks could be improved and finally you won't worry about how to fix it in the next migration. This is the way that we have been working during this migration process and the response from the community has been very positive, a lot of our improvements are now included and ready for the next major release of Sakai.

Of course, we have more improvements to contribute, but we know now how to do it in a proper way and we feel more confortable with Sakai, we are not only using but driving Sakai right now.

The conclusions are very positive, and we need to let this feeling flow to the rest of our University and especially to our Sakai users. They need to know that when they are letting us know their suggestions they are improving the global LMS, not only our LMS.

This is the beginning of another journey, we have worked really hard to connect ourselves with the community as much as possible and we want to keep this connection alive. Global thinking is not and option, is a compromise even when you have full access to source code.

Follow our experience upgrading to Sakai 10 !!

Check out our experience with the Sakai Community & meet the Community Cube! EuroSakai 2013

Mission accomplished!!

 

 


Upgrade's Logbook (Feb)

Logbook (15/Feb/13). Changes we made.

Making a diff between the original 2.7.2 tag and our code, I collected all the changes made in the code, and at the same time classified them. This could be a measure of the work that we will have to do in the next months, and also the value that we could return to the community. The complete list has around 30 patches that we could contribute to the community.

Logbook (22/Feb/13). Sakai assembly.

I started to work in update our infrastructure to the new version. Sakai code structure has changed since 2.7. Now it uses sonatype maven repo, and not all the tagged artifacts are present on this repo, only kernel and indie ones. Because of this situation I have to download and compile part of the Sakai code to create the sakai assembly.

At the same time I see some messages on the list asking for a -all tag, and following this conversation I realized that assembly are going to disappear, so I have to change the way we work.

Analyzing the situation, I realized that our maven deploy plugin is able to manage zip assembly artifact no matter the big they are, so, why don’t we use the zip binary version? I think, this could work, and really it does.

We sent a message to the list when we realized that something was wrong in the 2.9.1 release, and this problem affected the binary version too, some 2.9.0 jars were deployed inside 2.9.1 binary distribution. This has a terrible effect in our way of work, so probably we need to change the binary, or wait for the 2.9.2 version.

Logbook (25/Feb/13). Sakai QA Server at University of Murcia.

During the next couple of months we are going to be listing jiras in this page that we already have running in our 2.7.2 version. Its not our intention that all this patches get into trunk right away, we believe that they should go through the QA process but we also believe that we should bring them up to life gradually. We have requested our instituion the infraestructure needed to set up a QA server in order to improve this process. We hope to get a quick answer and will inform when that happens.

We also want to set up a jenkins server to build the trunk and maybe the 2.9.x branch with all the patches that we developed, in order to contribute the code as safe as possible. Break the build doesn't rock (smile)

With this infraestructure the community will be able to test all the patches before getting them into trunk.

Good news!!. The servers are ready !! (18/Mar/2013)

TRUNK Nightly Server: http://sakai-trunk.atica.um.es/

2.9.x Branch Nightly Server: http://sakai-test.atica.um.es/

A Jenkins server update and build the code every day, and the database is completely removed every monday. Check the main welcome page of the server to know more about the set of tools and patches installed in each one.

Upgrade's Logbook (Mar)

Logbook (05/Mar/13). Sakai Login Event.

Some of our custom tools are located at MyWorkspace and also the permissions that allow to use this tools could change across time. So, we have to modify permissions in the user's myWorkspace after user login. During the last 2 years we were using a web filter located at the Sakai Login tool, but now we change this wrong way of work and we developed a EventTracking Observer. This is the right way of do it, and also allow us to change permissions even we use Become User tool.

Logbook (05/Mar/13). Sakai JSF 1.2 Tools.

Long time ago we commented in  SAK-20086 , mostly because we have been using jsf 1.2 in our custom Sakai tools since the beginning. Today, we have updated the patch, actually is the same because it seems that nothing has changed in the jsf project. We divided the patch into two different ones:

    • The first allows the use of jsf 1.2 components with facelets (xhtml and jspx extensions only jsp was supported).
    • The second patch (PrimeFaces) adds facet head to the jsf sakai view tag in order to allow the inclusion of the primefaces tag in the head section of the resulting page.
    • Indivisible patch, you need to add head facet to the sakai:view tag in order to get jsf 2 components working.

Updated : After a lot of work I realized that SakaiViewHandler has some kind of problem with JSF2 and cause conflicts with navigation in a Sakai JSF2 Tool. On the other hand the sakai:view jsf component is too intrusive. The patch that adds head facet to the component allow working with other faces libraries, but requires to duplicate the head tag in the resulting page being this the only way to move on without rewriting all the sakai jsf components.

Finally I found a solution. Since JSF 1.2 the recomended way to create a custom ViewHandler is extends ViewHandlerWrapper. Extending ViewHandler works in JSF 1.1 and 1.2, but not in JSF 2.0, and extending ViewHandlerWrapper does not work for JSF 1.1. So, I upload a patch that adds SakaiViewHandlerWrapper class and generate jsf-app artifact and jsf-app-jsf2 artifact. The first artifact uses the SakaiViewHandler and the classifier artifact uses the SakaiViewHandlerWrapper. Nothing changes for tools like messageforums or samigo.

<dependency>
	<groupId>org.sakaiproject.jsf</groupId>
	<artifactId>jsf-app</artifactId>
	<version>${sakai.jsf.version}</version>
</dependency>

If you want to create a new tool with JSF 1.2 or JSF 2.0 use the classifier, and exclude jsf 1.1 that is included by default with jsf-app.

<dependency>
	<groupId>org.sakaiproject.jsf</groupId>
	<artifactId>jsf-app</artifactId>
	<version>${sakai.jsf.version}</version>
	<classifier>jsf2</classifier>
	<exclusions>
		<exclusion>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-api</artifactId>
		</exclusion>
		<exclusion>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-impl</artifactId>
		</exclusion>
	</exclusions>
</dependency>

Please test this out in our QA servers : http://sakai-test.atica.um.es/portal (2.9.x) http://sakai-trunk.atica.um.es/portal (trunk)

  1. Register and create a site. 
  2. Then, add KickRoster (JSF 1.2), KickRoster2 (JSF2 RichFaces) and KickRoster3 (JSF2 PrimeFaces) tools.
  3. It works !!
  4. And samigo, msgcntr, calendar-summary all the current JSF 1.1 work too !!
  5. Check KickRoster source code trunk and 2.9.x.

 

Logbook (05/Mar/13). Sakai Input Rich Text Issue.

If you reply a message with < character on its content followed by a letter, you loose the text after the symbol. This is because sakai input rich text jsf component doesn't escape this character, and CKEditor parses it as an unknown html tag. If you type an space after < you don't have this problem. It is a really simple patch and we added to SAK-23313.

Sam Ottenhoff commented that maybe other characters could cause problems, and actually it does. The & character causes problems too. So we have to change the patch to manage this character too.

Logbook (06/Mar/13). Sakai Email API Ability to add attachments on the fly.

Now if you want to use EmailService to send a message with attachments, you need to create a java.io.File object, but actually Mail API needs a DataSource, so Sakai builds a FileDataSource with the File object. We change the Attach API so you now can create a Attach object using a DataSource instead of a File, giving you the ability of adding attachments on the fly, and also avoiding the Sakai transformation from File to FileDataSource.

Wow!, today this patch is in trunk. Thanks Aaron !

Logbook (06/Mar/13). Sakai Managing tool categories as properties.

If you want to add a new category (site type) to a tool, you have to change all the /tools/toolid.xml files. You could have all those files in sakai.home rather than distributed across webapps, but you still have to change a lot of files, and also, in the long term, you could be affected if changes are made to the original files since you are using now a modified copy of them. We think that most people just modify those files for adding new categories but those files include other things like tool title, function require... 

Therefore, It would be good to have them work independently. If you'll be able to add a property like tool.categories.toolid=category1,category2,category3,.... you could manage all tool categories within the same file, avoiding the copy of the entire toolId.xml file.


Upgrade's Logbook (Apr)

Logbook (08/Apr/13). Assignments downloading spreadsheet in a site with brackets in its title fails.

Here the steps to reproduce the error: 

    1. Create a site with brackets in its name: My [Site] 
    2. Go to assigments and create one a make a submission. 
    3. Try to download submissions as spreadsheet. 

If you take a look at the code in  https://source.sakaiproject.org/svn/assignment/trunk/assignment-impl/impl/src/java/org/sakaiproject/assignment/impl/BaseAssignmentService.java  you will see this: 

	// a tab title in a workbook have a maximum length of 31 chars. 
	// otherwise an Exception will been thrown "Sheet name cannot be blank, greater than 31 chars, or contain any of /\*?[]" 
	// we truncate it if it's too long 
	String sheetTitle = siteTitle; 
	int siteTitleLength = sheetTitle.length(); 
	if (siteTitleLength > 31) { 
		M_log.info(this + " Site title is too long (" + siteTitleLength + " chars) truncating it down to 31 chars!"); 
		sheetTitle = sheetTitle.substring(0, 31); 
	} 
	HSSFSheet sheet = wb.createSheet(Validator.escapeZipEntry(sheetTitle)); 


But escapeZipEntry method obviously filters characters not valid for a ZipEntry, but not for a Sheet Title. See  https://source.sakaiproject.org/svn/kernel/trunk/kernel-util/src/main/java/org/sakaiproject/util/Validator.java  

	protected static final String INVALID_CHARS_IN_ZIP_ENTRY = "/\\%:*?'\""; 
 
	/**
	 * Return a string based on id that is fully escaped to create a zip entry
	 * 
	 * @param id
	 *        The string to escape.
	 * @return id fully escaped to create a zip entry
	 */
	public static String escapeZipEntry(String id)
	{
		if (id == null) return "";
		try
		{
			StringBuilder buf = new StringBuilder();
			for (int i = 0; i < id.length(); i++)
			{
				char c = id.charAt(i);
				if (INVALID_CHARS_IN_ZIP_ENTRY.indexOf(c) != -1)
				{
					buf.append('_');
				}
				else
				{
					buf.append(c);
				}
			}

			String rv = buf.toString();
			return rv;
		}
		catch (Exception e)
		{
			M_log.warn("Validator.escapeZipEntry: ", e);
			return "";
		}

	} // escapeZipEntry

So, probably a new method escapeSheetTitle is needed, but this will be in another JIRA for kernel.

I'm testing the patch in our QA server.

David suggested a better solution use the poi utility method and that's right !!

Logbook (11/Apr/13). Sakai titleEditableSiteType property not properly managed.

If you have 3 site types in Sakai, course, project and other, and set the property value to:  titleEditableSiteType=project 
You will be able to edit the title of every site of type project and other, because of this code at  https://source.sakaiproject.org/svn//site-manage/trunk/site-manage-tool/tool/src/java/org/sakaiproject/site/tool/SiteAction.java  

private boolean siteTitleEditable(SessionState state, String site_type) { 
	return site_type != null 
		&& (!site_type.equals((String) state.getAttribute(STATE_COURSE_SITE_TYPE)) 
			|| (state.getAttribute(TITLE_EDITABLE_SITE_TYPE) != null 
				&& ((List) state.getAttribute(TITLE_EDITABLE_SITE_TYPE)).contains(site_type))); 
} 

I think the correct code should be this: 

private boolean siteTitleEditable(SessionState state, String site_type) { 
	return site_type != null 
		&& ((state.getAttribute(TITLE_EDITABLE_SITE_TYPE) != null 
			&& ((List) state.getAttribute(TITLE_EDITABLE_SITE_TYPE)).contains(site_type))); 
}

The current installations could be affected because of the change. For example, 

sakai.propertieseffect noweffect with patch applied
titleEditableSiteType=projectYou can edit every site title of any type different from course (even you only specified project type). You can edit site title only for project sites.
titleEditableSiteType=You can edit every site title of any type different from course (even you didn't specified anyone).You can not edit site title for any site.

  This could be solved adding a new property, titleNotEditableSiteType with course as a default value.  

private boolean siteTitleEditable(SessionState state, String site_type) { 
		return site_type != null 
				&& ((state.getAttribute(TITLE_NOT_EDITABLE_SITE_TYPE) != null 
					&& !((List) state.getAttribute(TITLE_NOT_EDITABLE_SITE_TYPE)).contains(site_type)))
				&& ((state.getAttribute(TITLE_EDITABLE_SITE_TYPE) != null 
							&& ((List) state.getAttribute(TITLE_EDITABLE_SITE_TYPE)).contains(site_type)));
}

I'm doing some testing on our trunk server.

Logbook (16/Apr/13). Section Info: Allow read only sections (by category) with MANUAL_MANDATORY configuration.

University of Murcia needs to allow instructors to create and manage sections by themselfs, but there are some sections comming from a provider and we want these sections to be read only. This could be done with a new property.

# Read only category codes
readOnlySectionCategories=01.lct,02.lab,...

With this configuration an Instructor can create and manage sections of all categories except Official and Laboratory. Official and Laboratory sections appears to be read only, not edit, assign or remove option for them.

I'm doing some testing on our trunk server.

Upgrade's Logbook (May)

Logbook (02/May/13). Flexible way to customize cut method for site title in tabs.

The property site.title.maxlength allow long site titles fix the UI by cutting the end of the title in tabs.

We've got many long site titles and very similar, for example, "This is the subject part I", "This is the subject part II". In these cases both cutted titles appears to be the same "This is the subj...". We want a more flexible way to do it. With 2 new properties:

#This is the current property. Default 25
site.title.maxlength=12
#customize the cut method. Default 100:0 (X:Y, X% of site.title.maxlength at the beginning, and Y% of site.title.maxlength at the end)
site.title.cut.method=50:50
#customize the separator string. Default ...
site.title.cut.separator=[...]

Now if you choose 50:50 and [...], the above example, will get something like "This is[...]part I" and "This is[...]part II".

UPDATE: After a lot of testing I forget to apply the same method to cut titles in preference's page. I've made an emergency patch that uses the same method by copying and pasting it, but now that this method is neede in multiple locations the best way to do it is to add a new methos to kernel Site API, to get an abbreviated Site Title.

Logbook (08/May/13). Database upgrade the final Oracle script.

Today I've created a script for applying the changes in our database to convert Sakai from 2.7.2 to 2.9.1 (and soon 2.9.2). And here is the result. The script starts with an oracle procedure to remove duplicates described in SAM-775. Then is safe to run until the end. Reviewing the script I change several things.

The original script removes SAKAI_EVENT and SAKAI_SESSION table due to KNL-735. This could be a disaster if you are planning to audit data, of course you have to purge this data, but I prefer to keep data in another table rather than remove them. So I replaced the delete sentence with alter table sakai_session rename to bckup, and create a new table with the same structure and new types for date columns.

Also I like to get data separated from indexes and lob data (using different tablespaces), so I add tablespace info in the adecuate sentences. In the other hand we don't need to modify permissions across sakai templates because we have our own templates and we use umusync to distribute across existing sites.

Logbook (20/May/13). Subsite tooltip doesn't shows the full title of the child site.

This is a trivial bug, someone forget that site title can be shorted and you have to use the full version in tooltips.

Logbook (27/May/13). Top login false not properly translated.

I don't know if this is on purpose, but if you are using top.login=false with xlogin.enabled and you don't set xlogin.text property you will see a {4loginMessage2} text at the top of the gateway portal.

Logbook (28/May/13). Javascript error with brackets in short description.

If you type a short description with a special character for jquery you will get a javascript error in site info's (More..) link.

Logbook (28/May/13). Configurable import options in site info.

We need to disable some import options of the site info's import from site tool. If there is a property like: site.info.import.options.disabled we can do it.

Logbook (30/May/13). S2U Special features.

We developed some patches as a group in collaboration with other spanish universities, and we want to add to the Sakai core for future releases.

Allow instructor to upload resources to multiple dropbox folders.

Allow group submissions in assignments. We develop a different solution but we will adopt this solution.

Logbook (31/May/13). NeoPortal dropdown tools not honoring permissions.

We use to add tools to the workspace and then let the portal to show or hide according to the user's permissions, but it seems doesn't work with drop down neoportal menus.

Upgrade's Logbook (Jun)

Logbook (06/Jun/13). Portal more site view incorrect display.

When you set the portal.use.dhtml.more property to false, you aren't able to see any button in the top corner of the more site view window.

In relation to that you have to control the add new site permission in the top dropdown user menu too.

Logbook (10/Jun/13). DF/ Double clicking buttons produces WSOD.

Double clicking buttons produces side effects inside msgcntr code, duplicate messages, log errors, etc. It's easy to control this double clicking, is not a final solution because you could cause all those side effects bypassig client controls, but reduces a lot of them in a normal use.

Logbook (10/Jun/13). Javascript error in messages about missing messages.js.

This problem affects version 3.0.x and is fixed for 3.1.x, you have to add messages.js by yourself if you want to avoid this error in Sakai 2.9.x.

Logbook (18/Jun/13). Recent Announcements in MyWorkspace fail to show the Site field.

I've solved this problem by adding the line context.put("showMessagesList2", showMessagesList.iterator()); but I think there is another problem with sort function when sites becomes visible.

That's right, there is a problem but is not related with Site column is related to SAK-8005. If you activate the reorder option, the default order in synoptic announcements is not set to "by date", so you can loose messages due to pagination.

Logbook (26/Jun/13). Groups you are member of in Site Info is missing.

Since SAK-21272 Site Info only displays groups created in its Manage Groups option, so you can't see Site's Sections. We think this info is really useful for our Sites, because we populate sections with our custom course management implementation.

Logbook (28/Jun/13). New web content tool instructions are not properly translated.

The new web content tool has some work TODO with I18N.

Upgrade's Logbook (Jul)

Logbook (04/Jul/13). Running Clog in Oracle

We decided to add Clog as a new tool in Sakai 2.9, but we found some problems trying to run it in Oracle and with a custom skin.

Logbook (05/Jul/13). Error in average presence time per visit.

We noticed that the results shown in Site Stats as average presence time per visit were so big, and finally I found the reason.

Logbook (11/Jul/13). Section Info Assign TAs menu not properly displayed.

We noticed that the main menubar lose its style in Assign TAs option. The reason is an unnecesary h:panelGroup.

Logbook (12/Jul/13). Number format L10N fails in assignments related to gradebook items.

L10N Bug in assignments associated with gradebook entries.

Logbook (18/Jul/13). FMath plugin should store generated images in a configurable subfolder.

This jira was commented in the last spanish community meeting and I remember that I want to apply it to our instance, sounds resonable.

After a little research we decided to create a different patch that consider fmath files as attachments.

Logbook (24/Jul/13). Avoid problems in WebDav connections to myworkspace resources if eid contains @.

Some Linux WebDav clients use the @ as an special character so when it appears in the WebDav URL you can get problems to connect.

Logbook (24/Jul/13). RefreshAuthzGroup method saves active and provider as true/false instead of 1/0.

This is a rare thing, that I detected because I use this method in some custom code, but I don't know how to reproduce it in blue Sakai. Anyway the error is pretty obvious.

Logbook (31/Jul/13). CourseManagementGroupProvider error in getUserRolesForGroup.

This is another little change that involves a big error. Resolution order is not used by all Sakai implementors but if you know what it is, take care of this bug.