The LearnPress BuddyPress add-on lets BP groups own LearnPress courses, with membership stored in wp_bp_groups_members and course progress in wp_learnpress_user_items. The two tables are linked by user-id but the default admin screens don't compose them: group admins see roster data, LearnPress instructors see progress data, and combining them for a cohort report requires hand-written SQL.

SleekView joins learnpress_user_items with bp_groups_members so each group row shows its member roster alongside per-course completion and quiz scores. A cohort report filters by group_id and course_id to surface progress per member per course. A leaderboard sorts members of a given group by quiz score across the linked courses. A stalled-learner queue filters where learnpress_user_items.status is enrolled but end_time is null and start_time is older than a chosen threshold.

Inline edits to enrolment status route through LearnPress's API where supported so completion hooks fire and certificates issue. Direct edits to bp_groups_members use BuddyPress's membership functions so group activity records correctly. Group leaders get views scoped to their own groups via WordPress capability gating layered on top of BP's group-meta permissions.

Cohort-based learning is the killer use case for combining a community plugin with an LMS, and it's where the default WordPress admin pays the steepest tax. BuddyPress holds the social structure (who's in which group, who's posting, who's silent) while LearnPress holds the learning state (who's enrolled, who's stalled, who's mastered the material), and the actual program operations sit at the intersection of those two. A program director wants to know which cohorts are tracking ahead of schedule and which ones need intervention, scoped per cohort, ranked by completion.

A group leader wants to nudge specifically the stalled learners in their own group, not the whole catalogue. A success rep wants to look up one member and see every group they belong to with their progress in each course, in one row, in one screen. None of these are built-in reports.

They're all joins that exist as obvious queries against tables that already hold the data. SleekView's job is to make that join browsable, filterable, and scoped per role so the program ops layer stops being a custom-SQL job and starts being a saved view that runs on a cadence.