Redirect After Login keeps its rule set in wp_options under keys like rul_settings for site-wide and per-role redirects, and in wp_usermeta for per-user overrides (typically rul_redirect_url). Each role and each user can declare a redirect target for login, logout, and registration events.

The default admin gives a settings screen for role-level rules and a per-user override field inside each profile. There is no single grid that joins per-role defaults with per-user overrides. Auditing a multi-role site with custom per-user redirects becomes a click-through problem.

SleekView reads the option set and the usermeta keys, normalises them into rows, and exposes the entire login-redirect rule set as a sortable, filterable grid. Inline edits write back through the plugin's standard update hooks so the redirect behavior on the next login reflects the change immediately.

Redirect After Login does a simple, important job: it lands each user on the right post-login URL based on role, user, or capability. The trouble starts as a site grows. A membership site with five customer tiers and twenty per-user exceptions ends up with a rule set scattered across one settings screen and dozens of user profiles.

Auditing the rules becomes impossible from inside WordPress because no single screen shows them together. So overrides drift, exceptions go undocumented, and a portal restructure turns into a manual click-through across every profile. SleekView reads the same options and usermeta the plugin reads and renders them as a grid.

Scope, subject, login URL, logout URL, override flag, and last-modified all become columns. The plugin still performs the redirect on every login event. SleekView gives admins the visibility a rule set of any real size requires.