Set data-link in ReferenceFilter#data_attributes_for

Asherah Connorrequested to merge
push-vpspwloyplms into master

What does this MR do and why?

Set data-link in ReferenceFilter#data_attributes_for.

This was missed in Redact link references back to their original form (!222957 - merged) while addressing Reference redactor removes links where it shoul... (#584587 - closed) — that MR resulted in all references being correctly fixed … except for user and project references, because they're special, don't inherit from AbstractReferenceFilter, and don't set data-link like they should. See #584587 (comment 3104114761) for where I noticed this.

As far as I can tell, the only reason they don't inherit from AbstractReferenceFilter is because they came first, and AbstractReferenceFilter came later, because users and projects existed on GitLab before just about anything else! We should refactor these two filters to work in terms of AbstractReferenceFilter, to avoid this kind of omission from happening again, but it's a higher-complexity job than first appears and is security-sensitive, so we'll want to take our time doing it!

In the meantime, let's have the !222957 (merged) fix apply to the two remaining filters by correctly setting data-link in ReferenceFilter#data_attributes_for. This ensures the redactor notices it can use data-original-href to restore the link in its original form. This will also inadvertently fix a tiny RTE bug no-one has ever noticed before, where the link is treated as a plain reference due to the lack of data-link.

References

Screenshots or screen recordings

Here's an issue with links to issues/groups/projects, one visible to logged-out user, one not. Source:

Issues:

* [number 6](/root/comrak/-/issues/6) is totally ok
* [number 7](/root/comrak/-/issues/7) is totally chonfidential

Users/groups: 

* [`@All`](@All) is a hidden group
* [`@rav`](@rav) is a public one

Projects:

* [`public`](public>) is a public project
* [`private`](private>) is a private project

Screenshots:

On master On this branch
image image

Issues was fixed by !222957 (merged), but not namespaces or projects: note how the invisible ones have their links removed on master. This means you can find locate private namespaces or projects by seeing when the link is removed; if it's not removed, it's either visible or it doesn't exist.

On this MR, they now produce links the same way non-existent namespaces or projects produce links, so you can no longer differentiate "doesn't exist" from "exists, but you can't see it".

How to set up and validate locally

  1. Create an issue as above in your GDK, with links to objects that work for you.
  2. Test it in incognito; you should see the links removed.
  3. Check out this branch.
  4. Edit the issue text slightly. Add a space somewhere. This is necessary because the HTML is cached (without the data-link attribute this MR adds), so you need to bust the cache.
  5. Check the issue again in incognito; the previously removed links should now exist, not linking to the (invisible) objects but treated as just regular links. This is the way.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports