Skip to content

Unsubscribing author from Notifications is impossible: Show error or disable unsubscribe checkbox #508

@jerclarke

Description

@jerclarke

Expected behavior:

  • When unticking the post author in Notifications metabox, they get unsubscribed
  • OR If they aren't actually unsubscribed, we get a red flash instead of green after AJAX returns, and their box is still ticked.

Current behavior:

  • Unticking the post author causes a green flash, and the user seems to be unticked
  • Reloading the page shows they have been re-ticked, it is impossible to unsubscribe the post's author

Thoughts:

  • This is really confusing to users, and likely to make them misunderstand the situation if they don't go back and look at the Notifications metabox after reloading
  • I understand the reasons why the post author would remain always subscribed, and I don't think we need to change that aspect of this, it's understandable and users can work around it.
  • BUT: if it's impossible to unsubscribe the author, we should make it clear when someone tries to untick them that it didn't work.

Proposed UX: AJAX returns red flash and leaves the user ticked

  • Unticking the current author causes a red flash, and when AJAX returns, the user is still ticked.
  • This seems the easiest to do by editing how the AJAX response is handled.
  • Downside is that if the author select menu on screen has been changed, but not saved, it is the "old" author that will be un-unsubscribeable, rather than the "new" one, since our AJAX can only see the saved author on the backend.

Alternate UX: Disable the checkbox for current author based on a CSS class

  • When rendering the user list, add a CSS class to the current post author: post_following_list-author
  • CSS class matches the ones used to filer the notified list display,like post_following_list-current_user
  • Use this to disable the checkbox for the author so they can't be unticked.
  • Downside is the same as the AJAX solution: Doesn't account for the author having been changed during this pageload.
  • Upside is that this seems really easy to implement. Adding a disabled property to the input that just lasts until the page is reloaded wouldn't involve much code at all.

Alternate UX 2: Disable checkbox based on currently selected author on screen

  • Same as previous UX, but we also have JS that updates the "disabled" user in Notifications based on who is currently selected as the author in the author metabox
  • This seems a bit harder because now we need to update the checkbox whenever the author UI is changed, and involves external (changing) JS, unlike the first two solutions which only rely on get_the_author()-type unchanging API calls.
  • Upside is that this will reflect the state AFTER saving better, because if you change the author AND unsubscribe the old one, then the old one will indeed remain unsubscribed
  • FWIW I think that whole scenario of changing the author and unsubscribing the old one is VERY niche, and won't come up very often. Fixing the core problem of making it clear you can't unsubscribe the current author is a much higher priority.

Can you replicate the key problem?

Maybe I'm missing something. Would be great just to hear if I'm right about the key premise, that it's impossible to unsubscribe the current author, and the UI lies and says that it is possible.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions