the (Show Details) would be a great first step for us - and cover our needs. Much like the logs for Herald Rules and other areas.
🐫 Does this button work ------>>^^^
There are a few pieces here, since we have to thread the needle through many layers to get where we want to go.
If JIRA links are mostly/all in the form ?page=com.jira.jira.plugin.extension.gateway-to-realms-of-wonder&exec=rm -rf / that might also mean that "links which don't really link to the task" are common and that "task + params" is more like "portal to arbitrary plugin behavior", although I'm not having much luck digging up more information about this by Googling.
(Also, now that I've read PHI1312, I mind this^^ implementation less since that was the actual support request anyway).
Do you think ( XXX-123 Order More Copier Paper ) is still a reasonable rendering if the parameter is something like ?download=123 and that means "Download Attached File 123" and clicking the link doesn't take you to XXX-123 at all?
Also, practically, I can't actually figure out how to get either modern JIRA or Asana to generate any URI with any parameters or fragments at all. Neither appears to support linking directly to a comment.
I guess my assumption is that ?a=b may, in the general case, completely change the meaning of the link. Although I think this has mostly been purged from the web now, an example was #! fragments before the widespread use of the history API, where https://example.com/a/#!b actually meant "Page B", not "Page A", and labeling the link "Page A" would be misleading.
If it's the same thing, that seems possibly confusing (two different links have the same visual rendering).
It's meaningfully more work, but the bigger thing stopping me is that I'm not sure what the best display behavior is.
This is just short-circuiting the whole external object lookup process, right? Is it significantly more work to just fix the lookup process to preserve these fragments?
See also T13317.
See PHI1312. The modified JIRA rules reportedly misfire on URIs with anchors or parameters. For now, the plan is to just skip these URIs. In the future, we might specialize URIs which (for example) link to comments on foreign objects.
I'm going to close this in favor of T13291. Referencing files by full URI currently works, and relative references and other behavior is planned.
Getting rid of the indirect writes on handle reads would probably be nice eventually, but doesn't directly accomplish anything today.
I think that might be everything? Not entirely sure, but haven't seen any more since the last deploy.
Tue, Jun 18
Yeah, there's a lot of very ambiguous behavior here in the face of ambiguous inputs. I think we're probably not walking into too much of a minefield, but I'm not confident I picked the best behavior for all malformed/suspicious inputs.
I'm a little worried about a Postel's Law-style HTML parser. Later on I can envision getting more strict about what we accept in the interest of delivering more precise error messages, which might break existing pages that previously worked just by accident. I guess if it ever comes to that, we can write a migration that warns installs about suddenly-malformed wiki pages.
- Make it less so.
See PHI954. The "support pact members" cache is currently updated only when you actually click "Support", but this is often silly and unintuitive.
Aha! This user very cleverly added email@example.com to their user account before they were disabled.
- Plus a rebase for the msortv() change.
Oh, not sure what happened there -- that's the local result, so maybe I ^C'd too fast. Let me just kick it...
Is it expected that B22956 never completed?
Mon, Jun 17
I deployed that last round of things to secure. Not totally confident I got everything, but hopefully we're in better shape now.