/**
 * Custom content types
 */
function getContentTypes()
{
   // TODO: Data webscript call to return list of available types
   var contentTypes = [
   {
      id: "cm:content",
      value: "cm_content"
   },
   {
      id: "my:customtype",
      value: "my_customtype"
   }
   ];

   return contentTypes;
}

model.contentTypes = getContentTypes();

The TODO is Alfresco developers note, so we may get this as an actual config option in the future, bit for now this is how you need to do it.
You also need to extend the file flash-upload.get.properties, in this case also html-upload.get.properties.
Add the value for “value” in the javascript for each of you custom types.

my_customtype=My Custom Type

This works well, and you get to set the document type for each of the files individually. There is one bug I’ve noticed, and that is that you get prompted for document type when uploading a new version, but it actually doesn’t change the type.
This is what it can look like.

To the left in the Document Library page there are some Quick searches like “I’m Editing”. This implies that we should have a way of adding our own. And you can, Sebastian Wenzky has written a good howto. The key is the file filter.lib.js available in
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary.
Looking at that you can see that you actually can call the Document Library page with parameters, for example
http://localhost:8080/share/page/site/alfresco/documentlibrary?filter=editingMe and end up directly on the built in searches.

So we now have to create our own filter for the switch statement in filter.lib.js so that we get an url like documentlibrary?filter=customQuery. But we also need a way to pass our search data, and luckily there is a parameter already defined that can be used for that purpose, filterData, that is passed all the way by share to filter.lib.js. Our search url will the be /documentlibrary?filter=customQuery&filterData=/your search parameters/.

Her is some sample code to be added in filter.lib.js, part of it is reused from what is in filter.lib.js. You will have to adapt the code to fit you needs and custom metadata.

         case "customQuery":
             filterQuery = "+PATH:\"" + parsedArgs.rootNode.qnamePath + "//*\"";
             if(args.filterData.length>0)
             {
            	 var strData=decodeURI(args.filterData);
            	 logger.log(strData);
            	 var queryArray=strData.split("|");
            	 for(var i=0;i<queryArray.length;i++)
            	 {
            		var strQuery=queryArray[i];
            		var strQueryArray=strQuery.split("_");
            		logger.log(strQueryArray[0]);
            		logger.log(strQueryArray[1]);
            		switch (strQueryArray[0])
            		{
            		case "ftx":
             			var ftterm=strQueryArray[1];
            			var ftquery=" +(";

            		      var ftterms = ftterm.split(/\s/), i, j, t;

            		      for (i = 0, j = ftterms.length; i < j; i++)
            		      {
            		         t = ftterms[i];
            		         // remove quotes - TODO: add support for quoted terms later
            		         t = t.replace(/\"/g, "");
            		         if (t.length !== 0)
            		         {
            		            switch (t.toLowerCase())
            		            {
            		               case "and":
            		                  if (i < j - 1 && ftterms[i + 1].length !== 0)
            		                  {
            		                     ftquery += "AND ";
            		                  }
            		                  break;

            		               case "or":
            		                  break;

            		               case "not":
            		                  if (i < j - 1 && ftterms[i + 1].length !== 0)
            		                  {
            		                     ftquery += "NOT ";
            		                  }
            		                  break;

            		               default:
            		                  ftquery += "TEXT:\"" + t + "\"" + " ";
            		               		break;

            		            }
            		         }
            		      }
            		      filterQuery += ftquery+") ";

            			break;
            		case "docid":
            			filterQuery += " +@sys\\:node-dbid:"+strQueryArray[1];
            			break;
            		case "contractid":
            			filterQuery += " +@ltx\\:contractid:"+strQueryArray[1];
            			break;
            		case "doctype":
            			filterQuery += " +TYPE:\"{http://www.loftux.se/model}"+strQueryArray[1]+"\"";
            			break;
            		case "file":
            			//we need to search both with and without wildcards. Sometime there is a hit
            			//sometime not if we dont depending on search term. Makes results more predictable
            			filterQuery += " +(@cm\\:name:"+strQueryArray[1] + " OR @cm\\:name:*"+strQueryArray[1]+"*)" ;
            			break;
                    case "tag":
                    	filterQuery += " +PATH:\"/cm:taggable/cm:" + search.ISO9075Encode(strQueryArray[1].toLowerCase()) + "/member\"";
                        break;
                    case "sort":

                    	if(strQueryArray[1]=="editdesc")
                    	{
                    		filterParams.sort = [
                    		{
                    		column: "@{http://www.alfresco.org/model/content/1.0}modified",
                    		ascending: false
                    		}];
                    	}
                    	if(strQueryArray[1]=="editasc")
                    	{
                    		filterParams.sort = [
                    		{
                    		column: "@{http://www.alfresco.org/model/content/1.0}modified",
                    		ascending: true
                    		}];
                    	}

                    	break;
            		}
            	 }

             }
             filterParams.query = filterQuery + filterQueryDefaults;
             filterParams.query += " " + (Filters.TYPE_MAP["documents"]);

We now can call the Document Library page with (example)
/documentlibrary?filter=customQuery&filterData=ftx_test|doctype_contract|sort_editdesc.
This is as you can tell not a generic solution, each parameter is built up from a field in your search form. The search above would do a fulltext search on “test” and a document of custom type contract, sorted descending on last edit date.

To display correctly in Share Document Library, we also have to add our customQuery to Share. Find the file
site-webscripts/org/alfresco/components/documentlibrary/filter.get.config.xml and add a new filter filter.

<filters>
   <filter id="all" label="link.all" />
   <filter id="editingMe" label="link.editingMe" />
   <filter id="editingOthers" label="link.editingOthers" />
   <filter id="recentlyModified" label="link.recentlyModified" />
   <filter id="recentlyAdded" label="link.recentlyAdded" />
   <filter id="favouriteDocuments" label="link.favouriteDocuments" />
   <filter id="customQuery" label="link.customQuery" />
</filters>

Our filter is to be called by a special search page, so we don’t want i clickable link to apper. We can do this simply by making the label above blank in the file filter.get.properties (found in the same folder as above)
link.customQuery=
Also in the file toolbar.get.properties we have to add some labels for the result list to appera nicely.
description.customQuery=Custom Search
description.customQuery.more=
If you have added more lanugages to share, add the same lines for corresponding properties files.

Now you just have to create you search form. you can do that by adding a custom Dashlet, or with a custom Share page. I will not describe this in this post, I may make a follow up post for that.

Note that Alfresco is also adding similar functionality to Share for version 3.3. It will be for the Share quick search box, where you can add parameters to search specific metadata by writing for example description:important and get an url like /share/page/search?t=description:important. But to my understanding this will only be by using the quick search box, and therefor more for advanced users. But this is certainly an option to wait for this functionality, and instead create you custom search page to call this url.

<config evaluator="aspect" condition="my:customaspect">
	<forms>
		<form>
			<appearance>
				<field id="my:customtextfield" set="mycustomset" mandatory="true">
					<control template="/org/alfresco/components/form/controls/autocomplete.ftl">
						<control-param name="ds">/share/service/ds/autocomplete/alfrescoperson />
					</control>
				</field>
			</appearance>
		</form>
	</forms>
</config>

Now you have the looks of you aspect defined, now you will have to add when to display your custom aspect.

>
<config evaluator="node-type" condition="my:customtype">
	<forms>
		<form>
			<field-visibility>
				<show id="sys:node-dbid" />
				<show id="my:customaspect" />
				...

It will display if you add that aspect to your document for that particular custom type. As you can see it should not go into the appearence tag in node-type evaluator. For properties specific for that document type on the other hand, appearance should be placed there. As you can see I also use a custom set to group and to put a label for the aspect above (mycustomset). You will have to assign it under the aspect-evaluator. What you will have to do is for each document type create an appearance tag for the custom set you want to use.

<set id="mycustomset" appearance="bordered-panel" label="Company Inc. - My Custom Type" />

I have used the label to clearly identify what type of document you current document is (My Custom Type in this case).
As you can see i’ve used sys:node-dbid, that is the internal number sequence Alfresco assigns a document, and works perfectly as a dokument-id. However, we need a better label than the default one. You can get that by adding to your node-type evaluator for you custom type

<appearance>
       <field id="sys:node-dbid" read-only="true" set="mycustomset" label="Document ID" />

The forms enginge uses the data models message resource bundle to know what labels to put for each metadata field. So create this file together with you model file if you want you property sheet to be multi-lingual. It should be possible to create resource bundles that is used by the forms engine so that you dont need to hardcode for example “Document ID” as I did. I have yet to find out where to put those files, have to come back to that.
The end result could be something like this:

Now I just need to add a Twitter dashlet to our Alfresco Share installation, in combination with tracking features like acitivites feed, I’ll get a nice client where I can do most of my work. I have yet to try Alfresco Share blog integration with Wordpress.

And this post should now end up as a tweet as well, the tweet update my Facebook status and be visible in my linked in page. I’ll se if that works out.