Uploaded image for project: 'Addon Channel Manager'
  1. Addon Channel Manager
  2. CHANNELMGR-1775

Rich text fields used as a list-based choice are broken

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Top
    • Resolution: Fixed
    • Affects Version/s: 5.1.0, 5.2.0, 5.3.0
    • Fix Version/s: 5.3.0
    • Labels:
      None
    • Similar issues:
    • Story Points:
      5
    • Sprint:
      Tiger Sprint 179
    • Processed by team:
      Tiger

      Description

      A rich text field can be used as a choice in a choice field (a.k.a. content block). These choices can be configured list-based, i.e. configured in a comma-separated string of JCR types, like the Interviews field in the Christmas Tree Document in the HAP. In that case, the generic configuration of the field type should be used for the choice. However, the current implementation does not read this generic configuration. As a result, the frontend tries to read a property that does not exist, and the field itself cannot be edited in the Visual Editor. 

      Steps to reproduce:

      1. In the HAP, edit the Christmas Tree Document in the Content perspective
      2. Locate an "Interviews" field. It can add three types of choices: "Real Estate", "Employee", and "Rich Text Editor"
      3. Add a "Rich Text Editor" and enter some text in it.
      4. Save & Close the document.
      5. Edit the Christmas Tree Document in the Channel Manager.
      6. Locate the added Rich Text Field in the Interviews field.

      Expected: the field shows the entered text, and can be edited as any other HTML field

      Actual: the field is empty and cannot be edited. No toolbar appears when the field is clicked. The JavaScript console logs the following error:

      angular.js?10a4:14199 TypeError: Cannot set property 'sharedSpaces' of undefined
          at CKEditorService.loadCKEditor.then.CKEDITOR (ckeditor.controller.js?1164:48)
          at processQueue (angular.js?10a4:16696)
          at eval (angular.js?10a4:16712)
          at Scope.$eval (angular.js?10a4:17994)
          at Scope.$digest (angular.js?10a4:17808)
          at Scope.$apply (angular.js?10a4:18102)
          at done (angular.js?10a4:12082)
          at completeRequest (angular.js?10a4:12291)
          at XMLHttpRequest.requestLoaded (angular.js?10a4:12219)

      The other fields still function normally, so I won't consider this a blocker.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mdenburger Mathijs den Burger
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: