[Bug]: Members beyond pla.limit.values cannot be removed when a template renders the member attribute

[lopezio]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- OS: FreeBSD jail (source install)
- PHP: 8.4
- LDAP Server: OpenLDAP

PLA Code

Github checkout

PLA Version

2.3.11

Current Behavior

On a group with more than pla.limit.values (default 10) members, when a custom template (JSON, enabled for the entry) includes the member attribute: removing a member via the membership dialog has no effect. After closing the dialog the form is unchanged ("No attributes changed" on update), and re-opening the dialog shows the member still in "Group Members". Each overflow member also appears twice in the dialog.

Expected Behavior

Each member listed once; removals via the dialog are reflected in the form and saved.

Steps To Reproduce

1. Enable a JSON template that includes member in its attributes (rendered on the read-only template tab of the entry view)
2. Create a groupOfNames with more than 10 members
3. Edit Entry → Add Member → move a member out of "Group Members" → Close
4. Form unchanged; update says "No attributes changed"

Relevant log output

Anything else?

Root cause in resources/views/components/attribute/values.blade.php: values beyond pla.limit.values are rendered as hidden inputs without the conditional no-edit class that visible rows receive:

<input type="text" class="d-none" name="{{ $o->name_lc }}[{{ $langtag }}][]" value="{{ $value }}">

The member dialog and attribute_values() exclude .no-edit inputs to skip the read-only template tab — but these hidden inputs are not excluded, so every overflow member is read twice (template tab + edit form). Removing one duplicate from the dialog list leaves the other, so modal_update() keeps the member.

Fix (see PR): apply the same no-edit condition to the hidden inputs:

<input type="text" @class(['d-none','no-edit'=>(! ($editable ?? FALSE) && ($o->dn))]) name="{{ $o->name_lc }}[{{ $langtag }}][]" value="{{ $value }}">

Transparency notice: This bug was filed with the help of Claude (Fable 5) while upgrading an instance in use from v1 to v2.

Bugs were found with manual testing, and customizing some templates. Bug description and the patches were also made with the help of the model, providing it with feedback about all behaviour and checking the code it produced. The results have been tested thoroughly. PR is following