Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-16116

Solr Indexing Fails when updating a node with a second content property

    Details

      Description

      Description

      Technical Description of the issue:
      A document is no longer indexed after a second content property is added and set.

      Customer's Description of the problem:
      "In Alfresco 5.1 if a node contains a content property, the node drops out of the Solr index as soon as the node properties are modified or the node is checked out."

      Supporting evidence

      Steps to reproduce

      1. Load/activate the following content model definition to create an aspect that contains a content property:

      <?xml version="1.0" encoding="utf-8"?>
      <model name="tst:model" xmlns="http://www.alfresco.org/model/dictionary/1.0">
      	<description>Additional content property</description>
      	<version>1.0</version>
      	<imports>
      		<import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d" />
      		<import uri="http://www.alfresco.org/model/content/1.0" prefix="cm" />
      		<import uri="http://www.alfresco.org/model/rendition/1.0" prefix="rn" />
      	</imports>
      	<namespaces>
      		<namespace uri="http://www.test.com/model/tst/1.0" prefix="tst" />
      	</namespaces>
      	<aspects>
      		<aspect name="tst:renditioned">
      			<title>Renditioned Node</title>
      			<properties>
      				<property name="tst:rendition">
      					<title>Rendition</title>
      					<type>d:content</type>
      					<index enabled="false">
      						<atomic>false</atomic>
      						<stored>false</stored>
      						<tokenised>false</tokenised>
      					</index>
      				</property>
      			</properties>
      		</aspect>
      	</aspects>
      </model> 
      

      2. Create a simple text document named test1.txt
      3. Create another simple text document named test2.txt, which will be the content property attached to test1.txt.
      4. Search for "test1".
      5. Run the following javascript to apply the aspect, and set the content property (replace the noderef's accordingly):

      //
      // Add content property to a document
      //
      
      // Original document (e.g., test1.txt)
      var doc = utils.getNodeFromString("workspace://SpacesStore/669f85bf-6423-4114-9868-356a45be7647");
      
      // Content property. It is a document that already exists in the repo (e.g., test2.txt)
      var contentProp = utils.getNodeFromString("workspace://SpacesStore/ac0b5768-a8d1-4f1c-a4bc-12fbcd47d2e7");
      
      // Add aspect with second content property
      doc.addAspect("tst:renditioned");
      
      // Set content property
      var prop = contentProp.properties.content;
      logger.log ("Content property: " + prop);
      doc.properties["tst:rendition"] = prop;
      doc.save();
      

      6. Use the node browser to confirm that the propert "tst:rendition" is set.
      7. Search for "test1" again

      Expected Behaviour
      Step 7. File "test1.txt" should be returned.

      Observed Behaviour
      Step 7. File "test1.txt" is not found.

      Analysis to date
      The partner wrote that "... the node drops out of the Solr index as soon as the node properties are modified or the node is checked out." During my testing I didn't have to change a property or check out the node, because the node would no longer be indexed by simply adding the content property (no further action was needed).

      A possible workaround would be to create association to the node, but the content property allows to have renditions that are versioned. Using associations would add a layer of complexity. Points made by the partner:

      • Aside from the elegance of the code, we'd have to hide the PDF renditions somewhere in the repository so that users don't accidentally overwrite or delete them.
      • It would be a large amount of rework on our side to sidestep the bug, while also introducing differences in our codebase for Alfresco 5.1 and above vs older releases of alfresco.
      • If later versions of Alfresco fix the issue, it would only exacerbate the previous issue. We'd have to keep separate versions of our codebase for the versions that this bug affects.
      • Going this route would essentially mean that Alfresco no longer supports content properties as of Alfresco 5.1. If Alfresco has any other customers that use content properties, they will be affected too.

      Customer business impact / priority / urgency
      Very critical for partner, which is trying to deploy their solution on Alfresco 5.1 for their customer. This issue has been escalated.
      "This second content property is critical to satisfy the requirements of most of our client solutions. TSG will be unable to recommend Alfresco 5.1 to any of our clients until this issue is resolved."

      Ideal Fix Version:
      5.1.0

        Attachments

          Issue Links

            Structure

              Activity

                People

                • Assignee:
                  closedbugs Closed Bugs (Inactive)
                  Reporter:
                  lcolorado Luis Colorado [X] (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  6 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 2 hours
                    2h

                      Structure Helper Panel