Re: #1636 (closed)
This is to ensure notifications are not filtered out at the application level and we don't return less than the requested amount of records unless it's the last page. The idea is that instead of relying on safe_render_many (application level filtering), the notifications that can't be rendered should be filtered out in the query.
Right now, the logic for filtering the notifications at the application level is the following:
For a non-superuser: skip notifications from the user that has deactivated, password_reset_pending, confirmation_pending (if account_activation_required is enabled), or invisible flags set to true.
For a superuser: skip invisible and deactivated.
(Unlike deactivation, invisibility doesn't prevent a user from performing actions that create notifications for other users).
In the MR:
- Actions by invisible accounts do not create notifications
- Removes the fallbacks that cause notifications to be silently filtered out from the result (now an error will be logged instead).
- The user visibility check is skipped at the view level when rendering the user account, meaning we rely on the database query to be the single source of truth for the notification visibility