## Summary The Member Options admin page (`/admin/members/options`) always shows "You don't have permission to see any options. Please contact your administrator.", even for administrators with every permission. `MemberOptions` still reads field options using the old `optid` key, but `FieldOptions` has returned them under `option_id` since the module was renamed from simple_conreg to conreg (#3564947). ## Problem description `FieldOptions::getFieldOptionGroupedList()` returns a flat list of group headings and options. Option entries hold their ID in `option_id`. Group headings have no ID. `MemberOptions::buildForm()` tells the two apart by checking `optid`: ```php if (empty($val['optid'])) { // Optid not set, so entry is group heading. ``` Since `optid` is never set, every entry is treated as a group heading and no options are added to `$options`. The form then falls through to the "no permission" message. This affects every user regardless of permissions, so the message is misleading. All the stale reads are in `src/Form/Admin/MemberOptions.php`: - Line 55: the group/option check above, which causes the bug. - Lines 64, 70 and 71: the permission check and the `$options`/ `$optionTitles` keys for each option. These are never reached today, but would produce the wrong permission name and keys. - Line 192: when a whole group is selected, the check tests `!empty($groupOption['option_id'])` correctly, but builds the permission name from `$groupOption['optid']`, producing `view field option event 1`. Selecting a group would show no option columns even once line 55 is fixed. Line 229 also reads `$entry['optid']`, but that one is correct. It comes from `FieldOptionStorage::adminOptionMemberListLoad()`, and the `conreg_member_options` table column is still named `optid`. The key was renamed in commit `f1ab355` (#3564947), which changed `getFieldOptionList()` and `getFieldOptionGroupedList()` but not their caller in `MemberOptions`. `FieldOptionPermissions`, the other caller, was updated and uses `option_id` correctly. ## Steps to reproduce 1. Configure at least one option group and option for an event (Event Configuration → Member options). 2. Log in as an administrator (or grant a role "View data for field option … for event …"). 3. Visit `/admin/members/options`. 4. **Expected:** a select list of option groups and options. **Actual:** "You don't have permission to see any options. Please contact your administrator." ## Proposed solution - In `MemberOptions::buildForm()`, read `option_id` instead of `optid` from the `getFieldOptionGroupedList()` entries on lines 55, 64, 70, 71 and 192. Leave line 229 unchanged. - Add a kernel test that builds the form for a user with permission for one option but not another, and checks that: - the permitted option appears and the other doesn't; - a user with no option permissions gets the "no permission" message; - selecting a group only shows columns for permitted options. ## Related: field option permissions missing from the Permissions page While investigating, the "View data for field option …" permissions were also missing from the Permissions page. That's a separate problem: `FieldOptionPermissions::permissions()` uses the correct key, and the permissions appeared again after a cache clear. The likely cause is #3596652, which changed `FieldOptions` to read `conreg_options.options` and `conreg_options.option_groups` as lists instead of newline-separated strings, with `conreg_update_9024` converting existing config. If a page built `FieldOptions` after the new code was deployed but before the update ran, it read no options, and that empty object stayed in the `conreg:fieldOptions_{eid}_{lang}` cache until the next full cache clear or event config save. The site log has matching "foreach() argument must be of type array|object, string given" warnings from `ConregOptions::days()` in that window. This couldn't be confirmed, because the cache had already been cleared. Possible follow-up: have `conreg_update_9024` clear the `conreg:fieldOptions_*` cache entries after converting the config, so no stale option lists survive the update.