cancel
Showing results for 
Search instead for 
Did you mean: 

Comparison between file names during CheckIn

morganp1
Confirmed Champ
Confirmed Champ
Hi everybody,


This post concern the Alfresco Community Edition version 4.2.c but I think this can be extend to all Alfresco versions.


I'm currently trying to develop a small feature to prevent Alfresco users to overwrite the content of a wrong file during a CheckOut/CheckIn. I already blocked the default edition actions of Alfresco to require all users to go through a CheckOut/CheckIn to edit a document.


However, during a CheckIn (by default), Alfresco does not compare the name of the file in the Repository with the name of the file in your local computer (the one you are trying to CheckIn). That behavior can cause some issues… Indeed, a user can easily overwrite the content of the file A with the content of the file B during the CheckIn of A.


So what I'm trying to do is to compare the name of the file in the Repository (let's say "File_A.txt") with the name of the file that is CheckedIn (e.g "File_A_v2.txt"). By default, a Working Copy is also created in the Repository with the name of "File_A (Working Copy).txt". At the end, I would like to prevent a user to CheckIn a file (from his computer) if the name of the file A (in the repository) isn't contained in the name of this file => the CheckIn of "File_A_v2.txt" would be authorized but not the one of "File_B_v3.txt".


To do that, I tried to add a custom behavior (Java Class) which implements "CheckOutCheckInServicePolicies.BeforeCheckIn". In this Java Class, I'm able to retrieve all information about the nodes in the Repository (the nodeRef & the workingCopyNodeRef) but I'm unable (or I didn't find out how) to retrieve the name of the file that is CheckedIn.


Does someone know how this can be done? Maybe I'm not looking in the right direction but I thought if I could get the name of the imported file, it would be somewhere around there.


Just for information, my Java code looks like that:

public class CompareNamesBehavior implements CheckOutCheckInServicePolicies.BeforeCheckIn {
   …
   public void init() {
   …
      policyComponent.bindClassBehaviour(CheckOutCheckInServicePolicies.BeforeCheckIn.QNAME, ContentModel.ASPECT_WORKING_COPY, new JavaBehaviour(this, "beforeCheckIn"));
   …
   }
   public void beforeCheckIn(NodeRef workingCopyNodeRef, Map<String, Serializable> versionProperties, String contentUrl, boolean keepCheckedOut) {
      NodeRef nodeRef = getCheckedOut(workingCopyNodeRef);
      logger.info("NodeRef Name = " + (String) nodeService.getProperty(nodeRef, ContentModel.PROP_NAME));
      logger.info("WorkingCopyNodeRef Name = " + (String) nodeService.getProperty(workingCopyNodeRef, ContentModel.PROP_NAME));
      logger.info("WorkingCopyNodeRef Label = " + (String) nodeService.getProperty(workingCopyNodeRef, ContentModel.PROP_WORKING_COPY_LABEL));
   }
   …
}



Best regards,
Morgan

3 REPLIES 3

mlagneaux
Champ on-the-rise
Champ on-the-rise
Hi,

Let's say you have a file A.txt that has been checked out. Then you also have a file A(working copy).txt. As soon as this working copy is updated, you loose the name of the local file that has been used for the update : this information is lost.

I think that a better solution would be to control that the names of the local file and the Alfresco node are the same when an update of the working copy is done.

Hi mlagneaux,

Sure, you are right and this is what I want to do but the thing is that I don't really know where this verification can be done. If you take a look at the <a href="https://github.com/Alfresco/community-edition/blob/master/projects/repository/source/java/org/alfres...">org.alfresco.repo.coci.CheckOutCheckInServiceImpl.java</a>, you will see that the BeforeCheckIn is called before to copy the content of the WorkingCopy back into the Original Node… I don't know where does the content of the local file is copied to the WorkingCopy node.

Regards,
Morgan

Hi,

Maybe you can use the ContentServicePolicies#OnContentUpdatePolicy or NodeServicePolicies#OnUpdateNodePolicy and link your behaviour to the working copy aspect.