In Share, when I need to alter default functionality I start with looking into the page I need to change, and then find out how this page is called, and if I can add parameters or need to change javascript. In this case it is page/site/{site}/edit-metadata that I somehow need to tell to use a different form. This page use template-instances/edit-metadata.xml, and in there is a form component

<!-- Edit Metadata Form -->
<component>
  <region-id>edit-metadata</region-id>
  <url>/components/form</url>
  <properties>
    <itemKind>node</itemKind>
    <itemId>{nodeRef}</itemId>
    <mode>edit</mode>
    <submitType>json</submitType>
    <showCaption>true</showCaption>
    <showCancelButton>true</showCancelButton>
  </properties>
</component>

The form is rendered using the webscript /components/form, now I need to find out if there is a way to pass in a form id. I then look in folder site-webscripts/org/alfresco/components/form/ to find out how the form generation works, form.get.html.ftl includes form.lib.ftl and in there I can see that you can pass formId as an argument. I can now either alter template-instances/edit-metadata.xml, or use the new Surf extensibility functionality (from version 4.0). With a surf extension i add to site-data/extension a file called myextension.xml with content

<extension>
	<modules>
		<module>
			<id>ReplaceForm</id>
			<description>Show edit metadata for specific form</description>
			<components>
				<component>
					<scope>template</scope>
					<region-id>edit-metadata</region-id>
					<source-id>edit-metadata</source-id>
					<sub-components>
						<sub-component id="default">
							<evaluations>
								<evaluation id="hide">
									<render>false</render>
								</evaluation>
							</evaluations>
						</sub-component>
						<sub-component id="edit-metadata-new" index="25">
							<url>/components/form</url>
							<properties>
								<itemKind>node</itemKind>
								<itemId>{nodeRef}</itemId>
								<formId>{formId}</formId>
								<mode>edit</mode>
								<submitType>json</submitType>
								<showCaption>true</showCaption>
								<showCancelButton>true</showCancelButton>
							</properties>
						</sub-component>
					</sub-components>
				</component>
			</components>
		</module>
	</modules>
</extension>

I will not go into details about surf extension, instead watch the Alfresco Webinar about Surf extension with David Draper and read the slides. What happens when this customization is applied is that the default component is replaced by one that can take formId as url parameter. You can easily test this (when above extension is applied) by navigating to page edit-metadata and in the end of the url add &formId=doclib-simple-metadata. You will se the form that is normally just used for the popup edit metadata dialog in the full page edit.

So now I need a way to call this page with the formId parameter. The edit-metadata page is opened using a document library action, so I need to append the formId parameter if (and only then) the aspect in question is used. From version 4.0 this is in configuration that you can easily alter. The default config for actions is found in share/WEB-INF/classes/alfresco/share-documentlibrary-config.xml. From there I came up with this config that you can put in share-config-custom.xml

  <config evaluator="string-compare" condition="DocLibActions">
    <!-- Action definitions -->
    <actions>
      <action id="document-edit-metadata" type="pagelink" label="actions.document.edit-metadata">
        <param name="page">edit-metadata?nodeRef={node.nodeRef}</param>
        <permissions>
          <permission allow="true">Write</permission>
        </permissions>
        <evaluator negate="true">evaluator.doclib.action.isLocked</evaluator>
        <override>document-edit-properties</override>
      </action>
      <action id="document-edit-metadata-diarie" type="pagelink" label="actions.document.edit-metadata">
        <param name="page"><![CDATA[edit-metadata?nodeRef={node.nodeRef}&formId=diarie]]></param>
        <permissions>
          <permission allow="true">Write</permission>
        </permissions>
        <evaluator>evaluator.isDiarieNotLocked</evaluator>
        <override>document-edit-metadata</override>
        <override>document-edit-properties</override>
      </action>
    </actions>

    <!-- Action Group definitions -->
    <actionGroups>
      <actionGroup id="document-browse">
        <action index="130" id="document-edit-metadata" />
        <action index="130" id="document-edit-metadata-diarie" />
      </actionGroup>
      <actionGroup id="document-details">
        <action index="120" id="document-edit-metadata-diarie" />
      </actionGroup>
    </actionGroups>
  </config>

It does two things, first I replace the popup metadata edit in browse mode, I want the full page. So that is why the default config for action ‘document-edit-metadata’ is added. I cannot only add this action to Action group definitions, because then you will see both, that is why I redefine the action, but now with an override to hide document-edit-properties if used. Next is to add my new action ‘document-edit-metadata-diarie’ that has the formId parameter. Note that it needs enclose the parameter in CDATA to be valid xml. If the evaluator returns true, then use this one and override the others. So next we need to define the evaluator.isDiarieNotLocked. Default evaluators can be found in share/WEB-INF/classes/alfresco/slingshot-documentlibrary-context.xml. Put yours in a mycustom-context.xml file in the class-path.

  <bean id="evaluator.hasdiariefordaspect" parent="evaluator.doclib.action.hasAspect">
    <property name="aspects">
      <list>
        <value>lx:diarieFord</value>
      </list>
    </property>
  </bean>
  <bean id="evaluator.isNotLocked" parent="evaluator.doclib.action.chainedMatchOne">
    <property name="evaluators">
      <list>
        <ref bean="evaluator.doclib.action.notEditable" />
      </list>
    </property>
    <property name="negateOutput" value="true" />
  </bean>
  <bean id="evaluator.isDiarieNotLocked" parent="evaluator.doclib.action.chainedMatchAll">
    <property name="evaluators">
      <list>
        <ref bean="evaluator.hasdiariefordaspect" />
        <ref bean="evaluator.isNotLocked" />
      </list>
    </property>
  </bean>

So my evaluators does this, evaluator.hasdiariefordaspect checks that is has the required aspect, evaluator.isNotLocked evaluates if it can be edited and is not locked (this one propbably can be defined in a smarter way, but it works), then finally put together in evaluator.isDiarieNotLocked where we need both previous evaluators to be true. If you want to learn more about Share Document library extension read Mike Hatfields blog.

And finally we have customized Share to use a specific form for edit metadata when the document has the selected aspect applied. With only configuration files!

Note that my approach lets user with a bit of knowledge add whatever form id they want in the url, and thus potentially edit hidden metadata. In this use case it was not considered an issue.

The problem here is that although there is a file locking mechanism in CIFS, and Alfresco can check for that and detect when there is a file save and apply versioning in the background, there is no way to control how client implements a file save. Many document editing clients implements some sort of temporary file where the actual saving takes place, until you finally close the document, the original document is deleted by the client, and replaced by the temporary file now renamed to the original name. This Alfresco has to detect to actually do versioning, and not just plain delete and creation of a new document. My intention here is not to exactly explain the process, rather give you a quick insight of what Alfresco has to deal with. And if you think that the Microsoft Office suite has one way of doing a file save, think again. Not only does the file save process differ between the different office products, it differs between version, Microsoft Word 2003 have a different save process than version 2007. In version 4 of Alfresco this has finally been dealt with in a reliable way, and I feel comfortable saying to my clients that they can use cifs without file editing in some cases corrupting the files.

So for one of my clients we quickly upgraded to version 4, and deployed Alfresco with Share client not only acting as collaboration tool, but also as their Intranet. And with document editing via cifs with Single Sign On using Kerberos. And to start with all is well. Until they start the bigger roll out to let more users edit via cifs. Then some users get access denied and get prompted with a login, but no credentials entered ever work. And these clients are are all on a Windows 2008 Terminal Server. And a issue tracking journey begins ending in a very odd workaround.

The reports of this error starting coming in the second week in january. Now from the end users perspective it is Alfresco that is failing, but when researching issues like this it can be just about anything from the Windows OS, network equipment, and Alfresco. You just have to keep an open mind about every possibility and not start a blame game between Windows, Network and Alfresco administrators. Here are some of the things we tried collaboratively (not specifically in this order)

• There was an authentication error is Kerberos. So in Alfresco turn on all the Kerberos and authentication logging there is. But no authentication errors in the log at all. It either works, or not.
• Windows admins notice that this happens around 50 users being logged in on the Terminal server. So maybe a throttling error with Active Directory servers. Second terminal server deployed, but on this server it happens around 10 users?
• Verifying all the krb5.conf settings, creating new keytab files and deploy on the Alfresco server
• Upgrading the Ubuntu version on the server Alfresco runs on
• Upgrading Alfresco version to latest Alfresco Community 4.0.d
• Restart of Terminal servers. Temporarily helped, but cifs session after a while started to get denied.
• Packet tracing, staring yourself blind at packet traces. We could catch the Authentication denied for SMB, but there was no clue whatsoever about why.

None of the above gave some insight, and we tried many more things not mentioned here. And if you have about 200 users relying on the Alfresco server being available, you cannot just restart Alfresco to try out configuration changes, or the terminal server. Probably would have saved some time if you are on Alfresco Enterprise, were you can change configuration and log levels without restart.

What finally gave a clue what was going on was setting the cifs.sessionDebug flags in alfresco-global.properties. Since we had no clue where the error could be, almost all of available flags were set. And it spits out lots of information, and in there we found

[SMB] Failed to allocate UID for virtual circuit, [0:-1,[peter@DOMAIN.NET:null,,,192.168.10.10,Normal],Tree=0,Searches=0].

It is not a very obvious error, and that it is the cause for authentication denied is even less obvious if you have no clue what a virtual circuit is. Time to learn more about cifs protocol than you want to. There was a similar error filed already JLAN-142, that I have now amended.

My client currently have have cifs working. It turns out that Windows 2008 Terminal server is “eating” smb sessions, and not releasing them, making Alfresco run out of Virtual Circuits . We have deployed two things, one is to compile a custom version of Alfresco (thank you for being open source) increasing virtual circuits from default 16 to 128. The other is a crazy one, the bug in windows can be worked around if you never log out the first user that logs into the terminal server as discussed in this Microsoft forum discussion. Since we deployed two fixes at the same time I cannot for sure say which is the final solution, or if they interact, but it actually looks like it is the “keep user logged in”, deemed “the weirdest workaround ever deployed” by my clients IT-administrators. If we can reach a definitive conclusion I will update this post, but after finally having a working system they are not to keen on more restarts.

And there seem to be some fixes to the SMB session leaks, since my client have their Terminal Server in a working state they haven’t tried them. But I think I should mention them, and if you have any experience with them let me know.

SMB/CIFS sessions leak in Windows Vista, in Windows Server 2008, in Windows 7 and in Windows Server 2008 R2

A handle leak occurs in a Server Message Block (SMB) session between computers that are running Windows Vista or Windows Server 2008

But my intention here is not to whine, Alfresco has the bigger picture here, and has to set the priorities. And since this is an open source product, if you are not to happy with how something work, you can fix/enhance it. So that is what I’ve done. I’ve created an alternative viewer based on the Mozilla project pdf.js.

All documents that are shown in the flash based viewer has been transformed in the chain <source format> - <pdf> - <flash>. If we could skip that one last step, we can avoid using pdf2swf, and thus the problem of risk of jvm crash. And there would support for the same source formats as currently. But then there needs to be a way to display the pdf inline. Chrome and Safari comes with build in pdf viewer, so that could be used. And many other have an external plugin like Acrobat reader installed. That would cover many users, but ideally there would be something that can be run in the browser to show pdf. And this is what pdf.js does, all implemented in Javascript and using html5.

So the viewer I’ve implemented tries to

• Use pdf.js viewer for html5 compliant browser
• If pdf.js cannot be used, try to see if pdf reader plugin is available, and display the pdf using that plugin
• As last option, the standard Alfresco flash based viewer is used if none of the above works.

The easiest way to do this was to use <iframe>, where the pdf.js viewer is loaded via an Alfresco surf page that implements the standard viewer almost out of the box. You can try the standard one here. It is very feature complete, and handles most of the pdfs I’ve tried very well.
The same method, using iframe, is used to display using a pdf reader plugin, just call the pdf directly in the iframe src url.

This is what it looks like

www.youtube.com/watch?v=V1R08Ba3uo4

I will release the source code shortly, needs to be cleaned up a bit. I will update here when I’m done with that.

Update
The source code is checked into the Share Extras project. You can view it here.
There is no compiled release yet, that is on purpose, it is still untested, but if you know how to check-out and compile, then I assume you understand not to rush it to use on a production server.

This is a very nice feature, that just works. But there are some problems with this. First there is no indication in Share forms that this happens, there should at least be visual indication that it is. Second problem is that the title and description properties are not just used for documents, they are user for many other components in Alfresco. I have done some testing, and I have found that Site name and description, Blog posts title, Discussion topic title, Data List name and description, and Data List entry name and description will show different texts depending on locale if it has been edited with different locale. Again this only happens if edited with a different locale, probably not happening so many times that a Discussion is edited with different locales, but that Site Managers from different countries change Site title and description is not unlikely.

It was a client of mine that first noticed this behavior, and I filed a bug ALF-3756 in July 2010. My initial reaction was that users should not see different things, and that is was because user user different browsers, and that this should be fixed. As it turns out, it is not because of different browsers, it is because of different locale preference set in different browsers. It was recently fixed in HEAD, so happily testing this out, nothing had changed and the behavior is the same. So i filed a regression bug ALF-11166, but after thinking of the multilingual behavior, it may be that it is not a bug after all, and this is why I’m writing this post.

I’ve thought of ways to fix this, one could be that you change the property definition of cm:title and cm:description in the data model from d:mltext to d:text. Some limited testing shows that this work, a property will stay multilingual (d:mltext) until next edit, then it is saved as d:text, and all user see the same thing regardless of locale. Changing the default model is nothing I recommend, and I only did very limited testing just to see what happened. And this is probably not the way to fix this, because it removes a nice feature. Alfresco is very locale (I18N for the hardcore) aware, you can localise almost everything, and from 4.0 property lists (constraints) can be localized. So the very fact that you can have a Site title and description in different locale is a good thing.

So the proper fix for this is to visually indicate what is going on in all forms and dialogs. It can be implemented in steps if not the full approach can be taken at once

1. Create a control with flag corresponding to the locale used, so that you visually see what locale is currently being edited.
2. Change the control so that you can list other values to see base language and the current values for other locales. That way you can keep track of translations and keep them in sync.

I created (or actually updated existing text controls) and then it looks like this for multilingual properties

Full details on how I did this is in the issue ALF-11166. Its a simple first step with just editing the control freemarker templates, a more complete solution would be as I outlined the possibility to list all added values for different languages. Let me know what you think.

This post will show you how to do this, and also take advantage of the built in templates (available from 4.0.b), and the new Surf extension mechanism.


All paths I’m referring to below are class path relative, if you are editing directly you can use tomcat/shared/classes/alfresco.
Start by creating a new page in site-data/pages called appintegrator.xml with content

<?xml version='1.0' encoding='UTF-8'?>
<page>
	<title>Application</title>
	<description>Application</description>
	<template-instance>1-column</template-instance>
	<authentication>user</authentication>
	<components>

		<!-- Top -->
		<component>
			<region-id>title</region-id>
			<sub-components>
				<sub-component id="appintegratortitle">
					<url>/components/title/simple-title</url>
					<properties>
						<title>Application</title>
					</properties>
				</sub-component>
			</sub-components>
		</component>

		<!-- Column -->
		<component>
			<region-id>column</region-id>
			<sub-components>
				<sub-component id="appintegratoriframe">
					<url>/components/appintegrator/iframe</url>
				</sub-component>
			</sub-components>
		</component>
	</components>
</page>

As you can see it uses a template instance of 1-column, one of the out of the box templates available from 4.0.b so we do not need to create templates for our new page. Erik Winlöf has posted about how to use these new templates if you want to learn more.
The first component in our new page is an out of the box component in Alfresco that we are just re-using to create a title bar. The next one is a new component we need to create to render the iframe. Start by creating files in site-webscripts/org/alfresco/components/appintegrator
iframe.get.desc.xml

<webscript>
  <shortname>appintegratoriframe</shortname>
  <description>Application Integrator iFrame</description>
  <url>/components/appintegrator/iframe</url>
</webscript>

iframe.get.html.ftl

<iframe id="${args.htmlid}-appintegrator" src="${protocol}${iurl}" scrolling="no"
marginwidth="0" marginheight="0" frameborder="0" vspace="0" hspace="0"
style="overflow:visible; width:100%; height:5000px"></iframe>

iframe.get.js

//The url argument is called iurl because there is a built in url object in Surf
var iurl = page.url.args.iurl !== null ? decodeURIComponent(page.url.args.iurl)
		: "loftux.se";
var ssl = page.url.args.ssl !== null ? decodeURIComponent(page.url.args.ssl)
		: "false";

if (ssl==="true") {
	model.protocol="https://";
}else{
	model.protocol="http://";
}
model.iurl=iurl;

Restart Share, and now you should be able to navigate to http://localhost:8080/share/page/appintegrator?iurl=loftux.com&ssl=false. As you can see there are two arguments, iurl is the url you want the iframe to load, and ssl true/false sets the protocol to https/http respectively (so you don’t add that in iurl).
Just start adding links to the Share Header, and you’ll have all your nice web apps in one convenient location.

But that title bar could say something more than just ‘Application’, like the name and a description of the application currently loaded in the iframe. Since we want to link it from the Share Header, we want to pass it as url arguments. For that we create a new title component, put it in site-webscripts/org/alfresco/components/appintegrator. It is very similar to the original one, it is just changed so that it can load arguments from the url.
appintegrator-title.get.desc.xml

<webscript>
  <shortname>Simple Title</shortname>
  <description>Simple generic title component that displays the title using the message keys passed in as url arguments</description>
  <url>/components/appintegrator/appintegrator-title</url>
</webscript>

appintegrator-title.get.html.ftl

<div class="page-title theme-bg-color-1 theme-border-1">
   <h1 class="theme-color-3"><span><#if page.url.args.title??>${page.url.args.title}</#if></span>
   <#if page.url.args.subtitle??>${page.url.args.subtitle}</#if></h1>
</div>

To load this new component, the “old” way of doing this would be to edit the template. But since we are using out of the box templates, we cannot change them. But for 4.0, there is a new extension mechanism, that we can use to simply replace an existing component with our own, without changing the template. For details on this, read David Drapers blog (first post in a series).

So we in site-data/extension we add the file
appintegrator.xml

<extension>
  <modules>
   <module>
   <id>Loftux AppIntegrator</id>
   <components>
     <component>
	<region-id>title</region-id>
	<source-id>appintegrator</source-id>
	<scope>page</scope>
	<sub-components>
	  <!-- Remove default title -->
	  <sub-component id="appintegratortitle">
	    <evaluations>
	      <evaluation id="hidedefaulttitle">
	        <render>false</render>
	      </evaluation>
	    </evaluations>
	  </sub-component>
	  <!-- Add our new title -->
	  <sub-component id="appintegratortitlenew">
	    <url>/components/appintegrator/appintegrator-title</url>
	  </sub-component>
	</sub-components>
      </component>
     </components>
    </module>
  </modules>
</extension>

I will not go into details on how to find region-id, source-id and component id:s, for that I recommend Davids posts. What we do here is to tell Share not to render the simple-title name appintegratortitle, and instead render our own title componet. For this to take effect, you must go to http://localhost:8080/share/page/modules/deploy and deploy the Loftux Appintegrator module.

When our extension module is deployed, we can add two new arguments to the url, title and subtitle that will display on the title bar. None of them are mandatory, just use the one you need.
Your final configuration for the Share Header could look something like this (extract)

<item type="container" id="application" icon="appintegrator.png">
   <container-group id="my" label="Internal Applications">
      <item type="link" id="loftuxse" icon="appintegratorwindow.png" label="Loftux.se" description="Dokument och informationshantering"><![CDATA[/appintegrator?title=Loftux.se&subtitle=Dokumenthantering&iurl=loftux.se]]></item>
      <item type="link" id="loftuxcom" icon="appintegratorwindow.png" label="Loftux.com" description="Document and Information management"><![CDATA[/appintegrator?title=Loftux.com&subtitle=Document%20management&iurl=loftux.com]]></item>
      <item type="external-link" id="devcona" icon="appintegratorsplash.png" label="DevCon Americas" description="Alfresco DevCon Americas"><![CDATA[/appintegrator?title=Alfresco DevCon&subtitle=Americas&iurl=www.amiando.com/alfresco-devcon-san-diego-2011.html]]></item>
      <item type="external-link" id="devcone" icon="appintegratorstar.png" label="DevCon EMEA APAC" description="Alfresco DevCon EMEA APAC"><![CDATA[/appintegrator?title=Alfresco DevCon&subtitle=EMEA%20APAC&iurl=www.amiando.com/alfresco-devcon-london-2011.html]]></item>
   </container-group>
</item>

This will render the menu in the first screenshot. Notice that you can have a links that open in the same window, or a new window/tab. Since applications are in an ifram, the user must have full access to them, so this approach is not suitable for an externally available Share client.

For this Share extension maybe it would have been easier to just create our template as input to our iframe page, and skipped using the new Surf extension. But I think it is a good example and a starting point for how it can be used.
You can download full source, sample share-config and a compiled jar from here AppIntegrator.

Now that removes any links to the page, but as the experienced Alfresco user you are, you know that you still can access the page typing the complete url to the page, for repository page it is /share/page/repository. And this is something you wanted to disable.

It is actually very easy to, the url will still be available, but not displaying any content besides the navigation bar.

Start with adding in tomcat/shared/classes/alfresco/web-extension
these folders and subfolders
site-data/pages
site-data/template-instances
templates
What you want to do is find the definition file of the page you want to disable, and copy it to site-data/pages. For the page used in this example, repository, it is tomcat/webapps/share/WEB-INF/classes/alfresco/site-data/pages/repository.xm
After copying, edit this page to be

<?xml version='1.0' encoding='UTF-8'?>
<page>
   <title>Repository Browser</title>
   <title-id>page.repository.title</title-id>
   <description>Browse content across the whole Repository</description>
   <description-id>page.repository.description</description-id>
   <template-instance>disabled</template-instance>
   <authentication>user</authentication>
</page>

The important change here is <template-instance>disabled</template-instance>, we are telling this page to use a new template, that we now have to create.
Create the file site-data/template-instances/disabled.xml with content

<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<template-instance>
   <template-type>disabled</template-type>
</template-instance>

and the the actual template file site-data/templates/disabled.ftl with content

<#include "/org/alfresco/include/alfresco-template.ftl" />
<@templateHeader />

<@templateBody>
   <div id="alf-hd">
      <@region id="header" scope="global" protected=true />
   </div>
<hr/>
This page is not available.
</@>

<@templateFooter>
   <div id="alf-ft">
      <@region id="footer" scope="global" protected=true />
   </div>
</@>

You can of course add what ever message you like.
Then refresh your webs-scripts or restart your server, and your repository page is disabled.
For any additional page you want to disable, you can just reuse the disabled template. All you have to do is the first step and copy the page definition file, and change it to reference your new template. To know what file to copy, navigate to the page you want to disable, in the url what you find after the /page/ is usually the name of the page definition file with an xml extension.

And of course this can be done even more advanced, like adding response status code 404, add I18N support for the message, or including component webscripts. But this will get you started.

As an open source company you always have to walk the fine line between just releasing everything for free and getting organisations to pay for your work and generate revenue. This is where Alfresco Team is important, small business customer now actually can pay for what they use, instead of just use the Community edition. But my initial reaction is that Alfresco has set the limits to tight, that it may not encourage a switch from Community to Team, and I will explain why.

The license is that you pay for the number of users. That is all fine, and the more users, the more you pay. But there is also a limit on the number of documents. From 10-100 users there is approximately 30000 docs, from 125-200 it is 60000. That limit should actually scale more linear, so the more users, the more documents. And it should start at a much higher number (if there should be a limit on number of documents at all). I can understand that the there is a cap so that servers do not get overloaded and generate for Alfresco costly support. But 30000 documents seems quite limited for even the smallest organisation.

But my biggest concern with the Alfresco Team release are the non existent possibility to customize. Jeff Potts recently published a post about With Commercial Open Source Innovation happens everywhere. It is all about how Forums, Open Issue tracker, Code contributions and more centered around Alfresco Community and Enterprise edition creates innovation. I mostly agree, but here is where Alfresco Team apparently do not fit. Because Alfresco has put a limit customizations http://team.alfresco.com/support/customizations you can make. To summarize, you can change css style sheets, and install dashlets, but that is pretty much it!

What, you cannot install a custom model with custom forms? Create a custom workflow? No, those are explicitly listed as no can do. And that is usually one of the first things you end up customizing. I guess this can be fixed by Alfresco by adding a built in content modeler and forms configurator, but still, if you can not have custom models in a content management system, why should i use Alfresco Team and not box.net or Google Apps?

And you are not allowed to use the repository tier, or the Repository page in share. And not do any integration work “for a custom content-centric application”. So if you are an innovative SMB, dont go for Alfresco Team, use Community, because Team edition just don’t fit with being innovative, due to limits set by Alfresco.

I have run my business Loftux for about a year now, and worked with about ten different clients, all of them on Community. And I have helped them create many innovative things, things that would not be allowed in Alfresco Team. My hope was that I could now convert some of the to use Team, and since they are mostly small business, Enterprise is not an option. They will now remain on Community, as long as these way to hard limitations remain. Jeff Potts explains Alfresco view in a post on why they have put these limits: “It’s really about keeping support costs down due to the lower price point”. I think there must be other ways than putting such a hard limit on how you can use the Alfresco Team edition.

Maybe these limits are a non-issue, that I just meet the SMBs that wants customizations, and all the rest out there run out of the box installs. And understand me correctly, this is not a post about getting things for free. I get paid by my clients for customizations, I just wish I could still do that, and my clients will pay Alfresco for support. For now, if I recommend Alfresco Team, I will turn away my own business. And to answer this post topic, SMBs do innovate.

Functionality

• All standard functionality in CKEditor.
• Loading of custom configuration files
• Insert images directly form Alfresco Share site

For form in Alfresco Share it is easy to create new controls. In this case you just tell Share form to use the new control

<appearance>
   <field id="cm:content">
      <control template="/org/alfresco/components/form/controls/ckeditor.ftl">
         <control-param name="forceEditor">true</control-param>
      </control>
   </field>
</appearance>

The actual control including source code can be downloaded from Share Extras project. More on how to configure forms on Alfresco Wiki
To install, copy the file ckeditor-form-control-0.1.jar to tomcat/webapps/share/WEB-INF/lib. Then change the form definitions as outlined above or copy the file ckeditor-config-custom.xml (remove .sample file ending) to tomcat/shared/classes/alfresco/web-extension and restart.

If you would like to use custom configuration file you can tell the control what config file to load with

<control-param name="settingsfile">components/editors/ckeditor/my-config.js</control-param>

The path should start without / and point to the location where you put your file. If you create a nice config file I can include it as an option file if you send it to me. Planning to add som custom config files in the future. More on how to configure CKEditor

To browse for images, click “browse on server” and you will get a list of thumbnails. I based it on the Images dashlet, so of course you can click on an image to get a large preview. To select an image, click on the filename.

The template user for the invite email is found in Repository> Data Dictionary> Email Templates> invite and is named invite-email.ftl. You can find it by clicking the Repository button in Alfresco Share toolbar, and then navigate to invite-email.ftl. You can edit this file online if you want to. Simple stuff, like changing the sender organisation name, most of us can do, but it is easy to do more.

The confirmation link created is using the server name of the server that the user doing the invite is currently using. This is in most cases correct, but you may want to direct internal and external users to different share servers (still connecting to same repository). It may be because you need to set up different authentication methods, or you have customized share to look different depending on if the users are external or internal.
http://alfresco.example.com/share/page/accept-invite?inviteId=jbpm$156&inviteeUserName=peter%40example.com&siteShortName=examplesite&inviteTicket=610b4819-0153-4406-9d85-0357e5ee65d3
The example above shows what the link may look like, in this case the alfresco.example.com is picked up from the server the inviting user is logged into when doing the invite. But in our case we want all external users to use alfresco-external.example.com. The can easily be achieved using freemarker code. If you never have used freemarker before don’t hesitate, if you know some html and/or javascript you will qiuckly pick up. Freemarker is also well documented.

This is what the template can look like, I’ve commented inline to explain.

<#assign inviterPersonRef=args["inviterPersonRef"]/>
<#assign inviterPerson=companyhome.nodeByReference[inviterPersonRef]/>
<#assign inviteePersonRef=args["inviteePersonRef"]/>
<#assign inviteePerson=companyhome.nodeByReference[inviteePersonRef]/>
<#-- Remove server name from the link-->
<#assign yesLink=args["acceptLink"]?substring(args["acceptLink"]?index_of("/share")) />
<#assign noLink=args["rejectLink"]?substring(args["rejectLink"]?index_of("/share")) />
<#assign userName=args["inviteeUserName"]?string />
<#-- Set server name depending on if user is internal or external -->
<#if userName?index_of("@") &gt; 0 >
<#-- All external user has their email address as username, check for this -->
    <#assign serverName="http://alfresco-external.example.com" />
<#else>
    <#assign serverName="https://alfresco.example.com" />
</#if>

Hello ${inviteePerson.properties["cm:firstName"]},

You have been invited by ${inviterPerson.properties["cm:firstName"]} ${inviterPerson.properties["cm:lastName"]} to join the '${args["siteName"]}' site.

Your role in the site will be ${args["inviteeSiteRole"]}.

To accept this invitation click the link below.
<#-- Append yes link to server name (that is different if internal or external user) -->
${serverName}${yesLink}

<#if args["inviteeGenPassword"]?exists>
and enter the following information:

Username: ${args["inviteeUserName"]}
Password: ${args["inviteeGenPassword"]}

We strongly advise you to change your password when you log in for the first time.

</#if>
If you do not want to join the site then click here:
<#-- Append no link to server name -->
${serverName}${noLink}

Create a bookmark after accepting for this server for use when you log in next time
${serverName} <#-- This is important, manu users miss where to navigate once they have accepted -->
You can create bookmarks for any place in Alfresco Share if you would like to reach you information quickly.

Regards,

${inviterPerson.properties["cm:firstName"]} ${inviterPerson.properties["cm:lastName"]}
Company

Note that you now can put a link to root in the Alfesco Share server. I’ve noticed that many times there are some confusion on where to navigate once the user has accepted. Users will find the invite email again, and the only clickable link in there is the invite, this results in an error since they already have accepted. Unfortunately html formatted emails are not supported by Alfresco yet, so the outgoing email will be plain text formatted.
Another tip can be to to put a link it a help page in the wiki (of you help page is named Getting Started)
${serverName}/share/page/site/publicsitename/wiki-page?title=Getting_Started
This must be a link to a public site so that all invited users have read access.

I have configured Alfesco so that external user id:s is base on their email adress. You can do this by creating a file in tomcat/shared/classes/alfresco/extension named invite-context.xml with the content

<?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="nameBasedUserNameGenerator" class="org.alfresco.repo.security.authentication.NameBasedUserNameGenerator">
            <!-- name patterns available:
       		%lastName%,  lower case last name
       		%firstName%, lower case first name
       		%emailAddress% email address
           	%i% lower case first name inital
     		-->
        <property name="namePattern">
        	<value>%emailAddress%</value>
        </property>
        <property name="userNameLength">
            <value>10</value>
        </property>
    </bean>
</beans>

You can also add fixed text, for example if you would like to have the prefix ext you can use ext_%firstName%_%lastName%.

Hope that this have given you some ideas. There is of course so much more you can do, for example add links to support, links to searches, adding a second language and more. Put some work into this template, as it often is the first thing users get in contact with when starting to user Alfresco Share. Good luck.