-
Notifications
You must be signed in to change notification settings - Fork 78
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
Some mattermost conversation links open in web browser #806
Comments
If this is happening, it's because Matterhorn doesn't recognize one of those URLs as a post link for your server for some reason. Are the URLs you included above both representative examples, with the first one being an example that doesn't get recognized as a post link? |
(By which I mean examples of actual URLs from your server.) |
Yes, I copied both of those examples without changing or obfuscating either of them. They both look like what I expect and both of them take me to the intended conversation when I load them with Firefox. Now that I load them both back-to-back, I see one is to a 'private channel' and one is to a 'public channel'. (None of our channels are fully public, we require authenticating with our SSO system to connect. But we do use the private channels to limit visibility of conversations.) Thanks |
Was the user account that had this problem a member of the private channel at the time this behavior was observed? |
(And was it the private channel's link that was misbehaving?) |
Unfortunately, I just came across another link that renders as the URL and loads in Firefox that goes to a public channel. (I even knew two examples wasn't enough to draw a conclusion but wanted to believe. sigh.)
Renders as:
I believe all the people who posted the links were members of the channels at the time that they posted the links. |
(Actually, channel membership won't matter at all. I thought it might, but Matterhorn doesn't even know which channel a post is in, just by looking at the post link. It only identifies a post link by looking at the URL structure.) |
Another question: when these links were not being rendered as expected, what was the Mattermost team that contained the channel in which the broken links were rendered? (The team in the URL is |
I only connect to one Mattermost server, run by Canonical. As far as I know, all the channels are part of the Canonical team. |
To confirm explicitly, then, |
Correct:
|
Okay, thanks. Just for your awareness: a "team" is a group of channels and users within a server, and every server has at least one team. You are currently a member of just one, although your server could have others that you aren't a member of. But in this case it doesn't matter because all of the post links you showed are links to posts on channels in your team, so they should be rendered as post links. (If Matterhorn sees a link to a post in a different team, it won't render it as a post link since that can't necessarily be treated as such.) This is a bit of a puzzle. I'll think about it some more and see if I have more questions for you, but right now I don't have any theories about why you're seeing this behavior. |
Hi. I'm facing the same issue. I wonder if this could happen when the linked message is pretty old and not part of the messages in Matterhorn's memory (or recent history). |
@taratatach If matterhorn can tell that a link is to a post, then it will always fetch that post and put it into the history. (It must do this since the next step is to select the post in selection mode.) |
In #816 I pointed out that my client had two connections to my company's mattermost instance via Kubernetes and loadbalancers. Earlier, @jtdaugherty said:
This is a mighty big leap to make, but what are the chances that the "post link for your server" is doing some IP-address based equality checks rather than DNS-name based equality checks or making an API call to retrieve the contents of the link and inspect the data for a team uuid or something? In which case, there might not be any pattern to which links are considered on the same server and which are considered to be on another server, because the
Thanks |
@setharnold post links are detected solely by inspecting the string of the URL that mentions the post (here). No API calls or DNS resolutions are involved. |
A leap too far! thanks again for indulging my curiosity @jtdaugherty. |
Is there a way I can force matterhorn to load an URL? eg, a recent message from a colleague renders like this:
The built-in url opening goes through xdg-open to firefox which loads that link in the web interface. What I would love is some way to go to this conversation within matterhorn directly. For example, maybe Does this feature exist? If not, would you like a new issue for it? Thanks |
Not right now. It can only open URLs that appear in messages.
In general, Matterhorn will do this if you open a post URL. If you open a post URL and it uses the open command as you describe, then that's an instance of the bug that this ticket is about, and I don't have any leads right now on why that would be happening. If Matterhorn uses the open command to open the URL, then for some reason it has concluded that the URL is not a post URL. I'll update Matterhorn so that it logs some of the information it's using to do post URL matching. Perhaps that way we can see why it isn't properly identifying post URLs. |
There's now a patch on
If you end up doing that, please post that here along with one of the post URLs you're using that isn't working. |
For me, the conversion to
Edit: |
Hello, usually internal links to conversations in matterhorn render with
<post link>
but once in a while internal links render with the full URL. These full-URL links open with Firefox rather than within matterhorn.The
Yank-all
view of a message that renders with the full URL and opens in Firefox:The
Yank-all
view of a message that renders with<post link>
and opens within matterhorn:I would prefer if these links always opened within matterhorn. I would prefer if the link text were visible, so that it is an option to select it and copy it via mouse.
Thanks
The text was updated successfully, but these errors were encountered: