Hi @IcDaan ,
When the read-only user opens that shared URL, they still don’t see the latest draft.
It seems like Umbraco’s core rendering pipeline ties access to the unpublished draft state directly to the Update permission, not just the UI action. If they only have Read access, the system denies them the draft view and falls back to an older state.
I noticed there’s a GitHub issue (#22797) raised by you for this exact Umbraco 17 behavior, so it looks like a known architectural limitation right now rather than just a UI quirk.
Since native Umbraco blocks this, it looks like the only real solution is either building a custom token-based endpoint to bypass the backoffice auth checks entirely (similar to what the TruePeople SharePreview package does), or giving the group Update rights and using Bellissima extensions to hide the save buttons.
I dug into this a bit more and found a few official resources that prove this is a core architectural rule, not just a UI issue. Here is what I found:
1. Umbraco Workflow’s “Offline Approval” is a paid feature for this exact problem If you look at the docs for Approval Groups (Approval Groups | Workflow 13.latest (LTS) | Umbraco Documentation), Umbraco HQ sells a licensed, paid feature to handle this. The docs say: “By enabling Offline Approval, all email notifications sent to the group members will include a personalized link to a preview page… It is not possible to edit the content from the offline approval view.” If standard preview URLs worked for read-only users, they wouldn’t need to build and sell a custom tokenized link system just for this use case.
2. Content Delivery API Documentation The headless API docs (Content Delivery API | CMS | Umbraco Documentation) back up this security philosophy. Under the Preview section, it explicitly states: “Accessing unpublished versions of your content nodes requires authorization via an API key.” This shows the core system treats draft data as strictly protected. A basic backoffice Read permission just isn’t enough to query the unpublished database cache.
3. Stack Overflow Precedent This isn’t a new Umbraco 17 bug; the permission architecture has worked this way for years. There’s an older Stack Overflow thread (https://stackoverflow.com/questions/49488545/umbraco-using-preview-functionality-with-user-who-doesnt-have-access-to-conte) dealing with the exact same thing. The accepted explanation there is: “There’s not really a fix for this one, as it’s correctly applying the permissions to the preview functionality… another option would be to write your own custom preview function.”
So it looks like the Update requirement is deeply baked into how Umbraco protects unpublished states. We definitely can’t do this natively without writing custom routing or buying a paid add-on.
Hope it helps!
