Hello,
This is a UX bug for the workflow described below:
- An external website links to a private category.
- A user of that website clicks on the link and is taken to
discourse.example.com - Since the category is private and if the user is not logged in, the user receives a page with the following error: “Oops! That page doesn’t exist or is private.”
- The error page does not tell the user to log-in to view private categories, nor does the website header have a “Log-In” button (like regular discourse pages do).
You can see the difference in page header for unauthenticated users on error pages vs regular ones by visiting: discourse - Demo (regular page) vs. https://try.discourse.org/c/private-category
Workaround: User must go to a different discourse page (eg. the homepage), log-in by clicking the “Log-In” button in the page header and then reopen the link again after having logged in.
This makes for a particularly frustrating experience for users who are new to discourse since it is not immediately obvious what action they need to take. The incidence of this is particularly high for users who are are using it in a mixed setting where discourse links are scattered and cross-referenced across wikis, slack, other website pages etc.
Fixes:
- The error page should be more explicit on how to access private pages for unauthenticated users.
- The error page should have a “Log-In” button in the header.
I’m not quite sure if there are particular reasons by the error page is treated differently from the rest of the pages (performance? different code-path?), but if this was a thought through decision, it’d be great if someone could shed light upon the matter.
If not, and the fixes I’ve proposed are acceptable, please let me know what I can do to fix it (happy to submit a PR, but need some help on where to start in the code-base).