# Bug Report: Assigned Users still not visible in Frontend Event Manager (v2.5.13)

**To:** Ashan Jay / EventON Development Team
**From:** Fortes Medien (volksmusikkalender.de)
**Date:** 2026-02-17
**Plugin:** EventON Action User
**Version tested:** v2.5.13 (also present in v2.5.12)
**Severity:** Critical — core "Assigned Users" feature non-functional

---

## Summary

Assigned users cannot see their events in the frontend Event Manager (`[evo_event_manager]` shortcode). Events only appear for the `post_author`, never for assigned users. This completely breaks the "Assigned Users" workflow.

We acknowledge that v2.5.13 addressed one part of this problem — the `tax_query` field was changed from `'id'` to `'name'`, which now correctly finds assigned events in the database. However, the problem goes deeper: a second, independent bug in the same method (`get_user_events()`) immediately filters out those found events again via an overly strict capability check. The net result is unchanged: assigned users see 0 events.

---

## What v2.5.13 fixed (thank you)

**File:** `includes/class-event_manager.php`, method `get_user_events()`, line ~93

The `tax_query` field change from `'id'` to `'name'` works correctly. The `event_users` taxonomy stores WordPress user IDs as term names/slugs (e.g., name="92", slug="92"), and the query now resolves to the correct `term_taxonomy_id`. This was verified via SQL inspection — the generated query correctly produces `term_taxonomy_id IN (886)` instead of the previous impossible `WHERE 0 = 1`.

---

## What still needs fixing

### Issue 1 (Critical): Capability check blocks assigned events — lines 126–147

After the tax_query correctly finds assigned events, the following capability check filters them out again:

```php
// line 126
$can_edit = current_user_can('edit_post', $post_id);

// line 130-146: bypass attempt for assigned events
if ($is_assigned && ! $can_edit) {
if (current_user_can('edit_others_eventons')) { // ← THIS IS THE PROBLEM
// ...
$can_edit = true;
}
}
```

**The problem:** For events where the user is NOT the `post_author`, `current_user_can('edit_post', $post_id)` resolves (via `map_meta_cap`) to requiring `edit_others_eventons`. Users with the Contributor role (or any role without `edit_others_eventons`) fail this check. The bypass attempt on line 133 then checks the same capability (`edit_others_eventons`) again — so it can never succeed for these users either.

**The whole purpose of "Assigned Users" is to grant event access WITHOUT requiring `edit_others_eventons`.** The bypass should not check `edit_others_eventons` at all; it should simply grant visibility when the user is a confirmed assigned user and the `evoau_assigned_emanager` setting is enabled.

**Your own plugin already implements this correctly** in `class-functions.php`, method `can_currentuser_edit_event()` (line ~192):

```php
// This is the CORRECT pattern — already in the plugin:
if( $this->user_assigned_toevent($event_id, $current_user->ID ) ){
if( !EVO()->cal->check_yn('evoau_assigned_editing','evoau_1')) return false;
return true; // No edit_others_eventons required!
}
```

The `get_user_events()` visibility check should follow this same pattern. Suggested fix for lines 126–147:

```php
$is_assigned = in_array($post_id, $assignedEventIDs);

if ($is_assigned) {
// Assigned users: visibility granted via evoau_assigned_emanager (already checked above)
$can_edit = true;
} else {
// Non-assigned: use standard WordPress capability check
$can_edit = current_user_can('edit_post', $post_id);
}
```

### Issue 2 (Secondary): `break` should be `continue` — lines 138, 141

Inside the bypass block, `break` is used instead of `continue`:

```php
if ($status === 'publish' && ! current_user_can('edit_published_eventons')) {
break; // ← BUG: exits the ENTIRE foreach loop
}
```

`break` terminates the entire `foreach ($all_posts ...)` loop, which means ALL remaining events after the first problematic one are lost. This should be `continue` to skip only the current event and proceed to the next.

This bug is currently masked (the `edit_others_eventons` check on line 133 fails first, so these lines are never reached), but it will cause problems once Issue 1 is fixed.

### Issue 3 (Latent): `user_assigned_toevent()` ignores `$userid` parameter — class-functions.php, lines 244–264

This function is used by `can_currentuser_edit_event()` and `can_currentuser_delete_event()` to check per-event permissions. It has a logic error:

```php
public function user_assigned_toevent($event_id, $userid){
$r = is_object_in_term( $event_id, 'event_users', $userid );
// ↑ $r is never checked!

$saved_users = wp_get_object_terms( $event_id, 'event_users', array( 'fields'=>'slugs') );
if(is_array($saved_users) && !empty($saved_users)){
// ...
$all_users = get_users();
foreach($all_users as $uu){
if( in_array($uu->ID, $saved_users)){
return true; // ← returns true if ANY user matches, not the specific $userid
}
}
}
return false;
}
```

Problems:
1. `is_object_in_term()` is called but the return value `$r` is never used — this single call could replace the entire function
2. The loop iterates ALL WordPress users and returns `true` if ANY user's ID matches ANY assigned slug — the `$userid` parameter is completely ignored
3. This means the function returns `true` for ANY user when ANY user is assigned to the event

Suggested fix — the entire function body can be replaced with:

```php
public function user_assigned_toevent($event_id, $userid){
$saved_users = wp_get_object_terms( $event_id, 'event_users', array( 'fields'=>'slugs') );
if( is_array($saved_users) && !empty($saved_users) ){
if( in_array('all', $saved_users) ) return true;
return in_array( (string) $userid, $saved_users );
}
return false;
}
```

---

## Our working workaround (confirms the root cause)

We have implemented a temporary workaround that confirms these findings. In our theme's `functions.php`, we hook into `evoau_manager_initiate` and swap `EVOAU()->manager` with a child class that overrides only `get_user_events()`:

```php
add_action('evoau_manager_initiate', 'vmk_fix_assigned_users_visibility');
function vmk_fix_assigned_users_visibility() {
if ( ! class_exists('VMK_Fixed_Event_Manager') ) {
class VMK_Fixed_Event_Manager extends EVOAU_Event_Manager {
public function get_user_events( $userid ) {
// ... same query logic, but:
// 1. 'field' => 'slug' in tax_query
// 2. Assigned events: $can_show = true (no edit_others_eventons check)
// 3. Author events: $can_show = current_user_can('edit_eventons')
// 4. Other events: $can_show = current_user_can('edit_others_eventons')
}
}
}
EVOAU()->manager = new VMK_Fixed_Event_Manager();
}
```

**Result:** After applying this workaround, assigned users immediately see all their assigned events in the frontend Event Manager. This confirms that the issue is specifically the `edit_others_eventons` check in `get_user_events()`, and that removing it for assigned events is the correct fix.

---

## How to reproduce

1. Create an event as an Admin or Editor user
2. Assign a Contributor-role user via the "Assigned Users" feature
3. Log in as that Contributor user
4. Navigate to the page with the `[evo_event_manager]` shortcode
5. **Expected:** The assigned event appears in the list
6. **Actual:** The list is empty (0 events)

---

## Environment

- WordPress 6.x
- EventON 5.x
- EventON Action User v2.5.13
- PHP 8.x
- User role: Contributor with capabilities: `edit_eventons`, `edit_published_eventons`, `delete_eventons`, `read`, `upload_files`, `submit_new_events_from_submission_form` — but NOT `edit_others_eventons` (by design)
- Settings: `evoau_assigned_emanager` = "yes", `evoau_assigned_editing` = "yes", `evo_auem_editing` = "yes"