Role assignment

+++ b/src/Form/SamlauthConfigureForm.php
@@ -521,6 +535,7 @@ class SamlauthConfigureForm extends ConfigFormBase {
+      ->set('samlauth_roles_default_roles', $form_state->getValue('samlauth_roles_default_roles'))

We should filter values to only save the selected roles otherwise the user will have all roles available.

Attached patch fixes this issue

Tested OK !

Added all role feature from d7 module except required role functionality.
1. Default role
2. Map role using saml attributes

@zeshan.ziya please provide interdiff to follow what you changed from previous patch https://www.drupal.org/documentation/git/interdiff

PS sadly module has no test suite

Ahh, I din't apply any patch from here. i took code from https://www.drupal.org/project/samlauth and added role features.

Adding a new patch to be compatible with the new module updates.

Alright. This issue was basically outstanding since the end of 2016, when droath contributed a completely rewritten branch which also had the basic role assignment in already. So it was up to me, to make sense of the various contributed patches.

I like the non-basic settings that zeshan.ziya contributed. I believe that includes functionality which many people will want, it will be enough for most people, and the configuration screen is still not too complicated. However

• I still want this in a separate submodule so that people who want to do their role assignment independently, in a custom way, can remove this functionality completely.
• I can imagine the checkbox for "reset roles" can still be too broad, so I made it a set of checkboxes so that specific roles can be reset.
• The roles should be stored as machine names, not IDs. (droath got this right.)
• I'm fine with the textarea as an input element for the mapping. However, 1) this needs a lot of extra validation; 2) I want to store the configuration in a more structured way than just this string (i.e. a "mapping" in the config schema). Which also stores machine names, not labels for the roles.

So I basically rewrote the thing. Result:

No tests yet for the event subscriber; that (like everything else) will likely wait until version 4.x. The form is standalone / independent of other logic flow, so if I'm wise, I'll make tests for that already. We'll see.

One extra thing I still want to implement: a checkbox for "Only take action on first login" (instead of every login). However, while coding that, I got convinced that the samlauth.user_sync event needs an extra property for that, indicating whether the account was just linked. I already committed the checkbox by accident, but it's doing nothing yet; will implement it soonish.