[Bug]: Closing any page-modal corrupts member values in the edit form

[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

While editing an entry that has a member (or uniqueMember) attribute, closing any dialog that uses the shared #page-modal (Export, Delete confirmation, the "... more values" viewer, etc) silently corrupts the member values in the edit form: the first member input is blanked and the remaining member rows are removed from the DOM.

Expected Behavior

Only closing the member-manage dialog should trigger the member write-back. Other dialogs must not touch the member inputs.

Steps To Reproduce

1. Open a groupOfNames entry, click Edit Entry
2. Open the Export dialog (or click "N more values" on the member attribute) and close it again
3. Observe the member rows in the form: first one blank, others gone
4. Submitting now removes members that were never touched

Relevant log output

Anything else?

Root cause in resources/views/components/attribute/widget/options.blade.php (Member case): the hide.bs.modal handler is bound to the shared #page-modal and runs unconditionally:

$('#page-modal').on('hide.bs.modal',function() {
    var updated = modal_update(modal_attr,attribute_values('destination','select','option'));
    ...

When any other dialog closes, select#destination doesn't exist, so attribute_values(...) returns [] and modal_update() executes its "all members removed" path against the form.

Fix (see PR): bail out unless the closing modal actually contains the member dialog:

if (! $(this).find('select#destination').length)
    return;

Please note that for the creation of this Report, and for the creation of patches, I took Claude Cowork (using Fable 5) to my help. However: Bug finding, testing, refining results, re-testing and confirming working patch on a local instance have been all made by hand. I will file 2 other bugs and then the pull request.

[leenooks]

I was unable to reproduce this using the steps you provided:

1. Open a groupOfNames entry, click Edit Entry
2. Open the Export dialog (or click "N more values" on the member attribute) and close it again
3. Observe the member rows in the form: first one blank, others gone
4. Submitting now removes members that were never touched

I was, however, able to produce it using the following steps

1. Open a groupOfNames entry, click Edit Entry
2. Open the member dialog and close it
3. Open the Export dialog (or click "N more values" on the member attribute) and close it again
4. Observe the member rows in the form: first one blank, others gone
5. Submitting now removes members that were never touched

This needs a little more investigation, thanks for the report.

[lopezio]

Hi, I tested this both with Safari and with Google Chrome. And another UX detail: The button below the field, "Add Members", should be called "Add/Remove Members" (or "Edit Members"). After a few tests I got used to the "Add Member", but at the beginning it was confusing.