Fix: Store actual WordPress role instead of first user cap for role filtering

[KingYes]

✨ PR Description

1. Problem & Context

The plugin was incorrectly storing user capabilities by reading the first key from $user->caps (a capability map), which could be any granted capability rather than the user's actual WordPress role. This broke role-based filtering in activity logs and caused inconsistent data storage, especially on multisite with plugins like bbPress.

2. What Changed (Where)

• AAL_API: Store $user->roles[0] instead of key($user->caps); remove bbPress fallback hack; add fallback for super_admin detection
• AAL_Log_Presenter: Use stored user_caps value with fallback to current role; handle missing role names gracefully
• AAL_Log_Query: Compare against $user->roles[0] for capability filtering; add role name labels to dropdown from global $wp_roles
• Tests: New test suite validates subscriber/editor/admin role storage and filtering accuracy

3. How It Works

User role is captured at log insertion time ($user->roles[0] lowercased) and stored in user_caps. On display, the presenter prefers the stored historical role but falls back to current role if missing. Query filtering matches logs by stored role against the permission matrix. Role names are now resolved from WordPress global $wp_roles->role_names instead of just ucwords-formatting.

4. Risks

Role schema assumption: relies on $user->roles[0] being present and meaningful. Edge case if users have no roles assigned (unlikely but handled with 'guest' fallback). Backward compatibility: existing logs with capability keys won't resolve to role names without a migration—mitigation is the fallback to current user role.

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}