On an Alfresco upgrade project I was working on recently, I faced an interesting issue where post upgrade, one of my custom Share action wasn’t working anymore. This action was used to create folder links for use on an external interface. When applied on a document, it would create a link to the parent folder for example and when applied on a folder, it would link to itself. Generated link could then be used from outside of Alfresco.

I created this custom action when I started working with Alfresco almost 10 years ago and I didn’t touch the source code since then, it always worked. Therefore, I was a little bit surprised when the action didn’t work anymore (the link would always redirect to the root of the Repository [/Company Home]) after the latest upgrade. The action is a simple JavaScript piece of code deployed as an AMP on the Share war file:

$ cat $ALF_HOME/tomcat/webapps/share/components/documentlibrary/folderlink.js
(function() {
  YAHOO.Bubbling.fire("registerAction", {
    actionName: "onActionFolderLink",
    fn: function dbiservices_onActionFolderLink(record) {
      var viewID = record.actionGroupId;
      var path = record.webdavUrl.replace('/webdav', '');
      ...

 

On this code, the “viewID” is used to know on which page and on which element is this action triggered. Possible values can be “folder-browse” (applied on a folder when you browse the repository), “document-browse” (applied on a document when you browse the repository) or “document-details” (applied on a document when viewing the details/preview of this document) for example. The second JavaScript variable “path” is supposed to be the path of the Alfresco Node. I used this “webdavUrl” when I created this method because I found that to be a simple way to retrieve the path, since you can use “record.displayName” to retrieve the name of the Node but you cannot use “record.displayPath” to retrieve its path (look at the end of this post for alternatives).

When trying to debug the issue, I used the JavaScript Console on the Share UI but my piece of code was working and giving me the correct outcome (using “document” instead of “record“). While looking further into the code, the issue was really that “record.webdavUrl” didn’t return anything when executed as part of the custom action while it was working properly on the JavaScript Console.

I couldn’t find anything on Alfresco side that would explain a different behavior between the two versions of Alfresco so I looked into the configuration instead (alfresco-global.properties) and saw that on the new server, the WebDAV was disabled. This was most probably done as part of a best practice, to disable whatever isn’t used. So, I tried to re-enable the WebDAV:

$ grep webdav $ALF_HOME/tomcat/shared/classes/alfresco-global.properties
webdav.enabled=true
system.webdav.servlet.enabled=true
system.webdav.activities.enabled=true
system.webdav.rootPath=${protocols.rootPath}

 

After a restart of Alfresco, the action suddenly worked without any problem. To do some more testing, I tried to enable only the “webdav.enabled=true” parameter but it stopped working again. So my next test was to enable only the servlet instead (“system.webdav.servlet.enabled=true“) and that was indeed sufficient.

Therefore, if you are using “webdavUrl” in any of your JavaScript code, make sure that you enable at least the servlet as follow:

$ grep webdav $ALF_HOME/tomcat/shared/classes/alfresco-global.properties
webdav.enabled=false
system.webdav.servlet.enabled=true
system.webdav.activities.enabled=false
system.webdav.rootPath=${protocols.rootPath}

 

There are other ways to retrieve the path of the working node on JavaScript inside a custom action so instead of enabling the WebDAV servlet, it is also possible (and probably better) to use another alternative. Here are the 4 different ways I know of, with an example value returned when executed on a Document:

  • record.webdavUrl -> ‘/webdav/dbi%20services/A%20Folder/My%20Document.docx’
  • record.location.path -> ‘/dbi services/A Folder’
  • record.location.repoPath -> ‘/dbi services/A Folder’
  • this.currentPath -> ‘/dbi services/A Folder’

 

As you can see, the values are rather similar, except for the node name (which can be retrieve with “record.displayName“) which is only present for the “webdavUrl” one. All the three other alternatives display the path up to the parent only. Therefore, if applied to a folder or document, you might also need the node name to be concatenated. In conclusion, if you do specifically need the “webdavUrl“, make sure that the “system.webdav.servlet.enabled” is set to true otherwise it won’t work.