The way it is implemented currently you can’t do this. You can link the Librem 14 v1 but not a specific report. @adw explained why that is.
I lack the web programming skills and the time / motivation to learn them to do anything about it. So if this is a real pain point, someone from the community needs to step up and fix it.
I think non-technical fixes are possible, as explained above, but whether they’re desirable is more of an HCL design and usability question.
Non-technical would mean:
I think that would be a maintenance nightmare.
A technical solution could add the reporter name and the Qubes OS release into the slug and we’d have a unique URL. Alternatively a generated UID would do the trick too. But then we are back at a dev task.
The full sentence was:
It sounds like you are considering the second idea (second half of the sentence) but not the first idea (first half of the sentence).
The first idea would involve merging all the reports that would result in identical first cells, with the result that every first cell is unique. This would mean that there are no longer any situations where multiple rows share the same slugified anchor link.
Perhaps this is also a bad idea, but if so, I haven’t heard why yet.
Just to make sure we are not talking past each other: by “non-technical” we are talking about solutions that do not involve any change of the code that generates the website, but merely manipulating the data stored in the YML files?
If that is the case please consider the structure of the YML files: we first have data like the OEM, model, bios, CPU, graphics, networking, USB etc. That is what I would call the “machine data” and that is also what is used to create the slug.
Followed by that we have a list of “versions”. Each “version” consists of Qubes OS version, Kernel version, Xen version, a remark, the name of the reporter and a URL.
We already do merge all reports that have identical “machine data” into a single YML file. That means there is one slug. However, multiple persons may have reported about that machine and for multiple versions.
This is what is actually causing the issue. Each “version” aka report gets it’s own row in the table on the website, but they all share the slug generated from the “machine data”.
If I understand correctly, following this option to its logical conclusion would probably result in deleting (or otherwise “losing”) “version” data while retaining only “machine” data. Then we’d have the desired result of every row starting with a unique first cell, but at the cost of “forgetting” how many different reports there were, from whom, on which releases, and so on. Presumably, this would be too extreme of a cost to pay for the desired benefit. Is this understanding correct?
If so, I agree that such a cost would be too high. I just wanted to make sure we were genuinely considering the available options.
Yes.
I appreciate that and are glad we explained it in this detail. Currently the slug is generated from:
brand + model + cpu-short + chipset-short + gpu-short
I suggest a unique slug could be generated from:
brand + model + credit + qubes
credit = the name/alias of the reporter
qubes = the version of the Qubes OS release
If there ever is a reporter having multiple versions of the same brand/model and is reporting those for the same Qubes OS version … like me 
… I will make sure the model contains an additional identifier as in ThinkPad T430 (23477C8) and ThinkPad T430 (23497W9).
You did send me some instructions on how to create a build/test environment for the website and I suppose if I can locate the code that generates the slug I will be able to change the variables going into it and test the result. So unless another volunteer steps forward in this thread, I will take a look at this when I find the time (might be a few weeks with everything else that is going on).
Another possibility occurs to me: Merging all same-model reports without losing information could be achieved by grouping the “version” data into a list. For example, a single row could have “Credit: Sven, Deeplow, Simon” (multiple names in one “Credit” cell). But this gets messy when considering how to handle different Qubes OS releases, since those are different columns. Probably too much trouble.
IIRC, the slug is just automatically generated from the contents of the first cell, but it might be possible to include more than that.
That’s documented here, btw.
Sounds good. This seems like a fairly low-priority issue, so I agree with not letting it take precedence over more pressing matters.
I have now made the change and submitted PR #198. There is an important side effect of this change to discuss before merging it: while I can update the links in the list of community recommended computers, there will be hundreds of links in the forum and the mailing list archive broken forever
Is everyone OK with that?
There is a better solution now. Each HCL report file (YML file) represents a specific device. But there can be more than one report in such a file. These reports are called ‘versions’. A version includes the Qubes OS release, kernel version, Xen version, remark and name/link of the reporter.
Until now if there was more than one version, all versions had the same URL (because the slug was formed from device details). The previously discussed solution of changing how the slug is created would result in breaking existing links in the forum and mailing list archive. This new solution simply adds an underscore and the version index to the URL of every report that is not the first one.
Hence all existing links continue to work as before, but we are now able to link to a specific ‘version’.