Talked with @emanuelschuetze. We may need a bug fix for pre rel-db aka 4.2.29.
Describe the bug
If you create a SAML meeting mapping with allow_update and a user for a SAML user already exists he doesn't get added via the mapper to the meeting. For this we don't only need to check if allow_update is true. But changing" the info should also be allowed if the user doesn't exist in the meeting. It needs to be documented that this means with an active SAML mapping you cannot remove users from a meeting but you can only lock them out or deactivate them completely.
How To Reproduce
Create a mapping for a meeting.
Log in and out as a SAML user.
Create a mapping for a meeting with allow_update false.
Log in as that SAML user and he won't be added.
Furthermore we want that if the IDP doesn't send any key for mapped groups or no mappings apart from default groups are set that group settings don't get updated even if allow_update is true. This change of behaviour also needs to be documented.
Talked with @emanuelschuetze. We may need a bug fix for pre rel-db aka 4.2.29.
Describe the bug
If you create a SAML meeting mapping with
allow_updateand a user for a SAML user already exists he doesn't get added via the mapper to the meeting. For this we don't only need to check ifallow_updateis true. But changing" the info should also be allowed if the user doesn't exist in the meeting. It needs to be documented that this means with an active SAML mapping you cannot remove users from a meeting but you can only lock them out or deactivate them completely.How To Reproduce
Create a mapping for a meeting.
Log in and out as a SAML user.
Create a mapping for a meeting with
allow_updatefalse.Log in as that SAML user and he won't be added.
Furthermore we want that if the IDP doesn't send any key for mapped groups or no mappings apart from default groups are set that group settings don't get updated even if
allow_updateis true. This change of behaviour also needs to be documented.