ADF -> wiki conversion should convert all non embeddable files to a link media type

[Tara Tjandra]

private boolean isEmbeddable(String fileName, String mimeType) {
        return isBlank(mimeType) || mimeType.startsWith("audio/") || fileName.endsWith(".mpeg") || fileName.endsWith(".mp4") || mimeType.startsWith("application/x-shockwave-flash")
            || fileName.endsWith(".wma") || mimeType.startsWith("application/x-oleobject") || fileName.endsWith(".wmv") || mimeType.startsWith("video/quicktime")  || mimeType.startsWith("image");
    }

Determining embeddability can work as follows in the above. If this check fails for a media item, it should be represented as [^file.doc] rather than !file.doc!

[Chris Fuller]

1. I’m pretty sure that the media and mediaInline nodes don’t know anything about mime types. Where is that information supposed to come from? Is this a new piece of information in the conversion context?
2. The link media type is deprecated and the editor no longer knows what to do with it. I’m assuming that this is not what you actually meant.

‌

[Craig Lawrence]

Is this mirroring a change on the CS side?

[Tara Tjandra]

So it turns out thumbnailing non-embeddable files totally breaks in the wiki renderer which is incredibly sad and means recent changes we had to remove a regex to special-case transforming !file.pdf! to [^file.pdf] can’t go ahead as is.

Given CS now has knowledge of converting to a link media type based on whether this is an inline node or not, I’m hoping that we could push all of this logic to CS… However if they don’t know anything about the mime-type then we’re back to square one of half logic in CS and half the logic in Jira, which I hate.

@Chris I can look in to the wiki renderer code if you don’t know off the top of your head, but I’m guessing trying to support non-embeddable files in the wiki renderer using the ! annotation is not worth pursuing effort for payoff wise?

[Chris Fuller]

@Tara Tjandra it really depends on several things that aren’t currently clear to me:

1. What is the actual current behaviour?
2. What would we like it to do instead?
3. Do we already have enough information to do the right thing instead?
4. If we don’t, can we make that information available through the conversion context?
5. If we can’t, can we at least make it better than it is today (for example, by reacting to filenames only even if we don’t know the mime type)?

Do you have the answers to these?

[Tara Tjandra]

1. See above. Also, editor is a little clunky in this view. 2. Speculating: default avatar displayed for the thumbnail relating to the file type or some generic Atlassian asset for a document. 3. Jira does but as you’ve indicated to me Content Service doesn’t have the mime type. I’m fairly sure I mistook the "type": "file", attribute for this… 4. … But your suggestion of exposing this through the conversion context is probably our best long term path forward. 5. And yeah that’s likely feasible but with a lack of stats into how many non-embeddable attachments are process via their filename vs their mime type, it’s hard to make a call whether the filename only check would solve 99% of cases or 9%. I have a feeling it’s closer to the former but knowing we’d need a complete solution to leverage conversion context, we might as well lean into that.

In summary, conversion context and getting that rolled out is a better use of our efforts.

[Chris Fuller]

Ok, that makes sense. It is not that difficult to get the change through the library. However:

1. I don’t know how involved it will be to get the corresponding changes through CS, since it also involves adding a new property to the wire protocol.
2. My understanding is that historically we haven’t always used the conversion context at all and have instead taken care of fix-ups like replacing UUIDs with filenames on our end in pre-/post-processing steps. If that is what we are doing, we would need to understand why we don’t trust the conversion context to deal with it and what the impact would be if we switched, independently of making changes to include the mime type information.

‌