Custom URL's stop working in markdown, after upgrade 3.0.20 to 3.0.23

[tw bert]

Hi, unfortunately we need to downgrade back to 3.0.20, because we use custom protocols in our markdown descriptions. Example:

_Eclipse Hyperlinks:_

[my\_short\_demo.txt](eclipse:///openfile?workspace=TryoutEclipse&editor=default&window=1&line=0&offset=0&project=mercurial_xtryout&path=xtryout/my_short_demo.txt)

Renders to clickable hyperlinks in 3.0.20, and to plain text in 3.0.23.

Our dev machines have a custom protocol handler, that opens the file inside a specific running eclipse instance (for the openfile command above, but it's just an example).

Anything we can do to fix this?

Kind regards, TW

[Christian Hammond]

Hmm, that’s going to require some thought. We had to disallow arbitrary protocol schemes in order to address a security issue. We might be able to offer some kind of setting to add new schemes, but we’ll need to look into the options here.

To check, does your company have a support contract with us? If so, we could expedite a pre-release build once we have something in place.

Christian

 

--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/9cef4b99-9196-4137-bc2e-255f0c0429fbn%40googlegroups.com.

--

--
Christian Hammond
President/CEO of Beanbag
Makers of Review Board

[tw bert]

A setting for allowed protocols would be great. 

We run RB on our LAN only, so even a simple environment variable would suffice. 

For our use case, it does not need to be WAN hardened. 

If you decide against it, can you point me to the source location? 

We might just hack it into the code. 

About the support contract: No, not for now. 

After writing quite a lot of custom tooling (via the api) to include RB in our CI/CD, 

we still have to iron out some issues, mostly related to performance. 

So we are a bit past proof of concept, but also still investigating and evaluating. 

Kind regards, TW

[tw bert]

Hi Christian,

Normally I would post this as a separate issue (feature request), but it could be technically related.

Would it be possible/feasible to switch to CommonMark?

We'd love to make better use of RB screen real estate in the Description (we populate it by the API, and we put quite a lot of information/urls there, so the actual diffs are often off-screen).

Being able to use extended syntax (like small text, see links below) will improve that a lot.

https://meta.stackexchange.com/a/53801

https://meta.stackexchange.com/a/135909/158100

https://meta.stackexchange.com/questions/348746/were-switching-to-commonmark

Kind regards, TW

[Christian Hammond]

Unfortunately, not any time in the near future. The module we use for all Markdown support doesn’t support CommonMark. It might be possible to extend the support some, but it’s unlikely we can make that a priority on our roadmap until Review Board 6 at this point, at the earliest.

If there are specific aspects you’d like, and can file a feature request, that’ll help us track it as a possibility in the future, if we see enough demand for it. 

In more positive news, we’ll be supporting custom URL protocols in 3.0.24 (probably in a month).

Christian

To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/5f3a0096-ca19-4429-bb6b-483bce0889d0n%40googlegroups.com.

[tw bert]

Hi Christian, that's great news, since not rendering custom URL protocols is the blocking issue for us.

Thanks for thinking along about CommonMark, I'm withdrawing that request for now (I only mentioned it because of possible positive security related side effects, next to enhanced markup, since GitHub seems fine by it).

We are looking forward to 3.0.24, and are going to stay at 3.0.20 until the next release.

Kind regards, TW