[WG: Sakai QA] The access view, getUrl() methods in content hosting and URL encoding

[Stephen Marquard]

Hi all,

This is a heads-up about recent changes in the access servlet (CollectionAccessFormatter), getUrl() methods in Content Hosting Service, and URL encoding in tools.

In the beginning, the getUrl() methods in CHS returned a URL which was not a correct URL in that the collection or item ID was not escaped. c/f:

http://jira.sakaiproject.org/browse/KNL-213 

This meant that if a folder or filename contained either spaces or UTF8 characters, the URL returned for that would be invalid if used as-is (as these characters aren't allowed in URLs), e.g. c/f SAK-16564. As a result, a number of tools (but not all) escaped either spaces or the URL itself (e.g. SAK-17460).

CollectionAccessFormatter (the class which handles producing the HTML for a directory view of a content folder, e.g. /access/content/group/groupid/somefolder/) did not use the getUrl() method at all, but used the ID to form the URL. This led to breakage for any non-content item, e.g. a Citation list or Form, which have special URLs and handlers. The same problem affected rwiki.

In fixing KNL-213 to resolve KNL-332 (correct links to forms and citations), getUrl() and its variants for a ContentEntity now returns a valid URL. 

*** This means that URLs from these methods should no longer be escaped by tools which output them. ***

The process of fixing this in Kernel 1.1 / trunk has involved reversing the URL encoding in those tools which did escape URLs (principally Podcasts, Forums), and verifying that previously-broken tools are now fixed (e.g. Syllabus, Wiki). Some other cases (e.g. Attachments widget) behaved correctly before and are unaffected by the change.

These changes are tracked here:

http://jira.sakaiproject.org/browse/SAK-17459 

The only outstanding issue in trunk with kernel 1.1.0-beta04 is the FCK connector which looks like a simple fix. Everything else should now behave correctly wrt encoded URLs. This can be verified by uploading a file with spaces and UTF8 characters in it, and verifying that it can be downloaded correctly from all contexts where it could be referenced (e.g. as an attachment).

However, please note that for anyone looking at merging these changes to 2-6-x either in the Sakai branch or local branches, please note that it's an all-or-nothing proposition, i.e. the kernel changes in KNL-213 / KNL-332 must accompany the changes in the respective affected tools as identified in SAK-17459.

Lastly, CollectionAccessFormatter included support for 2 optional parameters, viz. basedir and sbasedir, intended to facilitate integration with file-pickers in editors by producing an alternate output format. As these now appear completely redundant with the use of special connectors by FCK and Sferyx, support for these has been removed (as they complicated the code considerably).

These changes resolve a significant number of long-standing JIRAs and hopefully will make encoding and i18n problems in URLs a thing of the past - thanks to everyone who contributed patches along the way.

Regards
Stephen