Improve UX for Group SAML Configuration page
Original comment by @pshutsin in #202577 (closed)
@xanf we have a problem with implemented solution. Currently when I turn-off GMA all dependent toggles are turned-off automatically. This behavior ignores actual stored values, so "prohibited_outer_forks" toggle will be shown as turned off even if the value in database is true.Steps to reproduce:
Checkout 34648-restrict-forking-outside-of-gma-part-2 branch Migrate database Go to Group SAML page of a new group Turn on GMA toggle => Prohibit outer forks is turned off regardless of DB value (true). Expected: "Prohibit outer forks" should be ON by default (which is reflected in default DB value) when GMA is enabled.
==============
In general I find this behavior as weak UX. Currently we have 4 dependent toggles: Enabled, Enforce SSO, Enable GMA, Prohibit Outer Forks. Imagine a use case where group owner needs to temporary disable Group SAML => They turn "Enabled" toggle off => other 3 toggles are wiped out to "off" state => when owner will turn it back they'll have to restore back other 3 toggles manually.... if they remember how it was before.
I remember a while ago we were "hiding" dependent toggles without changing their state. What was wrong with that?
As a further improvements to our UX I suggest that instead of toggling options, which are currently unavailable we will mark these as disabled (we already have this pattern in Settings -> General
for projects). This will allow us:
- to prevent clearing current settings due to occasional toggling
- allow the user to temporary disable, for example, GMA while keeping
Prohibit outer forks
settings on - it will be applied again as soon as GMA will be turned on again - Properly communicate defaults (now
Prohibit outer forks
is turned on by default, which is absolutely unclear from UI)
Generally, I consider hiding toggles as poor UX (and it was removed from this page ~10 months ago), while disabling will allow us to communicate theoretically available options to user