Content
View differences
Updated by Judith Roth 6 months ago
We need to decide on the markdown representation of the new rich-link work package blocks.
We want to do better than the previous implementation in CKEditor did. And we also probably should embed some information about the Block itself ([at least the ID](https://www.blocknotejs.org/docs/foundations/document-structure#blocks)) to be able to identify the Block later when (if) we ever try to update the YDoc from Markdown.
The markdown representation should also reflect the visual representation, at least representation. So far we defined [different visual representations](https://www.figma.com/design/d3zhm0R0pjHJvQd3XTlxuS/New-Documents-module?node-id=1367-40371&t=Iid5MIPMj4Y8qAPa-0) (which needed different space and offer different amounts of information). Based on the level setting chosen there, the markdown representation should probably also offer the same amount of information that is included (type, status, etc). information. (Caveat: for 17.0 we will probably implement only one representation).
With **CKEditor**, CKEditor, the markdown representation for a work package link looks like this:
`<mention class="mention" data-id="39" data-type="work_package" data-text="#39">#39</mention>`
`<mention class="mention" data-id="39" data-type="work_package" data-text="##39">##39</mention>`
`<mention class="mention" data-id="39" data-type="work_package" data-text="###39">###39</mention>`
The **current implementation** current implementation for the rich-link work package extension produces this markdown:
`[#39 - Work Package Title](/api/v3/work_packages/39)`
Which does neither include the type nor the status (which are included in the **visual representation from the designs** - for inline, only title, id and type, for block we show title, id, type and status): <br>
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/860562/content">
**Proposal**
I propose something in between - to still stay backwards compatible with external applications but also include the new information and have a nicer looking (rendered) markdown:
`<mention class="mention" data-id="38" data-id="39" data-type="work_package" data-block-id="123">[TYPE #38 (Status) Work data-block-id="123">[Work Package Title](_/api/v3/work_packages/39_)</mention>`
e.g.
`<mention class="mention" data-id="38" data-type="work_package" data-block-id="123">[FEATURE #38 (In development) Add dark theme support](_/api/v3/work_packages/39_)</mention>`
Which will probably look like this (depending on the markdown viewer):
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/860570/content">
I also attempted a 2-line block notation like in the visual representation, but it turned out to not look good with surrounding text. Title (TYPE) #39](/api/v3/work_packages/39)</mention>`
We want to do better than the previous implementation in CKEditor did. And we also probably should embed some information about the Block itself ([at least the ID](https://www.blocknotejs.org/docs/foundations/document-structure#blocks)) to be able to identify the Block later when (if) we ever try to update the YDoc from Markdown.
The markdown representation should also reflect the visual representation, at least
With **CKEditor**,
`<mention class="mention" data-id="39" data-type="work_package" data-text="#39">#39</mention>`
`<mention class="mention" data-id="39" data-type="work_package" data-text="##39">##39</mention>`
`<mention class="mention" data-id="39" data-type="work_package" data-text="###39">###39</mention>`
The **current implementation**
`[#39 - Work Package Title](/api/v3/work_packages/39)`
Which does neither include the type nor the status (which are included in the **visual representation from the designs** - for inline, only title, id and type, for block we show title, id, type and status):
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/860562/content">
**Proposal**
I propose something in between - to still stay backwards compatible with external applications but also include the new information and have a nicer looking (rendered) markdown:
`<mention class="mention" data-id="38"
e.g.
`<mention class="mention" data-id="38" data-type="work_package" data-block-id="123">[FEATURE #38 (In development) Add dark theme support](_/api/v3/work_packages/39_)</mention>`
Which will probably look like this (depending on the markdown viewer):
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/860570/content">
I also attempted a 2-line block notation like in the visual representation, but it turned out to not look good with surrounding text.