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

cm:tagScopeCache properties is set to NULL when all tag(s) being removed from Site (st:site) node tree


    • Type: Service Pack Request
    • Status: Closed (View Workflow)
    • Resolution: Not a bug
    • Affects Version/s:
    • Fix Version/s: None
    • Component/s: Tags and Categories
    • Labels:
    • Bug Priority:
      Category 3
    • ACT Numbers:



      Outstanding question/Business Impact

      Customer wants to know why did the cm:tagScopeCache property is set to NULL instead of being totally removed like cm:tagScopeSummary property when tag scope count is set from > 0 back to 0? Is this by design behavior or bug?

      This behavior has caused the customer's custom script for not able to run properly at all time due to the NULL value.

      Current observed product design

      cm:tagScopeCache properties is part of cm:tagScope aspect which is added to all Site node by default.

      When a new site is created, cm:tagScope aspect is applied by default. One do not see any cm:tagScopeCache and cm:tagScopeSummary property associate to st:site node until first tag is being created for any of the site content under Site Document Library.

      When site user create the first tag for any of the content/folder node within Site nodes, one will see Site Node properties has two new properties added:

      cm:tagScopeCache | d:content | contentUrl=store://2017/1/25/14/23/dba1b1f9-6b0d-4738-a099-25a242b7ea72.bin|mimetype=text/plain|size=6|encoding=UTF-8|locale=en_US_|id=303 
      cm:tagScopeSummary | d:text | Collection: tag1=1

      If you remove all tags from folder child node within the Site (st:site) node, it will read then change to:

      cm:tagScopeCache | d:content | null and no longer displayed cm:tagScopeSummary properties. 

      If you then add the tag back to it, it will display the cm:tagScopeCache with content url and cm:tagScopeSummary again with the updated tagScopeSummary.

      Steps to reproduce

      1. in, deploy custom model into your Alfresco from FTP location.
      2. Login to Alfresco Share and create a new site.
      3. Double check in Node Browser that the site node does not have cm:tagScopeCache properties.
      4. Navigate to the newly created site, add content and folder under site document library, add a new tag to either content or folder item.
      5. Double check in Node browser that the site node now does have cm:tagScopeCache properties.
        For example, 
        cm:tagScopeCache | d:content | contentUrl=store://2017/1/25/14/23/dba1b1f9-6b0d-4738-a099-25a242b7ea72.bin|mimetype=text/plain|size=6|encoding=UTF-8|locale=en_US_|id=303 
      6. Next, delete the previously created tags from the site > document library > folder/content node(s).
      7. Double check in Node Browser that the site node now have cm:tagScopeCache properties modify to 'null' while cm:tagScopeSummary properties is removed.
        For example, 
        cm:tagScopeCache | d:content | null 
      8. Now, run the custom js script (found in FTP location) which customer have provided using Javascript Console or Folder rule.
        • Expected: Script run failed with an error returned: Object cannot be null.
        • Actual: Script run failed as expected, with error:
      2017-01-25 14:49:00,426 ERROR [extensions.webscripts.AbstractRuntime] [http-apr-8080-exec-9] Exception from executeScript - redirecting to status template error: Object cannot be null. 
      java.lang.NullPointerException: Object cannot be null. 
      at com.hazelcast.impl.Util.checkSerializable(Util.java:39) 
      at com.hazelcast.impl.MProxyImpl.check(MProxyImpl.java:473) 
      at ... 

      Root Cause Analysis
      the NullPointerException error relevant to cache, I validated this null value for cm:tagScopeCache being the root cause after tested following workaround.


      1. Add a new tag back to any site node child folder/content.
      2. Double check the cm:tagScopeCache properties value on site node is now changed from null to contentURL value and there are no other properties fields with NULL value.
      3. Now. rerun the same custom js script which failed previously.
        • Expected: The script should run without problem this time once we remove the null value from site node properties
        • Actual: Script does run successfully.





              • Assignee:
                closedissues Closed Issues
                sliaw Seng Liaw
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created:

                  Structure Helper Panel