Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"View Source" functionality / plugin #592

Closed
mborejdo opened this issue Oct 6, 2017 · 108 comments
Closed

"View Source" functionality / plugin #592

mborejdo opened this issue Oct 6, 2017 · 108 comments

Comments

@mborejdo
Copy link

@mborejdo mborejdo commented Oct 6, 2017

Edit (by @Reinmar on 19 July 2021)

We've just released General HTML Support that resolves most of the issues mentioned in this thread.

Read more:

Edit (by @Reinmar on 7 March 2019)

This ticket covers the following three aspects:

  • The "edit source" mode known from CKEditor 4 (which is actually the trivial part).
  • Support for "free HTML" editing.
  • Ability to migrate content from CKEditor 4 to CKEditor 5.

This discussion is very long and will be confusing if you choose to read just a few random comments. However, you can jump directly to this comment to read about the current plans.

We want to keep this discussion clean, therefore we will be moderating and deleting low-quality comments. Please avoid "me too", "CKE5 is useless without it", etc. comments.

Type of comments that will be welcome:

  • Which HTML features are important for you. Snippets of HTML that you want CKE5 to support will tell us the most. Please be precise.
  • What's blocking you (precisely) to migrate from CKEditor 4 to CKEditor 5.
  • What could you sacrifice when migrating from CKEditor 4 to CKEditor 5. For instance, CKEditor 4 stores some information using inline styles (e.g. the alignment of an image). Would it be ok if those were automatically converted to classes (because CKEditor 5 strongly prefers classes)?

Thank you!


Original ticket

Hey there!

we are evaluating an ckeditor4 -> 5 upgrade.
Unfortunately I cannot find anything related to the "view source" button/functionality.
Is this a feature which will be implemented as a plugin? Or is this something the new dataprocessing/view engine is handling? Is there an ETA? (I cannot seem to find it on the roadmap docs and searching for "source" and/or "view" across the repos leads to many unrelated issues.

Thanks

@fredck
Copy link
Contributor

@fredck fredck commented Oct 6, 2017

Hey Michael! Thanks for the suggestion. It, in fact, bring us to a topic where a lot of feedback is needed.

First of all, thinking about end users, the "View Source" feature is something to avoid. It is a mistake to have it, especially in the light of CKEditor 5, where we want to bring the editor out of the "HTML Editor" thing, making it the perfect soluting for "quality content writing".

So, the more input we have, the better. You may tell us about your use case. Some things you could let us know:

  • Why do you think "View Source" is important?
  • What are the use cases for such feature? Can you list the top user actions within it?
  • What's your feeling about me saying that this feature is "dangerous" and should not exist?

Note that I'm not asking this with the intent of saying that we're not willing to do it. It's a sincere talk, eager for feedback. In fact, we're most likely not making a move towards the development of any feature, if there is not enough talk and data to help us understand them and their benefit.

In any case, for now, I believe this would be a community contributed plugin.

Thanks!

@mborejdo
Copy link
Author

@mborejdo mborejdo commented Oct 6, 2017

Hey fredck. Thanks for your feedback.
I understand your points and also see only limited usage for a "view source" plugin for the average user (Editor). (we disable it for the average user, but allow "admin" usage)

I do see the need for "advanced" users (eg. CMS Admins) where "pixelperfectness" is needed. Eg. The "Editor"/User/Customer created a document, but messed up styling, spacing, DOM-nesting or the like.

Responding directly to your questions:

  • Its important do see the internal document structure and be able to edit more than "wysywig" (empty elements, unneeded breaks, etc)
  • "Fixing" Editor/User generated content on a "lower level" (within ckeditor views)
  • I completely understand that this feature is not needed for the average user and in constrained cms environments

i will ask my colleagues some more usecases, where we use this CK4 feature

@mborejdo
Copy link
Author

@mborejdo mborejdo commented Oct 6, 2017

Some more "usacases" from my colleagues:

  • Adding "third party markup" (tracking etc) within content (without specific plugins)
  • fast content duplicating/editing (copy/pasting in src-view mode)

@cavac
Copy link

@cavac cavac commented Oct 7, 2017

Another usecase:

I'm using CKEditor 4 to edit my blog and software documentation (but display the public pages WITHOUT editor, just the HTML). When developing plugins or writing posts, i regularly use the "View Source" feature.

Without a "View Source" option, CKEditor 5 is a no-go for me.

As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.

@Reinmar
Copy link
Member

@Reinmar Reinmar commented Oct 9, 2017

As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.

This is how many developers perceive it and we are aware of that. But that's not true.

Let's state this clearly – CKEditor is not an HTML editor. It is a content editor and HTML is just one of the possible outputs.

Most of the use cases that you mentioned were related to manually adjusting the output and adding custom markup. Yes, this is possible in CKEditor 4. But CKEditor 4 is not meant to be used this way. When hacking the output you risk that the next time this content will be loaded into CKEditor 4 something will break.

Why? One of the reasons is that CKEditor 4 needs to understand the content. When content is being edited in the WYSIWY* mode the editor needs to apply many complex transformations to it. Those algorithm needs to make decisions based on the content that you're editing. So if you put into the editor content which it wouldn't generate itself, you risk that this content will not be understood and will be somehow broken.

This is, IMO, one of the most frequent reasons why developers dislike WYSIWY* editors – it's because they are abusing them.

CKEditor 5

So far I've been talking about CKEditor 4. How's CKEditor 5 different?

CKEditor 4 uses the DOM as a model. When loading data, the HTML is processed (read – filtered, normalized and escaped) but it ends up in the DOM anyway.

CKEditor 5 has a custom data model. When you load HTML into the editor, it's parsed and then features (initialized previously in the editor) try to pick up from this HTML the pieces they understand. This is called "conversion". As a result of a conversion, the content is being loaded into the custom data structure. The reverse process is executed when content needs to be rendered back to the DOM (either for editing or for data retrieval).

This means that if you don't have a feature which handles a certain HTML tag/attribute/style/whatever then the editor will automatically drop it.

This is how all modern rich-text editors work. Nothing special here (well, except the fact that we support OT ;P)

Source mode

So, I think that the discussion above missed the point. Why doesn't source mode make sense for CKEditor 5? It's because you will lose all changes done in the source mode unless they are compatible with what the initialized features understand. But in this case, you'd be able to just apply these changes in the WYSIWYM mode.

Solutions?

Don't use CKEditor as a page builder (aka HTML editor). Use it exclusively for content editing. Write features for custom stuff that you want it to handle. Build a proper app for page building (if you need it) and use CKEditor as a part of it.

That's the direction which we were empowering in CKEditor 4 by the introduction of features such as Allowed Content Filter and widgets. And CKEditor 5 just made a couple of steps further.

PS

It should be possible to implement a "wildcard" feature in CKEditor 5 (I guess we'd call it "AllowedContentTrue" ;P), but just... don't. Don't do it cause loading data is one thing, but then all the features still need to understand that content for editing.

@fredck
Copy link
Contributor

@fredck fredck commented Oct 9, 2017

tl;dr on @Reinmar's comment:

If you need the Source features, stay on CKEditor 4. It'll not be feasible to have this feature working in the same way in CKEditor 5 and, even if you'll have it, it'll just allow the user to use markup that the editor understands, which is pointless because it can be achieved in the wysiwyg mode anyway.

The real solution is not calling for to the Source feature but instead develop features into the editor, which will allow end users to make things right.

@cavac
Copy link

@cavac cavac commented Oct 9, 2017

Ok, understood. CKEditor doesn't seem to be the right choice for my use-cases, i'll find another alternative.

Thanks for the information.

@Reinmar
Copy link
Member

@Reinmar Reinmar commented Oct 9, 2017

Ok, understood. CKEditor doesn't seem to be the right choice for my use-cases, i'll find another alternative.

Just to make it clear – things that we wrote about CKEditor 4 will be true for all rich-text editors that I'm aware of and things that we wrote about CKEditor 5 will be true for all rich-text editors which implement a custom data model. It's simply a limitation of anything which starts with "WYSIWY*" – customize it by implementing missing features or hope it won't break if you push it beyond the limits.

@mborejdo
Copy link
Author

@mborejdo mborejdo commented Oct 9, 2017

thanks for answering the question and giving insight on those design decisions. Makes sense.

One use case we described is "fixing" user-generated content. I see ckeditor5 generating empty elements or unnecessary breaks and nesting during my evaluation (adding images, removing, etc). I see this behavior on many content-editable related editors.
What would be the preferred way to "clean up" these problems in ck5, as I will not SEE these problems in the editor? (Sure this is a limitation in the WY-S-IWYG in general)

@Reinmar
Copy link
Member

@Reinmar Reinmar commented Oct 9, 2017

One use case we described is "fixing" user-generated content. I see ckeditor5 generating empty elements or unnecessary breaks and nesting during my evaluation (adding images, removing, etc).

I'd love to hear more about that. Could you report a new ticket with some examples of such content? What you get from users and what how you'd expect the content to look?

@scofalik
Copy link
Contributor

@scofalik scofalik commented Oct 10, 2017

I have a feeling that many users feel the need for the "view source mode" out of fear or uncertainty, with the assumption that the editor will output "wrong" code. We pay a lot of attention to make sure that CKEditor 5 is outputting a least bloated, semantically correct data.

We started the Editor Recommendation project where we discuss what editors (in general - not only CKE5) should output. We also introduced two "processing pipelines" - one of them generates data for the editor (editing mode) and one of them is generating data for output (this is the data you want to save in the database). The editing pipeline contains quirks and additional tags that are necessary for proper editing, but the data pipeline should be as clean as possible. With core features, we strive to create them in a way that no unneeded tags are created by editor.

If you think that you encountered a bug and the data is not generated the way it should be, please report a ticket as @Reinmar suggested.

@ProductiveRage
Copy link

@ProductiveRage ProductiveRage commented Oct 19, 2017

I would like to reiterate one of the reasons from @mborejdo -

  • "Fixing" Editor/User generated content on a "lower level" (within ckeditor views)

Our Service Desk has to help end users tidy up their content from time to time, most often if they have pasted some formatted content in from other software (eg. Microsoft Word) and it's gone a bit skewiff. It's possible that this will not be necessary if the paste-from-other-software support works better (I'm afraid that I don't have any examples to hand, I've just been thinking about why - in the past - we've use View Source).

I'd also like to repeat this point as well -

  • Adding "third party markup" (tracking etc) within content (without specific plugins)

What is the plan for dropping in embed content from other sites using CKEditor 5? YouTube, for example, allow you to right-click on a video and "copy embed code" and other sites and services offer similar embed snippets.

Finally, @fredck said that "If you need the Source features, stay on CKEditor 4" - I presumed that CKEditor 5 would replace CKEditor 4 at some point in the short(ish) term future. Might this not be the case and they both may be maintained for years to come (where CKEditor 4 is more of an "HTML Editor" while CKEditor 5 is the re-imagined "Content Editor") - a bit like .NET Framework and .NET Core (two products with certain commonalities but with different goals)?

@fredck
Copy link
Contributor

@fredck fredck commented Oct 19, 2017

The point is that the View Source feature is not the solution anyway.

If you need to fix the formatting for end users, you must be able to do so using the editor features. That's because if you try to "fix" by using HTML not supported by the editor, that fix will be lost anyway. Hopefully, this will become an edge case, with time.

When it comes to embedding, we have plans to bring a solution to do so in the right way. Much probably an oEmbed service that allows people to paste URL or embed code from third-party websites (like YouTube) and the embed is inserted in the contents.

The same kind of approach should be taken if you need to insert arbitrary HTML into the content. The right solution is creating a plugin where you can paste anything you want. This could be shown to the user as a widget and the plugin would output that raw HTML as a result.

@fredck
Copy link
Contributor

@fredck fredck commented Oct 19, 2017

And yes, I believe CKEditor 5 will replace CKEditor 4 in the future. For that, there are still features to be developed. But we also expect developers to make better decisions when it comes to their expectations and to spend more time on designing an RTE for their applications. (not pointing fingers to anyone here... just generalizing)

@ProductiveRage
Copy link

@ProductiveRage ProductiveRage commented Oct 19, 2017

Understood, thanks for the quick response!

It may make it awkward for software that has used CKEditor 4 and relied (whether intentionally or inadvertently) upon Users being able to tweak the html from time to time to perform particular tasks.. however, I can see that it will offer a much cleaner and more reliable approach for any system that doesn't have such strange legacy requirements and where the User can be guided through particular tasks with appropriate plugins.

@pjasiun pjasiun mentioned this issue Oct 23, 2017
@pjasiun
Copy link

@pjasiun pjasiun commented Oct 23, 2017

To make it clear, this topic is about 2 separate plugins.

First is "Source" plugins, which replace the visual editor content with the data (HTML by default, but it might be any format, for instance, markdown) and let you edit the content as data. There are couple problems with such plugin, for instance, it will not work well with the collaboration.

The second plugin is mentioned "AllowedContentTrue". Plugin which lets you set any content (any HTML tag). For sure CKEditor 5 would not understand such content, and could only handle it in the dummy way, with all problems mentioned about.

However, note, that these plugins are independent. For instance for "fast content duplicating/editing (copy/pasting in src-view mode)" you need only the first plugin. It would allow you to edit content as HTML but would not allow any tags which edit does not understand. Or you may want to be able to put any HTML in the setData and get it back when you are using getData. Then you need the second plugin, which has nothing to do with the source mode.

If you want to have an HTML editor, you need both plugins, but I agree that this is not what CKEditor 5 suppose to be.

@harmenbos
Copy link

@harmenbos harmenbos commented Nov 19, 2017

As a software developer i like to migrate my solution platform to Ckeditor5 because of the innnovations which are there. But sourceview is needed for that. My developers wants to be in control als also want to test the output of new feature we gonna make.
And because the generated output is created anyway wit a getData call, it should't be a big effort to add this feature. So let the users decide about implementing it or not. Makes this sense?

@Reinmar
Copy link
Member

@Reinmar Reinmar commented Nov 19, 2017

But sourceview is needed for that. My developers wants to be in control als also want to test the output of new feature we gonna make.

Do you mean testing what a CKEditor 5 plugin which you've just written produces? But that's a developer's tool you need, not an end-user "source view" feature. And since CKEditor exposes editor.getData() your developers can open the console and type it there or you can, in a development mode, have a textarea or something next to the editor automatically updated with a content of the editor. But again – that's for developers, not end-users. And it doesn't require us to write a feature for it.

@Reinmar Reinmar closed this Nov 19, 2017
@Reinmar Reinmar reopened this Nov 19, 2017
@Reinmar
Copy link
Member

@Reinmar Reinmar commented Nov 19, 2017

I also thought about one more thing – viewing the model and the virtual DOM (the view). This is something that developers need to do when developing CKEditor 5 plugins. We actually have utils for that already (see https://github.com/ckeditor/ckeditor5-engine/tree/master/src/dev-utils). We use them extensively in tests.

We may also develop a live viewer of the CKEditor state. Something like the DOM viewer in Chrome's dev tools. Would those help?

@harmenbos
Copy link

@harmenbos harmenbos commented Nov 19, 2017

@pferreir
Copy link

@pferreir pferreir commented Nov 21, 2017

I understand you guys want to keep the data model and the serialization format separate, but then you have to be sure that users don't get stuck very often. My experience as a CKEditor4 user is that that editing certain kinds of content (e.g. bullet lists) can be tricky. I will sometimes switch to source view as non-destructive way of solving problems.

(BTW, the new CKEditor 5 looks really cool, keep up the good work! 👍 )

@scofalik
Copy link
Contributor

@scofalik scofalik commented Nov 22, 2017

If a user experiences a bug in given feature, they should report what happens and we will do our best to quickly solve the issue. I am realist and I know that there will be bugs, especially connected with more complicated features, like lists, widgets or table, but we are trying our best to cover all the cases. The hope is that we will be able to deliver quality features so that there will be no need to look at source.

As far as "simple changes in source" go, view-source plugin would not be that difficult to create and we expect that sooner or later community will create it :). As long as you are changing/providing HTML that is understandable to the editor it should be fine. Just keep in mind that "submitting" the changed HTML will have to use editor.setData() (unless you come up with some smart diffing, etc. but this is much more complicated). That means that it will reload the whole data. It might mess with undo steps and for sure would have a negative impact during collaborative editing.

@Reinmar
Copy link
Member

@Reinmar Reinmar commented Nov 22, 2017

I understand you guys want to keep the data model and the serialization format separate, but then you have to be sure that users don't get stuck very often. My experience as a CKEditor4 user is that that editing certain kinds of content (e.g. bullet lists) can be tricky. I will sometimes switch to source view as non-destructive way of solving problems.

A very good point. This is, I think, the only reason why I used source mode in CKEditor 4 myself.

A typical use case may look like this:

  1. You paste some content with lists to the editor.
  2. It turns out that there are multiple paragraphs and headings in some list items intermixed with some more lists, etc. Basically, a mess for the editor to control.
  3. CKEditor 4 has no mechanisms to clean that up. Neither does ACF help, nor you can edit that in the visual mode later on.
  4. So you switch to the source mode and figure out how to convert that to a proper, editable HTML.

Another scenario is applying a format (e.g. a heading) to a list item. It converts <li>foo</li> to <li><h1>foo</h1></li> and you can't go back to <li>foo</li>... ;/ You can only get <li><p>foo</p></li> now.

This is bad. And CKEditor 5 fixes all these issues :) How? With the new data model and redesigned features.

Of course, a big part of the "fix" comes from the fact that CKEditor 5's features allow far less than CKEditor 4. E.g. you can't have any blocks in list items. But that's exactly the point. Features need to be defined more precisely and target well-defined use cases. The current lists are supposed to support simple article use cases and we expect to have, as we call them, "document lists" in the future as a separate feature. It will handle only these more complicated lists and will need to figure out ways to edit them. It will do one thing, but it will do it well.

So, as @scofalik wrote – if such situations occur that you can't achieve some result in CKEditor 5, then they are bugs and we'll be grateful for reporting them to us.

@crshumate
Copy link

@crshumate crshumate commented Jun 13, 2019

@skurfuerst How is it unfair and very unfair at that? Simply because you disagree?

I'm not mocking or dissing the work they did do. Other than Source View missing, which is a critical feature for my company and many other developers, the plugin works splendidly.

However, I am quite frustrated both at the lack of the feature and the response. In this thread they act as if we have to justify to them the feature...when for years it's been a market standard and expectation.

What I said is true: Source View is an expected market standard when it comes to WYSIWYG editors. That's the exact reason we see so many frustrated developers/implementers in this thread.

If it's not a WYSIWYG editor that's fine but don't use that term as developers have certain expectations surrounding what WYSIWYG means. Don't use it for marketing just to get eyes and interest if it lacks market standards. Otherwise they will receive a bevy of frustrated developers who are going to rip out the code.

At minimum, if we're being objective and honest, there should be a warning/explanation on the front page of the documentation explaining that Source View is not a feature so devs do not waste their time

@bs-thomas
Copy link

@bs-thomas bs-thomas commented Jun 14, 2019

My company also wants to have the view source feature.

I think the biggest argument that CK editor has is that editing HTML in this plugin is not the right thing to do. It will also possibly break a few core features because of unexpected open-ended changes developers can make into the code.

However, I personally think that business requirements actually rule out the two arguments above.

On another note, I think that if I'm implementing
ckeditor on something like jira, I could understand that the wysiwyg editor should not have a view source button, because they would never have to play with complicated layouts using the editor. They just need the basic styling features and paragraph features.

However, if I'm implementing CK editor on a website control panel, the whole story is different and the view source feature would be almost mandatory.

Of course the feature list is really up to the dev team here. At the moment I am unable to use this version of CK editor. I'm forced to fall back to the previous version, hopefully if I'd be able to hear some good news about the view source feature I'll definitely want to jump onto this version.

Thanks all!

@archonic
Copy link

@archonic archonic commented Jun 14, 2019

This feature request is ultimately asking for a text editor as a feature within a vastly more complex editor. What's stopping you from creating a feature inside your app to load a textfield instead of CKEditor5? Or from creating a different view that uses CodeMirror?

@OpenESignForms
Copy link

@OpenESignForms OpenESignForms commented Jun 14, 2019

@wwalc
Copy link
Member

@wwalc wwalc commented Jun 14, 2019

For those who need SOURCE, we'll just need to stay on CKEditor 4.

Exactly. Especially, if by "View source" one understands being able to type freely random HTML code. Personally, I think that's the most reasonable option for now. We will support CKEditor 4 until 2023 so if you need a classic WYSIWYG editor with source mode and support for typing freely any HTML, just choose or keep using CKEditor 4 for now. Unless you are ready to invest a lot of your time (&money) to write custom plugins to support that. CKEditor 4 is a rock solid, well-documented editor that has good browser support and is still actively being developed.

I understand the disappointment of some of you. We also would love to have all the features that users request in CKEditor 5 immediately. After all, that would make all CKEditor users happy, which in result would make us happy too. It's really not easy knowing that there is a thread full of disappointed people and knowing that there isn't much you can do with it at that moment.

When releasing CKEditor 5 we had two alternatives: keep it hidden from the public for further 3-4 years, until we implement enough features to satisfy 90%+ of people, or just release it and add features gradually. The first beta release of CKEditor 5 in 2017 probably satisfied <5% of people. Does it mean that it was bad to release it? I don't think so. After all, a few percents of people received something that they needed. Did 95% of people lose anything because of that? Probably not, they still could use CKEditor 4. We try to document really well all the features of both editors, so anyone at any moment can have a look at what they offer and make a conscious choice.

We continue adding features gradually to CKEditor 5 and will continue doing so for many years to come. We do have limited resources though, so we need to prioritize our work somehow (hint: if you would like us to develop faster, purchase a commercial license or sponsor some features development, we will simply hire more devs for all the money). Seeing how View source feature is important, we did what we could for now and performed internal research as @Reinmar mentioned already. We know how much effort it requires: a lot. If it was a task for a month or two we'd do this already, but it isn't (the list of topics that it covers is in #592 (comment)).

As for priorities, we keep getting many many other requests that are more in line with the needs of the current user base of CKEditor 5, for example, better tables support or being able to resize images, code blocks and so on. When we more or less address issues like that and make sure that current CKEditor 5 users have a super decent editor, we'd gradually switch to "source mode" topic and provide the rest of users an easy way to jump in into an already super decent editor. The whole effort is not only about "source mode" itself, but also about making it easy for 80%+ of people to migrate from CKEditor 4 (or any other editor).

@jaybaldwin

This comment was marked as off-topic.

@seyaobey

This comment was marked as off-topic.

@Maxhou00

This comment was marked as off-topic.

@Reinmar

This comment was marked as off-topic.

@Maxhou00

This comment was marked as off-topic.

@AminaMahmod
Copy link

@AminaMahmod AminaMahmod commented Sep 30, 2019

actullay i need to know when you will support the view source and the ability to edit it in the ckeditor 5
as it's so important to my work right now @Reinmar

@ruslanguns
Copy link

@ruslanguns ruslanguns commented Oct 15, 2019

Well in my case, I am simply going to use the Markdown processor and it is really important to be able to work around Source Code.

@mehdyhaghy
Copy link

@mehdyhaghy mehdyhaghy commented Oct 25, 2019

We are using ckeditor 4 in a SaaS CRM as an Email Template Editor.
This is a the typical scenario: user creates email templates with their email template designer of choice and then they copy paste html into CKEditor source tab to save in our system.
They can apply small changes on CKEditor afterwards. after removing source part basically we don't have a way to import existing designs and users need to start from scratch.
I understand removing source view will improving content editing experience but it's simply not CKEditor anymore, it's a new product which deserves a new name and it's own separate repo.

@Nodws

This comment was marked as spam.

@ruslanguns

This comment was marked as spam.

@ckeditor ckeditor locked as spam and limited conversation to collaborators Nov 6, 2019
@Mgsy Mgsy removed the squad:compat label May 28, 2021
@Reinmar
Copy link
Member

@Reinmar Reinmar commented Jul 19, 2021

Some good news finally ;) 🎉

We've just released two features that I think you'll love:

We plan to continue work on General HTML Support (GHS) as there are some gaps (see e.g. https://ckeditor.com/docs/ckeditor5/latest/features/general-html-support.html#known-issues and #2973). However, the features that GHS offers already should resolve most of your use cases. Thus, I'm closing this ticket.

Thank everyone for your input ❤️

@Reinmar Reinmar closed this Jul 19, 2021
@Reinmar Reinmar removed this from the nice-to-have milestone Jul 19, 2021
@Reinmar Reinmar added this to the iteration 44 milestone Jul 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet