Details

    • Epic Name:
      RichText editing

      Description

      Current XMLtext field type uses the old xmltext ezxml format, a better approach in the future would be to use and update the Document component so it handles the internal format instead (docbook).

      Format

      The Field Type may expose several formats like intended with eZ Document Component, but for WYSIWYG editors and web use there is a need to have a xhtml5 like format that has all the capabilities of ezxml or even more.

      A xhtml5 wysiwyg format could be based on ezxml but with some changes:

      • Tag names should be changed to names in html5, most are easy, custom tag is not.
      • Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
      • Attribute names should be aligned with html5 (map custom attribute to -data-?)
      • Valid parent and child tags might need some minor adjustments, table in paragraphs for instance.
      • As for section tags, that can be mapped to the html5 section tag, and this can be visually hinted by the editor in needed: http://www.tinymce.com/tryit/html5_formats.php

      For Legacy Database there could be a converter that transforms the format to ezxml, if eZ Document Component is used then it needs some updates for minor changes done to the format in 4.1.

        Issue Links

          Issues in Epic

            Activity

            André Rømcke created issue -
            André Rømcke made changes -
            Field Original Value New Value
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we update our format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to -data-?)

            The transformation to eZXMLText format, should be done by legacy field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to -data-?)

            The transformation to eZXMLText format, should be done by legacy field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to -data-?)

            The transformation to eZXMLText format, should be done by legacy field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            The transformation to eZXMLText format, should be done by legacy field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            The transformation to eZXMLText format, should be done by legacy field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Christian Bacher (Inactive) made changes -
            Status Open [ 1 ] Backlog [ 10000 ]
            Christian Bacher (Inactive) made changes -
            Status Backlog [ 10000 ] InputQ [ 10001 ]
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            André Rømcke made changes -
            Link This issue relates to EZPNEXT-44 [ EZPNEXT-44 ]
            André Rømcke made changes -
            Workflow PM Kanban [ 11997 ] PM Kanban2 [ 12189 ]
            André Rømcke made changes -
            Workflow PM Kanban2 [ 12189 ] PM Kanban [ 12218 ]
            Christian Bacher (Inactive) made changes -
            Fix Version/s Kilimanjaro [ 10211 ]
            Christian Bacher (Inactive) made changes -
            Link This issue relates to PM-39 [ PM-39 ]
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter. Maybe using

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter. Maybe using

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter. Maybe using XSLT?

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            André Rømcke made changes -
            Rank Ranked lower
            André Rømcke made changes -
            Status InputQ [ 10001 ] Specification [ 10002 ]
            Assignee André Rømcke [ andre.romcke@ez.no ]
            André Rømcke made changes -
            Link This issue relates to EZPNEXT-779 [ EZPNEXT-779 ]
            Hide
            André Rømcke added a comment - - edited

            Possible requirements:

            • Polyglot Markup, aka both valid html5 & xml
            • Easily transformable using for instance xslt to transform to and from old and new format in Legacy converter.

            Reasoning for changing the format:

            • Writing OE 5.x was 1 year effort and still counting in terms of Support, if we can cut this down considerably by aligning our self with the format all future wysiwyg editors support: (x)html5, that will be worth it in terms of effort needed in the future on this FiledType.
            • Make it possible to more easily parse and deal with ezxml output in for instance REST clients
            Show
            André Rømcke added a comment - - edited Possible requirements: Polyglot Markup, aka both valid html5 & xml Easily transformable using for instance xslt to transform to and from old and new format in Legacy converter. Reasoning for changing the format: Writing OE 5.x was 1 year effort and still counting in terms of Support, if we can cut this down considerably by aligning our self with the format all future wysiwyg editors support: (x)html5, that will be worth it in terms of effort needed in the future on this FiledType. Make it possible to more easily parse and deal with ezxml output in for instance REST clients
            Hide
            Christian Bacher (Inactive) added a comment - - edited

            General Question: is changing the format in storage necessary?
            The conversions can be done anywhere else even above the public api.
            And there will be other conversions not necessarily to html5 for different applications.
            This leads more to a generic xml format which we already have (kind of).

            Show
            Christian Bacher (Inactive) added a comment - - edited General Question: is changing the format in storage necessary? The conversions can be done anywhere else even above the public api. And there will be other conversions not necessarily to html5 for different applications. This leads more to a generic xml format which we already have (kind of).
            Hide
            André Rømcke added a comment - - edited

            Never talked about changing format in Legacy storage, as for internal format that is an other discussion which Patrick did a design and requriment spec on:
            https://github.com/ezsystems/ezp-next/tree/Specification/eZXML5/doc/specifications/api/field_type/ezxmltext

            Re cap: Proposes to use Zeta Document component in the background with Docbook as internal format, convert to legacy ezxml in Legacy fieldtype Converter and convert to many different formats in the Public API (ezxml, "ezxml5", reST, wiki, markdown, xhtml, html5, ..).
            The main pieces of work that needs to be done is to update the ezxml support as it lacks features added in 4.1, and on top of that formats it does not already support (first and formost: "ezxml5").

            Show
            André Rømcke added a comment - - edited Never talked about changing format in Legacy storage, as for internal format that is an other discussion which Patrick did a design and requriment spec on: https://github.com/ezsystems/ezp-next/tree/Specification/eZXML5/doc/specifications/api/field_type/ezxmltext Re cap: Proposes to use Zeta Document component in the background with Docbook as internal format, convert to legacy ezxml in Legacy fieldtype Converter and convert to many different formats in the Public API (ezxml, "ezxml5", reST, wiki, markdown, xhtml, html5, ..). The main pieces of work that needs to be done is to update the ezxml support as it lacks features added in 4.1, and on top of that formats it does not already support (first and formost: "ezxml5").
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many things, and re implements things we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            We need to specify a xmlformat that is close to what we have today in eZ Publish, but in xhtml 5 dialect for easier integration with editors and the web.

            The format will still be in xml (ref "x"), but:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option:
            http://www.tinymce.com/tryit/html5_formats.php

            The transformation to eZXMLText format, should be done by Legacy Storage Engine field type converter. Maybe using XSLT?

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the following api's is probably not needed if format is simplified as mentioned above:
            setRawText
            getInputParser (has 10-14 public methods)
            getInputHandler (has 10 public methods)
            Current eZXMLtext field type exposes to many internals, and re implements features we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            The Field Type may expose several formats like intended with eZ Document Component, but for WYSIWYG editors and web use there is a need to have a xhtml5 like format that has all the capabilities of ezxml or even more, with some alignments with html5:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)
            * Valid parent and child tags might need some minor adjustments, table in paragraphs for instance.

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option: http://www.tinymce.com/tryit/html5_formats.php

            For Legacy there should be a converter that transforms the format to ezxml, if eZ Document Component is used then it needs some updates for minor changes doen to the format in 4.1.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the api should be minimized to no expose internal functionality.
            André Rømcke made changes -
            Assignee André Rømcke [ andre.romcke@ez.no ]
            André Rømcke made changes -
            Status Specification [ 10002 ] Specification done [ 10003 ]
            André Rømcke made changes -
            Status Specification done [ 10003 ] Development review [ 10006 ]
            André Rømcke made changes -
            Status Development review [ 10006 ] Backlog [ 10000 ]
            André Rømcke made changes -
            Fix Version/s Stetind [ 10212 ]
            Fix Version/s Kilimanjaro [ 10211 ]
            André Rømcke made changes -
            Summary New eZXMLText fieldType & format New RichText fieldType format
            André Rømcke made changes -
            Status Backlog [ 10000 ] InputQ [ 10001 ]
            André Rømcke made changes -
            Assignee André Rømcke [ andre.romcke@ez.no ]
            André Rømcke made changes -
            Description Current eZXMLtext field type exposes to many internals, and re implements features we most likely don't need anymore if we simplify and modernice our rich text format a bit.

            h3.Format
            The Field Type may expose several formats like intended with eZ Document Component, but for WYSIWYG editors and web use there is a need to have a xhtml5 like format that has all the capabilities of ezxml or even more, with some alignments with html5:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)
            * Valid parent and child tags might need some minor adjustments, table in paragraphs for instance.

            As for section tags, that can be mapped to the html5 section tag if we want to keep this feature, and rich text editors, this can be visually hinted with an option: http://www.tinymce.com/tryit/html5_formats.php

            For Legacy there should be a converter that transforms the format to ezxml, if eZ Document Component is used then it needs some updates for minor changes doen to the format in 4.1.

            h3.Fieldtype
            Besides exposing the legacy xmltext format, the api should be minimized to no expose internal functionality.
            Current XMLtext field type uses the old xmltext ezxml format, a better approach in the future would be to use and update the Document component so it handles the internal format instead (docbook).

            h3.Format
            The Field Type may expose several formats like intended with eZ Document Component, but for WYSIWYG editors and web use there is a need to have a xhtml5 like format that has all the capabilities of ezxml or even more.

            A xhtml5 wysiwyg format could be based on ezxml but with some changes:
            * Tag names should be changed to names in html5, most are easy, custom tag is not.
            * Tags should behave as in html5 (inline / block / inline-block), and custom tags should be able to be one of these.
            * Attribute names should be aligned with html5 (map custom attribute to \-data\-?)
            * Valid parent and child tags might need some minor adjustments, table in paragraphs for instance.
            * As for section tags, that can be mapped to the html5 section tag, and this can be visually hinted by the editor in needed: http://www.tinymce.com/tryit/html5_formats.php

            For Legacy Database there could be a converter that transforms the format to ezxml, if eZ Document Component is used then it needs some updates for minor changes done to the format in 4.1.
            André Rømcke made changes -
            Fix Version/s Aconcagua [ 10213 ]
            Fix Version/s Stetind [ 10212 ]
            André Rømcke made changes -
            Assignee André Rømcke [ andre.romcke@ez.no ]
            André Rømcke made changes -
            Epic Name RichText FieldType
            André Rømcke made changes -
            Epic Colour #fdf4bb
            André Rømcke made changes -
            Epic Colour #fdf4bb #f1f1f1
            André Rømcke made changes -
            Rank Ranked higher
            André Rømcke made changes -
            Rank Ranked higher
            Christian Bacher (Inactive) made changes -
            Fix Version/s Ventoux [ 10214 ]
            Fix Version/s Aconcagua [ 10213 ]
            Christian Bacher (Inactive) made changes -
            Fix Version/s Ventoux [ 10214 ]
            André Rømcke made changes -
            Workflow PM Kanban [ 12218 ] TPM Kanban [ 52990 ]
            Status InputQ [ 10001 ] Open [ 1 ]
            André Rømcke made changes -
            Workflow TPM Kanban [ 52990 ] GreenHopper Simplified Workflow for Project PM [ 55739 ]
            André Rømcke made changes -
            Summary New RichText fieldType format RichText editor 5.x
            André Rømcke made changes -
            Fix Version/s Aconcagua [ 10213 ]
            André Rømcke made changes -
            Rank Ranked higher
            André Rømcke made changes -
            Link This issue relates to EZPFT-619 [ EZPFT-619 ]
            André Rømcke made changes -
            Epic Child EZP-21136 [ 34653 ]
            André Rømcke made changes -
            Epic Child EZP-21191 [ 34886 ]
            André Rømcke made changes -
            Epic Child EZP-21319 [ 35261 ]
            André Rømcke made changes -
            Epic Child EZP-21320 [ 35263 ]
            André Rømcke made changes -
            Status Open [ 1 ] Development [ 3 ]
            André Rømcke made changes -
            Assignee Petar Spanja [ petar.spanja@ez.no ]
            André Rømcke made changes -
            Epic Colour #f1f1f1 #eacac6
            André Rømcke made changes -
            Fix Version/s Ventoux [ 10214 ]
            Fix Version/s Aconcagua [ 10213 ]
            André Rømcke made changes -
            Epic Child EZP-22216 [ 39325 ]
            André Rømcke made changes -
            Epic Child EZP-21315 [ 35257 ]
            Petar Spanja (Inactive) made changes -
            Epic Child EZP-22443 [ 39918 ]
            André Rømcke made changes -
            Fix Version/s Ventoux [ 10214 ]
            André Rømcke made changes -
            Epic Child EZP-22663 [ 40714 ]
            André Rømcke made changes -
            Summary RichText editor 5.x RichText editor in Platfrom
            André Rømcke made changes -
            Summary RichText editor in Platfrom RichText editor in Platform
            Hide
            André Rømcke added a comment -

            Comments above are out of date, look to #EZP-21136 and #EZP-21191 for what we ended up with after prototyping.

            Show
            André Rømcke added a comment - Comments above are out of date, look to # EZP-21136 and # EZP-21191 for what we ended up with after prototyping.
            André Rømcke made changes -
            Project eZ Release Overview [ 10100 ] eZ Publish [ 10401 ]
            Key PM-21 EZP-22949
            Workflow Agile Simplified Workflow for Project PM [ 55739 ] EZ* EPIC Workflow [ 63423 ]
            André Rømcke made changes -
            Summary RichText editor in Platform RichText editing in Platform
            André Rømcke made changes -
            Summary RichText editing in Platform RichText editing
            Pedro Resende (Inactive) made changes -
            Epic Child EZP-23059 [ 41547 ]
            Anonymous made changes -
            Status Development [ 3 ] Que [ 10035 ]
            Anonymous made changes -
            Status Que [ 10035 ] Specification [ 10002 ]
            Anonymous made changes -
            Status Specification [ 10002 ] QA [ 10008 ]
            Anonymous made changes -
            Status QA [ 10008 ] Development review [ 10006 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Development review [ 10006 ] Deploy [ 10009 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Deploy [ 10009 ] Open [ 1 ]
            Anonymous made changes -
            Status Open [ 1 ] Doc [ 10036 ]
            Anonymous made changes -
            Status Doc [ 10036 ] Development [ 3 ]
            André Rømcke made changes -
            Fix Version/s Pollux [ 13981 ]
            André Rømcke made changes -
            Status Development [ 3 ] Que [ 10035 ]
            André Rømcke made changes -
            Epic Name RichText FieldType RichText editing
            André Rømcke made changes -
            Epic Child EZP-23814 [ 43349 ]
            André Rømcke made changes -
            Epic Child EZP-23815 [ 43350 ]
            André Rømcke made changes -
            Epic Child EZP-23831 [ 43475 ]
            André Rømcke made changes -
            Epic Child EZP-23832 [ 43476 ]
            André Rømcke made changes -
            Component/s PlatformUI [ 10301 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24078 [ 44103 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-23831 [ 43475 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-23831 [ 43475 ]
            André Rømcke made changes -
            Status Que [ 10035 ] Development [ 3 ]
            André Rømcke made changes -
            Status Development [ 3 ] Que [ 10035 ]
            André Rømcke made changes -
            Remote Link This issue links to "Page (eZ Documentation)" [ 15008 ]
            André Rømcke made changes -
            Rank Ranked higher
            André Rømcke made changes -
            Priority High [ 3 ] Blocker [ 1 ]
            André Rømcke made changes -
            Assignee Petar Spanja [ petar.spanja@ez.no ]
            André Rømcke made changes -
            Assignee Damien Pobel [ damien.pobel@ez.no ]
            André Rømcke made changes -
            Status Que [ 10035 ] Development [ 3 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24378 [ 44867 ]
            André Rømcke made changes -
            Epic Child EZP-24423 [ 44953 ]
            André Rømcke made changes -
            Workflow EZ* EPIC Workflow [ 63423 ] EZ* EPIC Workflow2 [ 86600 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24507 [ 50298 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24531 [ 50404 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24532 [ 50405 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24723 [ 51129 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24712 [ 51081 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24724 [ 51131 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24725 [ 51132 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24731 [ 51172 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24732 [ 51175 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24768 [ 51346 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24777 [ 51362 ]
            André Rømcke made changes -
            Link This issue is cloned by EZP-24795 [ EZP-24795 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24732 [ 51175 ]
            Bertrand Dunogier made changes -
            Link This issue is cloned by EZP-24795 [ EZP-24795 ]
            Bertrand Dunogier made changes -
            Link This issue is blocked by EZP-24795 [ EZP-24795 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24894 [ 51651 ]
            Anonymous made changes -
            Status Development [ 3 ] Open [ 1 ]
            Anonymous made changes -
            Status Open [ 1 ] Specification [ 10002 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Specification [ 10002 ] Deploy [ 10009 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Deploy [ 10009 ] QA [ 10008 ]
            Anonymous made changes -
            Status QA [ 10008 ] Documentation [ 10010 ]
            Anonymous made changes -
            Status Documentation [ 10010 ] Accepted Scheduled [ 10014 ]
            Anonymous made changes -
            Status Accepted Scheduled [ 10014 ] Research [ 10021 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24950 [ 51769 ]
            Anonymous made changes -
            Status Research [ 10021 ] Accepted Scheduled [ 10014 ]
            Anonymous made changes -
            Status Accepted Scheduled [ 10014 ] Development [ 3 ]
            Anonymous made changes -
            Status Development [ 3 ] Specification [ 10002 ]
            Anonymous made changes -
            Status Specification [ 10002 ] Open [ 1 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Open [ 1 ] Deploy [ 10009 ]
            Anonymous made changes -
            Status Deploy [ 10009 ] Documentation [ 10010 ]
            Anonymous made changes -
            Resolution Done [ 9 ]
            Status Documentation [ 10010 ] QA [ 10008 ]
            Anonymous made changes -
            Status QA [ 10008 ] Research [ 10021 ]
            André Rømcke made changes -
            Status Research [ 10021 ] Specification [ 10002 ]
            André Rømcke made changes -
            Status Specification [ 10002 ] Development [ 3 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25108 [ 52219 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25135 [ 52287 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25136 [ 52288 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25137 [ 52289 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25138 [ 52290 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25139 [ 52292 ]
            André Rømcke made changes -
            Summary RichText editing Basic RichText editing
            André Rømcke made changes -
            Status Development [ 3 ] Documentation [ 10010 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25136 [ 52288 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25135 [ 52287 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-24724 [ 51131 ]
            Bertrand Dunogier made changes -
            Epic Child EZP-25000 [ 51918 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25000 [ 51918 ]
            Show
            Dominika Kurek added a comment - Documented in User Guide: https://doc.ez.no/display/USER/Creating+content#Creatingcontent-EditingRichTextFields
            Dominika Kurek made changes -
            Status Documentation [ 10010 ] QA [ 10008 ]
            Damien Pobel (Inactive) made changes -
            Epic Child EZP-25137 [ 52289 ]
            Damien Pobel (Inactive) made changes -
            Assignee Damien Pobel [ damien.pobel@ez.no ]
            Transition Time In Source Status Execution Times Last Executer Last Execution Date
            Open Open Backlog Backlog
            22m 17s 1 Christian Bacher (Inactive) 14/Mar/12 9:02 PM
            InputQ InputQ Specification Specification
            148d 18h 56m 1 André Rømcke 10/Aug/12 4:59 PM
            Specification Specification Specification Done Specification Done
            95d 20h 39m 1 André Rømcke 14/Nov/12 12:39 PM
            Specification Done Specification Done Development Review Development Review
            15s 1 André Rømcke 14/Nov/12 12:39 PM
            Development Review Development Review Backlog Backlog
            5s 1 André Rømcke 14/Nov/12 12:39 PM
            Backlog Backlog InputQ InputQ
            1m 53s 2 André Rømcke 14/Nov/12 12:41 PM
            InputQ InputQ Open Open
            147d 16m 1 André Rømcke 10/Apr/13 1:58 PM
            Open Open Development Development
            105d 1h 49m 1 André Rømcke 24/Jul/13 3:47 PM
            Removed Status Removed Status Specification Specification
            7s 1 16/Aug/14 8:13 AM
            Specification Specification QA QA
            2m 14s 1 16/Aug/14 8:15 AM
            QA QA Development Review Development Review
            21s 1 16/Aug/14 8:15 AM
            Development Review Development Review Deploy Deploy
            1m 20s 1 16/Aug/14 8:17 AM
            Deploy Deploy Open Open
            1m 43s 1 16/Aug/14 8:18 AM
            Open Open Removed Status Removed Status
            29s 1 16/Aug/14 8:19 AM
            Development Development Removed Status Removed Status
            602d 4h 39m 3 André Rømcke 23/Mar/15 4:46 PM
            Removed Status Removed Status Development Development
            61d 13h 23m 3 André Rømcke 19/May/15 9:56 AM
            Development Development Open Open
            145d 10h 1 11/Oct/15 7:57 PM
            Open Open Specification Specification
            0s 1 11/Oct/15 7:57 PM
            Specification Specification Deploy Deploy
            1s 1 11/Oct/15 7:57 PM
            Deploy Deploy QA QA
            0s 1 11/Oct/15 7:57 PM
            QA QA Documentation Documentation
            0s 1 11/Oct/15 7:57 PM
            Documentation Documentation Accepted Scheduled Accepted Scheduled
            0s 1 11/Oct/15 7:57 PM
            Accepted Scheduled Accepted Scheduled Research Research
            1s 1 11/Oct/15 7:57 PM
            Research Research Accepted Scheduled Accepted Scheduled
            18d 22h 16m 1 30/Oct/15 5:13 PM
            Accepted Scheduled Accepted Scheduled Development Development
            1h 10m 1 30/Oct/15 6:24 PM
            Development Development Specification Specification
            14m 9s 1 30/Oct/15 6:38 PM
            Specification Specification Open Open
            1h 4m 1 30/Oct/15 7:42 PM
            Open Open Deploy Deploy
            1h 1m 1 30/Oct/15 8:43 PM
            Deploy Deploy Documentation Documentation
            28m 19s 1 30/Oct/15 9:12 PM
            QA QA Research Research
            1m 26s 1 30/Oct/15 10:12 PM
            Research Research Specification Specification
            16d 11h 52m 1 André Rømcke 16/Nov/15 10:05 AM
            Specification Specification Development Development
            13s 1 André Rømcke 16/Nov/15 10:05 AM
            Development Development Documentation Documentation
            50d 7h 19m 1 André Rømcke 05/Jan/16 5:24 PM
            Documentation Documentation QA QA
            180d 18h 53m 2 Dominika Kurek 04/Jul/16 12:19 PM

              People

              • Assignee:
                Unassigned
                Reporter:
                André Rømcke
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: