Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1967 Ideas

Arie V
Community Manager
Arie VCommunity Manager

SSO exception neededCompleted

It is great that Indicium and Universal GUI now support SSO based on the Open ID protocol. In our case we'll use Azure AD as Identity Provider and wish to enable SSO with Universal. Since Universal GUI 2021.1.15 we can enjoy the beauty of SSO, PWA ánd Seamless SSO. The Seamless SSO is how we want to have it working for our end users, as there is no added value in having to click through multiple screens in 99% of the cases. This means that we have to set loginOptionsHidden or loginOptionsDisabled to true in the config.json of Universal GUI and set a DefaultIdentityProvider in Indicium appsettings.json.However, the current solution is a bit too rigid, as there is no way to circumvent the said Seamless SSO, except for changing the Indicium setting and redeploying Indicium. There are multiple scenario's for which this rigidness is unwanted: If we wish to enable multiple Open ID providers, but still wish to make it as Seamless as possible for each individual user If 1 of our foreign offices does not have Azure AD or if a user is not added as a Guest User in our tenant, we might want to give those users an IAM account If we plan to create customer portals: same as with first bullet If Azure AD is down for some unexpected reason, then we want to be able to get into our application using an IAM admin account as backup If (like we do on TEST now) we want to test with dummy users who reference a User Group, we want to create those users in IAM and not in Azure AD. For all regular users (especially with admin rights) in TEST we would like to enforce Azure AD SSO + MFA though. Now what we like best as a solution would be something client-side, which could be removed when clearing cache (ideally it would not be removed for every Universal GUI upgrade we get though). Given the above examples I don’t think it is ever going to be very useful to have the DefaultIdentityProvider setting in appsettings.json. How about adding a ‘Remember my choice’ checkbox on the Indicium login screen which value is stored in the cache?This provides all the benefits we’re looking for: In case of enabling multiple Open ID providers, a default can be selected by the user, enabling Seamless login the next time they login For non-Open ID users they can simply use the IAM login and perhaps also use Stay signed in + Remember my choice checkboxes to reduce the login steps It provides a way to get into Thinkwise in case the Open ID provider is not available (either through Clear cache or through Incognito browser) It will always and easily allow us to circumvent SSO default when testing in an Incognito browser tab An alternative would be to have a second login screen on Indicium with its own URL that is not impacted by the SSO settings, but it’s less convenient than above solution. There could be other alternatives, and we’ll leave the choice up to you. But something is needed here. 

Ricky
Superhero
RickySuperhero

Specify a collation for 1 specific column in a tableOpen

We like to be able to specify a collation for 1 specific column in a table in the model.Currently our default database collation is set to SQL_Latin1_General_CP1_CI_ASWe have this special column that really wants be case-sensitive and wants to be unique preferably Latin1_General_100_CS_AI_SC_UTF8  so that not only case-sensitive uniqueness is guaranteed but als super/subscripting for cubic meters for example. The latter can be achieved, but we cannot seem to find a way to make this specific column case sensitive/sub/supercripting ‘aware’ towards the database.We also would like to have the user interface to react to it as it was case insensitive in lookups for example. How can I achieve such functionality? An example is milliohm [mΩ] to meg(a)ohm [МΩ] (or mOhm and MOhm) - the column for such unit has to be unique since they actually really mean a load of difference in resistance, but I want them to be found by the user when typing in any case ‘mohm’ which currenly follows the collation rules:above is Latin1_General_100_CS_AI_SC_UTF8 (needs UTF8 and case sensitive for for both case and sub/superscripting uniqueness) where you can see that the client will act accordingly to the collation - which we do not want to happen.We want the user to have a result in a lookup that gives both options despite the collation settings:We do not want to bypass the SF-model or fiddle around with tags or dynamic(ly)/manually generated stuff.