Dec 082013

I have updated my Hesk hack based on a request from a reader. You can view the new instructions or download the new files here:

For those unaware, my previous post on this matter was here:

2.5 introduced a lot of changes. One of the big ones that affected my hack was the ability to directly link to a category type. This is now built into the application, so I modified my hack to take advantage of this.

If you have any questions, let me know.

Dec 032013

At work we have started using a piece of software called Alfresco. We use the Share web interface for collaboration within our department. A co-worker and I attended the excellent Alfresco Summit: in Boston. We learned a lot about the software and how extensible it is. It can be used in many ways, far more heavily then we are currently using it. We have hatched plans to use it for our departmental workflows, as well as building an online repository upon the deep repository backend that is available.

The application is written in Java and has lots of configuration and modification options. I’m going to highlight the first change we made to the Share UI here. I plan to document more in the future.

Goal: We plan to use our Share implementation mostly for internal collaboration and have it tied to our active directory for that purpose. However, we do plan to allow others to come in for some projects. Because of this we wanted to change the default option when creating a site from ‘Public’ to ‘Private’. This will help prevent staff from creating sites that are public by accident.

While at the conference, I spoke with an Alfresco Engineer and he explained how we could customize this page.

The file which controls the screen is called: create-site.get.html.ftl. I found it at ./tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/modules/create-site.get.html.ftl

Grab a copy of all of the content in this file and make your changes.

Then, create the same file in this directory: ./tomcat/shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/modules/ (you will likely have to create some of these directories yourself.) Note that the part of the original path after WEB-INF matches everything after the shared folder in the except for the addition of the web-extension folder in the override path. I’m sure that is relevant, which is why I’ll highlight it below:
Path 1: ./tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/modules/
Path 2: ./tomcat/shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/modules/

If you wanted to customize the HTML available in other parts of the app, you could probably drop the override file into the matching directory from its original location.

Anyway, once you have the file in place, you can restart Alfresco and it should be in play. This worked the first time I tried it, which was quite excellent!

Now, when you complete upgrades of your repository, you should back up your customizations and reapply them using the newer version of the code. The Alfresco team could change, add, or remove features from the page you are customizing and your override file will not take into consideration those changes. This could cause the behaviour to be erratic after the upgrade.