Developer Help: Fixing a Document That Couldn’t be Unlocked in Alfresco
by Jeff Rosler
Recently, I was working in an Alfresco 5.0.3 environment and wanted to update a document. I checked the file out in the Alfresco Share interface, but somehow I was able to delete its working copy without cleaning up the original node. I hit backspace and did a cancel checkout or something in Share that caused the problem.
At any rate, my unintended action caused my document to disappear from the Share document list. When I performed a simple search to find the document, I saw it in the search results. Clicking on the document from the search results list got me to a document details page that showed the preview but didn’t have any options. There was a message at the top of the Share page that seemed to suggest that the file might be deleted.
When I used the Node Browser within the admin tools in Share (https://docs.alfresco.com/5.0/tasks/admintools-nodebrowser.html) to find the file and look at it, I noticed that it was locked by me and had the cm:checkedOut aspect on it.
I thought the best way to fix this was to use the JavaScript console to cancelCheckout with some simple JavaScript code. If you haven’t installed this in your Alfresco environment, you might consider doing so. It can be a lifesaver in situations like this (see https://community.alfresco.com/docs/DOC-7431-javascript-console for information about it). Having said that, as always, consider what open source extensions you want to add to your systems.
Unfortunately, running a cancelCheckout on the node failed with no permission even though I was in the admin group. After looking at the docs, I realized cancelCheckout is supposed to be called only on the working object so it wasn’t surprising that it failed. I tried several other things, including unlock and removing the cm:checkedOut aspect, but couldn’t get anything to work.
After scratching my head about this, I spoke to one of my colleagues and he thought that removing the cm:checkedOut aspect and performing an unlock was the right way forward, but because the working copy was missing, an Alfresco behavior was stopping me from performing those actions. So, the way to get around this was to temporarily disable behaviors.
But how can behaviors be disabled? Luckily, you can get the application context within the JavaScript console and, if you know the name of your bean, you can get the object referenced by that bean. Looking around, I saw that the BehaviourFilter bean was named policyBehaviourFilter. I also looked at the Java docs for BehaviourFilter and saw the disableAllBehaviours() and enableAllBehaviours() methods. All that was needed then was to put this all together.
// get the node (found the node ref via a search and pasted it here)
var foundNode = search.findNode(“workspace://SpacesStore/XXXXXXXX-5fXX-XX6a-bXXf-7XXX47bdXXXX”);
// get web application context, so I can use that to get the behaviour filter object via it’s bean name
var ctx = Packages.org.springframework.web.context.ContextLoader.getCurrentWebApplicationContext();
// get the behavior filter object
var filter = ctx.getBean(‘policyBehaviourFilter’, org.alfresco.repo.policy.BehaviourFilter);
// turn off all behaviours, so I can remove the aspect without getting stopped by validation
filter.disableAllBehaviours();
// perform the remove aspect and unlock which failed previously with behaviors turned on
foundNode.removeAspect(‘cm:checkedOut’);
foundNode.unlock();
// turn behaviours back on
filter.enableAllBehaviours();
The above code snippet allowed me to fix my document. After running this, the document was again visible in Alfresco Share and was back to normal.
For help with your ECM questions, contact us today.