Thursday, March 25, 2010

Reviving Alfresco Share Thumbnail and Avatar Images

One great thing about Alfresco Share is (was) the ability to automatically create thumbnails for documents on upload.  Being able to visually browse your documents before opening them is a feature that many people like.  It can help you locate the document more quickly and helps to distinguish document contents in the case where documents are similarly named.

The problem is that on Windows in Alfresco Enterprise 3.2r, this feature broke.  On upload of a document, Alfresco tries to generate the thumbnail for the image content, but fails and instead creates a zero-byte thumbnail file.

You'll see something like this.

The default picture of a pair of gears displays whenever Share doesn't have a valid thumbnail file to display.

Searching in the forums for a possible solution, I came across one posted by Nicola Prando.  The bug and solution are also posted as ALF-1978.  Thanks Nicola!

The trick to fix this is to define a base directory for ImageMagick to use on Windows.  You can find the following file:
C:\Alfresco\tomcat\webapps\alfresco\WEB-INF\classes\alfresco\subsystems\thirdparty\default\imagemagick-transform-context.xml

You need to add the following lines to the property processProperties for the bean transformer.ImageMagick.Command:

<entry key="SYSTEMROOT"> 
       <value>C:/WINDOWS</value> 
    </entry>

But it isn't good practice to modify a file in the core Alfresco directory.  Instead define a new imagemagick-transform-context.xml file and place here:
C:\Alfresco\tomcat\webapps\alfresco\WEB-INF\classes\alfresco\extension\imagemagick-transform-context.xml

The contents of the file with this change looks like:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<beans>

   <bean id="transformer.worker.ImageMagick" class="org.alfresco.repo.content.transform.magick.ImageMagickContentTransformerWorker">
      <property name="mimetypeService">
         <ref bean="mimetypeService" />
      </property>
      <property name="executer">
         <bean name="transformer.ImageMagick.Command" class="org.alfresco.util.exec.RuntimeExec">
            <property name="commandsAndArguments">
               <map>
                  <entry key=".*">
                     <list>
                        <value>${img.exe}</value>
                        <value>${source}</value>
                        <value>SPLIT:${options}</value>
                        <value>${target}</value>
                     </list>
                  </entry>
               </map>
            </property>
            <property name="processProperties"> 
               <map>
                  <entry key="MAGICK_HOME">
                     <value>${img.root}</value>
                  </entry>
                  <entry key="DYLD_LIBRARY_PATH">
                     <value>${img.dyn}</value>
                  </entry>
                  <entry key="LD_LIBRARY_PATH">
                     <value>${img.dyn}</value>
                  </entry>
    <entry key="SYSTEMROOT"> 
                     <value>C:/WINDOWS</value> 
                  </entry>
               </map>
            </property>
            <property name="defaultProperties">
               <props>
                  <prop key="options"></prop>
               </props>
            </property>
         </bean>
      </property>
      <property name="checkCommand">
         <bean name="transformer.ImageMagick.CheckCommand" class="org.alfresco.util.exec.RuntimeExec">
            <property name="commandsAndArguments">
               <map>
                  <entry key=".*">
                     <list>
                        <value>${img.exe}</value>
                        <value>-version</value>
                     </list>
                  </entry>
               </map>
            </property>
         </bean>
      </property>
   </bean>

</beans>

After doing that, thumbnails will get correctly created.

Another tip, if you should ever need to debug Alfresco thumbnail creation, add the following lines to your log4j file to get debug information:
C:\Alfresco\tomcat\webapps\alfresco\WEB-INF\classes\log4j.properties

log4j.logger.org.alfresco.repo.content.transform=debug
log4j.logger.org.alfresco.repo.thumbnail.ThumbnailServiceImpl=debug

Friday, March 19, 2010

Alfresco 3.3 in the Making

About a month has passed since the Alfresco Enterprise 3.2r release.  The Alfresco development team is now in heads-down development, working on release 3.3.  The roadmap for the 3.3 release is posted on the Alfresco wiki and the next upcoming release, version 3.3, is scheduled for Q2 2010.

Out of curiosity, I thought that I'd check in with the latest Alfresco SVN HEAD source code to see some of the things that are brewing for the 3.3 release.  There are at least three areas that are showing interesting development, and I'll mention them here.

I did run across some problems, but then this code is far from a release date of a few months from now.

Themes for Share

The Admin Console of Share has been enhanced to include a new Tool plugin called "Application".  It looks like a place where overall Share configuration will be done via the UI.  The only thing there right now is the ability to select the Alfresco Share Theme.  Have a look at the "High Contrast Theme":



And here is what the Dashboard looks like after the "Yellow Theme" is applied:



Space Rules in Share

The Alfresco 3.3 Roadmap mentions enhancements in Share around Space Rules:

      Rule and Action Management
          
Linked Rules allowing rules to reused across multiple space
           - Compensating actions triggered on main action failure


Now when looking at the Actions available for a Folder/Space within Share, you see the following options.  Here I compare how the Folder Actions options have changed.

Folder Actions in 3.2r
Folder Actions in 3.3 pre-release

After clicking on "Manage Rules", you'll see the following:


On click of "Create Rule" you get a single screen for defining the new rule.  Unlike the wizard of Alfresco explorer, it's all in one place.  The "Link to Rule Set" will let you define libraries of reusable rules.


I think I prefer this consolidated view to defining a rule compared to the explorer wizard interface.  And it looks like a lot of the new rules functionality for Share is already working.  As shown above, I tried creating a rule on a space that adds the Taggable Aspect to incoming items to the folder.  Most of the UI is working pretty well.  The rule itself though didn't seem to get run when I later added content to the folder, and subsequent clicks on "Manage Rules" for the folder threw some errors.

I also experimented by creating a rule that would assign a simple workflow to incoming items of the folder.  I selected the Review and Approve Workflow with the option of moving the document to a different folder after approval.  I liked the interface for specifying the workflow, but this threw an error too.  It was interesting, although maybe not unexpected, that the error was one that shows the Surf logo.  That's the first time I've seen that in Share.


Alfresco Web Editor (AWE)

Alfresco's Ben Hagan has written a Blog entry explaining how to build and test the new Alfresco Web Editor (AWE).  This is the Web Editor that will be used in future releases of Alfresco WCM.

It all worked for me as described in Ben's blog, and it looks like it has good potential.  It looks a bit early though to start building anything out with it just yet.  But to already have something up and running is a good sign that there will probably be rapid progress on this front.

Monday, March 15, 2010

Smart Record Filing with Alfresco Share

Suppose you are using Alfresco with Records Management and you'd like to simplify the task of filing documents within the Records Management File Plan. That way documents filed by any user could be easily and automatically moved to the right spot within the File Plan.  (Or in a similar scenario where document filing is needed outside of the Records Management world.)

Consider a scenario that uses an Advanced workflow for document approval.  As the final step of the process, the document is accepted or rejected.  If accepted, we want to file the document correctly within the File Plan. And we'd like to be able to do it in a way that the user needn't have to know anything about the File Plan hierarchy.  Just hit "accept" and they're done.

One way to do that is to identify something about the document attributes that can be used to trigger off of for where to file the document.  To keep things simple, let's consider the case where we trigger off of some text appearing within the name of the document.

Suppose the following three File Plan paths exist:
        Legal/Contracts/City Sewer
        Legal/Shareholder/2009Q3-public
        Legal/Corporate/2009Q3-10Q

Depending on whether the following key words are contained in the document name string, the document will be moved to the appropriate folder: "Sewer", "Shareholder", "Corporate".

We can write some server-side Javascript that will then process the file correctly.

Consider this code snippet:

// Define mapping pairs
//   [ "String to search", "Alfresco space to map to" ]
var remap = [ ["Sewer", "Sites/rm/documentLibrary/Legal/Contracts/City Sewer"],
              ["Shareholder", "Sites/rm/documentLibrary/Legal/Shareholder/2009Q3-public"],
              ["Corporate", "Sites/rm/documentLibrary/Legal/Corporate/2009Q3-10Q"] ];
              
// Get the Name of the document
var docName = document.properties.name;

for( m in remap )
{
    var check = remap[m];
    if( docName.search( check[0] ) > -1 )
    {
       // Found a match.  String contained in document name
       var destSpace = companyhome.childByNamePath( check[1] );
       
       // Move the document to the right Alfresco space
       document.move(destSpace);
    }
}

This code could be embedded within the approval workflow process definition file. Or it could be extracted out into an external script. For example, the workflow might simply move the file to an "approve" folder and that folder could have an Alfresco rule assigned to it that executes the Javascript for filing. In that case, if the identification fails, the document stays in the "approve" folder and must be manually identified and filed.

The Javascript code defines an array of filing rules that specify which folder to move the document to depending on a match on part of the document name.

Wednesday, March 10, 2010

Tip: Repository Browsing in Alfresco Share 3.2r

There's a cool but not-well-publicized feature of the Alfresco 3.2r release (February 16) in Alfresco Share -- general browsing of the entire Alfresco Repository from the Share interface.  Paul Hampton, director of Product Marketing at Alfresco, briefly showed the feature in a webinar and later wrote a blog entry describing it.

Since Alfresco is in the process of migrating functionality from their 'classic' explorer client application to Share, it makes sense that general repository browsing be migrated.  Until this release, Share was only able to browse files in the document libraries of Share sites.

The feature is turned off by default, but it can be enabled by changing a boolean flag in the configuration file:
...\tomcat\shared\classes\alfresco\web-extension\share-config-custom.xml

This section of the XML configuration needs to be changed:


      
      true

The 'visible' flag needs to be set to true to be enabled.

After making that change and restarting the server, you'll see a link to the repository on your Share home page along the top links to the right of the Share logo.



After clicking on the Repository link, you'll then be able to browse the standard Alfresco repository.  (You may need to F5/refresh your browser cache to see it.)  You can upload files, create folders and create new content.

Wednesday, March 3, 2010

Tip: Setting Alfresco Global Properties

Configuration of Alfresco can be a bit challenging.  It takes some time to get a feel for which file needs to be modified and what directory that file is in.  Part of the reason for the number of files has to do with the fact that Alfresco is based on Spring, and Alfresco has adopted Spring configuration methodology.

In Alfresco 3.2 some of the complexity around finding where to make a configuration change has been simplified.  Alfresco introduces the concept of the alfresco-globals.properties file.  This new file tries to centralize as much as possible basic Alfresco configuration parameters  and settings.

alfresco-globals is basically a global override file.  The goals was to try to simplify common configuration settings into a single file.  Rather than centralizing everything into one file, which would be quite large and unwieldy, parameters defined in this file override parameters defined elsewhere in the standard configuration files used up until now.

After a full Windows install of an Alfresco 3.2+ system, you'll find this file in your tomcat\shared\classes directory. It will contain some of the settings selected during the installation process, like database connection information.  If the file isn't already there, you can find a template for it here:
   ..../tomcat/webapps/alfresco/WEB-INF/classes/alfresco-global.properties.sample

Some of the most common settings that are configured in Alfresco that can now be set/overridden by values in  alfresco-global file include parameters from these files:
..../tomcat/webapps/alfresco/WEB-INF/classes/alfresco/repository.properties
..../tomcat/webapps/alfresco/WEB-INF/classes/alfresco/hibernate-cfg.properties


Override values for Alfresco subsystems are also set in the alfresco-global.properties file.