Logged out during editing or posting: intercept and report, don't fail silently
meta:291621
If you start to edit a post (and I assume also if you start to create one) and get logged out, then when you go to submit the edit it fails and then the button becomes disabled, but you don't get any sort of error saying what the problem is. We don't do live updates via websockets or the like, so the page you're on can't know you've been signed out when you click the button, but when we get the failure back from the server, it would be better if we popped up an error message saying you need to log in.
One thing to check: are we at risk of losing the draft? When drafts are saved, are they tied to your browser session (it'll still be there when you log in) or to the current user? Make sure we account for that when addressing this. A big complicated edit that took you long enough that you got logged out behind the scenes is exactly the type of edit we do not want to drop on the floor.
are we at risk of losing the draft?
No, we are not - the drafts are saved in Redis cache tied to the user + post + attribute. When the user submits the form, we attempt to delete the draft first via AJAX, which in the case of being logged out fails with 422.
Although #1753 means there is no longer a silent failure in the case where a user is logged out before submitting a new or edited post, I'm not sure this is sufficient to cover this bug. That is, I like the improvement, but this bug either needs further work or a separate bug to be raised.
From a user perspective, the fact that a draft failed to be deleted does not communicate that the post will not be created (or edit saved), or that the underlying cause is being logged out.
Ideally I'd like the user to have the following:
- Clear indication that their post has not been saved.
- Clear indication that the reason is that they are not signed in.
- Either a way to remedy this (a link to sign in that will not lose their latest wording) or a statement (to the user) that this is not possible.
Hopefully we can get to a point where preserving the latest wording is always possible, but consider the following case where I suspect we currently lose the latest wording (I haven't tested to confirm this):
- Start writing/editing a post.
- These changes are saved to the draft.
- Get signed out in the background with no indication to the user.
- Continue making changes.
- These changes are not saved to the draft.
- Press submit.
- See warning message saying "Failed to delete post draft. (422)".
- Decide to visit another page.
- Realise not signed in.
- Sign in.
- Return to writing/editing the post, to find that the draft loaded is from step 2, not the later version that failed to be saved to draft at step 5.
I don't know the best way to deal with this case. Is there a way to preserve the changes that cannot be saved to draft while signed out? I'm assuming that attempts to save a draft while signed out will fail. Should we fall back on a draft saved to the client (still using the user id so this draft is not presented to other users who sign in on the same client)? Would it be better to detect that the user has been signed out and indicate this before they make further changes? Is this possible without needing websockets, for example in the case where the signing out is due to cookies being discarded following a browser update?
I'm happy for some of the edge cases to be spun off as new issues. Just reopening to have the discussion and decide how much should be covered by this issue.
@trichoplax it's fine if this issue stays reopened - I fixed the most problematic issue (that there's literally no feedback), but we still have very brittle logic in that we first try to delete the draft and only save the post if the deletion succeeds. This should not be the case - I am not even sure why we do that given that after saving the post we delete the draft server-side.