fix(structure): update archived and published docs in release links

[pedrobonamin]

Description

This PR updates how the links on published and archived releases work:
Published releases
Now when clicking on a document as part of a published release, instead of opening the document in the detailed view for that release it will open the published view with the history having selected that release:

Screen.Recording.2025-03-13.at.18.26.56.mov

Archived releases
Clicking a document as part of releases that are archived we cannot show the document from the published view, we instead open the document "faking" that the release exists, and it will show the badge in the document for that release, but the badge will be disabled.

Screen.Recording.2025-03-13.at.18.27.17.mov

This PR also fixes an issue with the open release links from the document events, now releases will open when clicking the menu item. (as expected)

What it doesn't solve:

View of documents unpublished by a release, it is not possible do it just now because content lake is generating the incorrect events for it, once the events are solved we will look back into solving this.

What to review

Everything works as expected.

Testing

Notes for release

Update archived and published docs in release links.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 17, 2025 10:26am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 17, 2025 10:26am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 17, 2025 10:26am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Mar 17, 2025 10:26am
test-next-studio	⬜️ Ignored (Inspect)			Mar 17, 2025 10:26am

[github-actions]

No changes to documentation

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.17%	54639 / 129552
🔵	Statements	42.17%	54639 / 129552
🔵	Functions	47.11%	2742 / 5820
🔵	Branches	79.41%	10232 / 12885

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/i18n/bundles/studio.ts	100%	100%	100%	100%
packages/sanity/src/core/releases/tool/components/ReleaseDocumentPreview.tsx	100%	96.15%	100%	100%
packages/sanity/src/core/store/events/useEventsStore.ts	11.94%	100%	0%	11.94%	38-208
packages/sanity/src/structure/i18n/resources.ts	100%	100%	100%	100%
packages/sanity/src/structure/panes/document/documentPanel/banners/ArchivedReleaseDocumentBanner.tsx	10.9%	100%	0%	10.9%	15-72
packages/sanity/src/structure/panes/document/documentPanel/header/perspective/DocumentPerspectiveList.tsx	72.99%	79.74%	33.33%	72.99%	32-69, 94-103, 128-131, 147-148, 248-251, 281-300
packages/sanity/src/structure/panes/document/timeline/events/PublishedEventMenu.tsx	8.51%	100%	0%	8.51%	30-146

Generated in workflow #32399 for commit bcc7dee by the Vitest Coverage Report Action

[github-actions]

⚡️ Editor Performance Report

Updated Mon, 17 Mar 2025 10:54:11 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	25.0 efps (40ms)	25.0 efps (40ms)	+0ms (-/-%)	✅
article (body)	77.5 efps (13ms)	72.5 efps (14ms)	+1ms (-/-%)	✅
article (string inside object)	24.4 efps (41ms)	26.3 efps (38ms)	-3ms (-7.3%)	✅
article (string inside array)	23.8 efps (42ms)	23.3 efps (43ms)	+1ms (+2.4%)	✅
recipe (name)	45.5 efps (22ms)	44.4 efps (23ms)	+1ms (+2.3%)	✅
recipe (description)	50.0 efps (20ms)	51.3 efps (20ms)	-1ms (-2.5%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (6ms)	+1ms (-/-%)	✅
synthetic (title)	16.1 efps (62ms)	18.5 efps (54ms)	-8ms (-12.9%)	✅
synthetic (string inside object)	16.9 efps (59ms)	18.9 efps (53ms)	-6ms (-10.2%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	40ms	42ms	44ms	182ms	177ms	11.4s
article (body)	13ms	16ms	18ms	71ms	49ms	4.8s
article (string inside object)	41ms	43ms	45ms	133ms	188ms	7.0s
article (string inside array)	42ms	43ms	45ms	64ms	63ms	6.6s
recipe (name)	22ms	24ms	25ms	36ms	0ms	7.9s
recipe (description)	20ms	20ms	22ms	34ms	0ms	4.7s
recipe (instructions)	5ms	7ms	8ms	9ms	0ms	3.2s
synthetic (title)	62ms	67ms	73ms	238ms	1936ms	14.3s
synthetic (string inside object)	59ms	62ms	69ms	365ms	1737ms	9.2s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	40ms	43ms	45ms	319ms	192ms	11.3s
article (body)	14ms	15ms	19ms	57ms	47ms	4.9s
article (string inside object)	38ms	39ms	42ms	210ms	141ms	6.8s
article (string inside array)	43ms	45ms	47ms	51ms	94ms	6.7s
recipe (name)	23ms	25ms	29ms	48ms	9ms	7.6s
recipe (description)	20ms	21ms	22ms	24ms	0ms	4.7s
recipe (instructions)	6ms	8ms	9ms	34ms	0ms	3.7s
synthetic (title)	54ms	59ms	67ms	452ms	1006ms	12.9s
synthetic (string inside object)	53ms	55ms	58ms	209ms	931ms	8.0s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[bjoerge]

LGTM! These are great improvements, thank you!