Feature 2.4/rm 2700 community on enterprise
Added module compatibility component that inspects the installed core and rm modules and determines if there is an incompatibility or not.
The application context is closed if there is an issue and an error logged/reported.
See merge request !49
- issue title: Copy/Move/Link actions don't take place and errors are thrown when running rules that perform them.
- regression caused by RM-2072 merged forward from v2.2
- the retrying transaction helper was missing from copyTo, moveTo and linkTo beans and was causing NullPointerException
- createOrResolvePath method calls getContext on a node created in the current transaction which is not visible in the new transaction and it throws a FileNotFoundException
- solution: I moved the creation of the new transaction after the context was retrieved as the concurrency exception reported in RM-2072 was being caused by property updates
Feature 2.4/rm 2937 record destruction keeping metadata
RM-2937 - The destruction of records can not be completed if the metadata is set to be maintained after destruction.
The issue reproduces only if image magic is correctly installed. If the node to be destroyed has associated renditions cleaning the rendition's content is failing because there is no capability to allow the operation. This in a regression from 2.3 where method security was disabled for the class that was deleting the thumbnails.
The code has been refactored in 2.4 and the content cleaning is performed in a new class. ExtendedContentDestructionComoponent uses the NodeService interface which enforces method security. ExtendedContentDestructionComoponent extends ContentDestructionComoponent from community which uses the nodeService implementation. I fixed it by using the implementation directly.
After fixing the issue I noticed the renditions nodes are not deleted which is a regression from 2.3 and there is no comment to specify this was intended so I deleted the rendition node.
I noticed that the method ContentDestructionComponent.destroyContent has the parameter includeRenditions which is not being used in the code. We are deleting the rendition even if this boolean is set to false. Should I fix it with this issue or should we raise another issue for this problem. Please advise.
See merge request !39
Feature 2.4/rm 2996 upload unfiled reacords with rule on file plan
RM-2996 - Files can not be uploaded in Unfiled Records if the File Plan has rules defined applying to sub-folders
The execution of rules as well as RM's RecordsManagementContainer.onCreateChildAssociation behavior fire before transaction commit and is unpredictable which one will run first. If the rule runs first the newly uploaded node doesn't have rma:filePlanComponent set at the time the method shouldRuleBeAppliedToNode executes. Calling recordService.isFiled(nodeRef)) will trigger capability check among which ViewRecordsCapability will check if the record has the rma:filePlanComponent aspect.
As a fix I ran the code from shouldRuleBeAppliedToNode method as system to avoid capability check.
I am aware the fix is a workaround but I think this is part of a bigger problem. The rules are fired before transaction commit and may conflict with other behaviors registered on transaction commit. However, we cannot add the aspect earlier in RM.
See merge request !37
- removed nodeService and eagerContentStoreCleaner from rm.contentDestructionComponent bean as they are already set on contentDestructionComponent
- fixed the ignored boolean
- ExtendedContentDestructionComoponent uses the NodeService interface which enforces capability check. ExtendedContentDestructionComoponent extends ContentDestructionComoponent from community which uses the nodeService implementation. I fixed it by using the implementation directly.
- After fixing the issue I noticed the renditions nodes are not deleted which is a regression from 2.3 and there is no comment to specify this was intended so I deleted the rendition node.
- recordService.isFiled(nodeRef) fires capability check which conflicts with RM behavior so I run shouldRuleBeAppliedToNode code as system to skip capability check
- this approach is a workaround
