You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My company uses the autolink-plugin to detect filenames in chat messages and convert them to a URL with a custom protocol that is used to open the file in the IDE. This works really well in most browsers, however the mattermost desktop client does not open these URLs. The reason is that the file paths contain backslashes (), so the URL with the file name is technically invalid. The browsers seem to automatically encode the illegal characters, but the desktop client refuses to open such links.
The best solution IMHO would be to add the possibility to url encode values in the template. This could be done by adding a prefix to the variable name, like this:
Template: [$match](editor_launcher:${urlEncode:path})
(Additional prefixes that might be useful: base64Encode, toLower, toUpper, ...)
The text was updated successfully, but these errors were encountered:
+1!
Our use case is different, I wanted to abuse the auto linker as URL shortener. We use a web app (Kibana) that generates veeeeery long URLs (3000+ characters), and my idea was to detect these and link them with a short text instead.
It successfully detects the links and applies the replacement, but because these URLs contain parentheses, colons and asterisks, the markdown parser interferes and doesn't parse the URL as a valid link (this is actually a mattermost issue, it breaks the URL in the same way). If the auto linker could urlencode, I could easily solve this.
My company uses the autolink-plugin to detect filenames in chat messages and convert them to a URL with a custom protocol that is used to open the file in the IDE. This works really well in most browsers, however the mattermost desktop client does not open these URLs. The reason is that the file paths contain backslashes (), so the URL with the file name is technically invalid. The browsers seem to automatically encode the illegal characters, but the desktop client refuses to open such links.
The best solution IMHO would be to add the possibility to url encode values in the template. This could be done by adding a prefix to the variable name, like this:
Template:
[$match](editor_launcher:${urlEncode:path})
(Additional prefixes that might be useful: base64Encode, toLower, toUpper, ...)
The text was updated successfully, but these errors were encountered: