RFE: The rich text edit box on the use case description page supports direct pasting of pictures.

[xian-crazy]

Question:
The current use case description text editing box needs to upload the picture first and then insert the picture url, which is very inconvenient.

Requirements:
Replace it with another edit box, which supports direct mapping instead of uploading pictures first.

[Prome88]

Agreed that this would be a beneficial function (as it was before the change from TinyMCE to markdown editor).

[atodorov]

SimpleMDE will need:
sparksuite/simplemde-markdown-editor#328

OTOH this feature also needs a backend support.

[Prome88]

I was pointed to https://github.com/Ionaru/easy-markdown-editor which is an active fork of SimpleMDE which has the upload support out-of-the-box.

uploadImage: If set to true, enables the image upload functionality, which can be triggered by drag&drop, copy-paste and through the browse-file window (opened when the user click on the upload-image icon). Defaults to false.

[atodorov]

I have made some research on this issue and here are the facts:

1. The editor used is not relevant; the problem is not with the editor itself but how uploaded files are connected to other objects like TestPlans, TestCases, etc.

2. Stemming from 1) at the moment of an upload the editor needs to know which type of object that is and it's ID. This is easily solved when editing records which have been saved previously in the DB b/c we know exactly which one it is. Files will attach to that particular object. If you look at the url of an uploaded file it will be something like /uploads/attachments/<app_name>_<model_name>/<id>/<original file name>

3. The problem with how things get connected to one another in 2) is that this doesn't work when creating new records. Until objects have not been saved they don't have an ID and we generally don't know what they are. This is the same reason many-to-many relationships like tags & components can be modified when viewing a page (e.g. a TestCase) but not when creating that type of object.

4. The cleanest way to solve this I've seen implemented by GitHub comments and they attach files directly to users b/c the user is logged in and known at any times. The URL is something like https://user-images.githubusercontent.com/<your user id>/<some hash value>.png

5. Kiwi TCMS can certainly use the approach in 4) but it opens more questions than it solves:

• Should the files be only for Markdown references (most likely images) or should they be also available in the Attachments card on each page ? Because this is per object that means one list of attachments for a TestCase + another list per user.
• Then what if multiple users add attachments to the same TC via the editor ?
• Should users be able to see all of the files they've uploaded
• Should users be able to remove theirs (or any other) attachments, even if they are in use. ATM we don't check references whether or not an uploaded file is referenced in Markdown text
• How about deleting records (e.g. test case) which reference uploaded images per user ? Should those be auto-deleted like the rest of the attachments ? If they aren't connected to the object being deleted this becomes a less trivial task and prone to failure
• OTOH if we don't remove per user uploads then there is a risk disk usage will grow and just keep around stale files not used by anything else. That would definitely be annoying for sys admins on heavily loaded systems where they may need to support a larger file storage cluster over time but the actual content won't be in use b/c it will be stale.

6. A more limited approach is to allow file uploads from the editor only when editing something, e.g. we know what the object is and what ID it has. Disable the button when this isn't the case. That would still be annoying to users and require to first save an incomplete page (possibly empty) and then edit to insert all pictures and file uploads.

^^^ 6) is more or less not solving the current problem so doesn't sound like a good idea anyway.