Bug and confusing behaviour when trying to set a custom NameID format which is already known to the module

Patch attached for reference:

https://www.drupal.org/files/issues/2024-08-29/DD-1794-samlauth--Fix-con... →

Hmm, there's some magic going on here I wasn't aware of; the sp_name_id_format field is actually used to store custom formats, too; we only populate sp_name_id_format_ for the form.

When saving the NameID format, sp_name_id_format_ isn't saved into config.

Re-rolling my code/a patch to handle this correctly gives the attached.

/A

One last patch from me; I found that submitForm() in SamlauthSamlConfigureForm.php was overwriting the value of sp_name_id_format; when a custom NameID format is set, setNameId() in src/Form/SamlauthConfigureTrait.php correctly sets it to the custom value, but then this function overwrites the custom value with the asterisk from the drop-down NameID formats selector.

{facepalm.gif}

Patch attached and pushed to the MR.

/A

OMG that was dumb. Thank you for fixing.

Unfortunately I wasted your time and mine, because:

• I assumed I needed to review the MR. But you had not pushed the patch from #8 to the MR. So I spent time trying to understand the current MR when in fact the fix is a single llne.
• Then I saw that parent::submitForm() is completely changed (has had new 'save' code added) in D10.3 and tried to understand what had happened in ✨ Add optional validation constraint support to ConfigFormBase Fixed , 📌 Allow all callables in ConfigTarget Fixed and more. When in fact this had nothing to do with the behavior; I thought parent::submitForm() was re-saving the value but it isn't. It is my own code (until a single line is removed).

I doubted about adding more of your MR, but didn't. If you add 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' as a "custom" format, the form recognizes it and displays just "Transient" -- which now should hopefully be obvious enough.

roderik → closed merge request !22