I didn’t immediately see any simple, working examples of how to search custom aspect properties via CMIS so I’ll post a brief one here.
In this example we’re using a CMIS query to search for the IPTC caption property provided by the IPTC/EXIF project. After installing that module the properties are applied using an aspect which is defined in
Within that file you’ll see:
<aspects> <aspect name="iptc:iptc">
In our case the target Alfresco repository is running enterprise 3.3.1 and aspects are implemented via JOIN syntax as very briefly stated in the wiki.
So the resulting query for this particular search of the IPTC caption field ends up looking like:
SELECT D.*, IPTC.* FROM cmis:document AS D JOIN iptc:iptc AS IPTC ON D.cmis:objectId = IPTC.cmis:objectId WHERE IPTC.iptc:caption LIKE '%searchTerm%'
There were big changes in Alfresco 3.4 in terms of metadata extraction and I haven’t yet had a chance to update the forge projects (or determine if they’re still even needed) and there are proposals for aspects in the next CMIS spec so I’ll be back to update this post.
It seems like every 6 months to never I hear: “The Alfresco thumbnails forge project used to be cool man, what happened?” Chill Winston, it’s still cool.
Now that Alfresco has a native implementation of thumbnails is the forge project still needed? Well, ‘needed’ is relative I suppose, but check out what the project gets you beyond the basic Alfresco distribution:
- Thumbnails when browsing, searching, or viewing a document in Alfresco Explorer (i.e. not Share)
- CoolIris view when browsing or searching in Alfresco Explorer (which is sweet)
- Actions to force the creation or update of thumbnails using Alfresco’s native thumbnail service
- A video transformer based on ffmpeg with the ability to specify an offset (also sweet)
- A patch to delete and regenerate thumbnails created by old versions of the forge project (Admittedly, not that awesome, but useful nonetheless. No one wants a messy bloated repo.)
There’s also several goodies on the roadmap for future releases of the project including Share mods.
So what are you waiting for? Go manage your modules and pop that amp into your war (for the non-geeks, I promise that’s not gross).
The thumbnails forge project was started quite a while ago (like Alfresco 0.9 or so… old school) and the first public release was put on the forge in late 2006 (which would have been around Alfresco 1.3 I guess).
The project gained the attention of the Alfresco team and they contacted me about making a few changes to bring it more inline with what they had in mind for an implementation, notably creating a public thumbnail service. Those changes were made and I continued to collaborate with Alfresco on the forge project and gave input on their implementation.
Here’s a look at some of the differences to be aware of between the old thumbnails project implementation and Alfresco’s new native thumbnails:
|Concept||Pre 1.0 Versions of Forge Project||Alfresco 3 Native|
|The service responsible for generating and retrieving thumbnails||
A specific thumbnail can be generated with overriding options
The content property from which the source data will be read
|A common size and destination mimetype for thumbnails||
|The detailed resizing specifications||
The resizing details are specified using classes containing generic
|The model type||
Not being of type content prevents most rules from being run on
Care must be taken to not run rules or index thumbnail nodes since they
One suggestion has been to add the following to the thumbnail type:
|The model property name of the common size and mimetype destination definition||
|Default thumbnail sizes (max length/width)||
- Strikethroughs represent deprecated items.
- Avatar thumbnail size has nothing to do with what I can only assume is an incredibly overhyped movie about pissed off blue tree people since I haven’t been to a theater in like 10 years.
This information has been available in the thumbnails project’s 1.0 release readme but as it’s not shown by default I figured I’d post here as well.
We were originally using Apple OS X Server as our LDAP store for our Alfresco instance.
Apple’s OS X Server uses OpenLDAP but adds custom schema for many things including users and groups. As a result we ended up using the
description LDAP attribute for Alfresco’s
We’ve since migrated to a generic OpenLDAP server (with a bit of our own custom schema) so we’re now able to use the more common and unchanging
cn attribute for the group id.
When we change
ldap-synchronisation.properties Alfresco imports the new groups properly but group permissions on spaces will retain the old group name so we need to change those to use the new
What we did was to create a temporary table in the Alfresco database, import the mapping of the
cn attribute to the
description attribute, then run a query to replace the old authorities with the new.
The following assumes Alfresco version 3.x.
Create the Temp Table
Import the LDAP Group Data
We used phpLDAPAdmin to export our groups subtree as CSV with only the
description attributes, then imported that file into the
t_ldap_groups table just created.
Replace the Old Authorities
I’m by no means an SQL expert but the query below does the following:
GROUP_from the current stored group long name
- Searches the temporary LDAP table for that group long name and corresponding group short name
- Updates the
GROUP_group short name
In Alfresco 2.x the authority is stored directly in the
alf_access_control_entry table as well so the update statement would be a bit more complicated.
Drop the Temp Table
DROP TABLE t_ldap_groups;
So far we haven’t had any adverse effects on our development server doing things this way but if anyone has a better method or potential issues with this one let us know.