We use an AD/Internal User Source, and we’ve been finding that any changes to users (e.g. adding roles) are slow (30+ seconds) via the Gateway UI.
Also, as there is no feedback in the UI to indicate that an action is being processed, it appears like nothing has happened. This is not a massive problem, but it can be a little unnerving unless you know to wait for the confirmation pop-up.
Happy to provide any further details
p.s. enjoying the new features so far, especially for the ways we can handle source control and our deployment pipelines!
Could you give me an idea of how many users and roles your user source has?
It would also be helpful if you could send me the config for that user source (via direct message). You can get that from the configuration REST endpoint. Scrub the host names and the connection username/password as well before sending.
Have you tried the same operation via the API? There shouldn’t be any reason the front-end is the source of any slowdown here as we’re just making requests via the API system.
I suspect you’re seeing slowdown here just as a symptom of the response taking longer than expected to come back from the Gateway. You could also verify this by examining the Network tab of your browser and just looking to see at the delta between request and response during the relevant operation.
Hi @Jesse_Van_Hill, we have 71 users and only 1 role. The config should have been sent to you via a DM. Let me know if there is anything else that may help the investigation.
Hi @cmallonee, I don’t think there is a way to add roles to a user via the API. Wouldn’t this be done through scripting using the system functions?
However, when trying to test this again today, it is significantly faster (<500ms). I’m unsure what has changed. I have tried recreating the user source, but I am unable to reproduce the problem.
@cmallonee & @Jesse_Van_Hill I will provide another update if I am able to reliably replicate the issue.
Is it possible you only see the slowness on your first access after (re)starting? Until the user source is loaded on first access, it doesn’t go out and cache the users/roles from the LDAP server. Expect the first interaction to be slow.
Anything you do through the Gateway UI can be done through the API. Look into the OpenAPI docs around Groups. In 8.3, “Groups” is the API term for Roles, even though we continued using “Roles” in the UI to avoid confusing front-end users. If I recall correctly, you need to think about this area a little differently, and you actually assign the User to a Group (look at the members array) instead of assigning the Group to a User.
Hi @Jesse_Van_Hill, I think you are correct with this assessment.
With this in mind, would it be possible to provide a warning in the UI that this may happen?
Also, would it be possible to provide feedback on any major save/update user interactions on the press of the button (e.g. loading icon, request confirmation popup/banner), in addition to the confirmation that the action has been completed? This is a minor issue, but it may improve the UX for any slow-running API calls, etc. I’m happy to provide any other information if that doesn’t make sense
I find it highly unlikely this would go over well. We’ve already fielded quite a bit of pushback on the Toast notifications both internally and externally. We’re working to improve them, but I suspect adding more of them is not the answer. Is there any question whether your attempt was sent? Does the submission button not look like it registered the click event?
Hi @cmallonee, that’s a fair view regarding the toast notifications.
Does the submission button not look like it registered the click event?
This is the issue when assigning roles from the UI.
I’m guessing that the ‘Assign Roles’ functionality was expected to be fast, and hence, there is no immediate feedback when the button is pressed to apply the changes.
All in all, a minor issue in the grand scheme, and now that I’m aware of it, it’s not a problem.
So a little bit more on the REST API for modifying users and roles/groups.
When we were designing the REST APIs for security, we wanted to use a industry standard REST API… so we decided to use the SCIM 2.0 spec. As Cody mentioned, if effectively made roles and groups synonymous with each other since the SCIM spec deals with groups.
I would recommend checking out the following endpoints on your Ignition gateway:
Defines the schema in much deeper detail than the Open API docs. It defines each attribute - mutability, when it is returned, uniqueness, etc. Open API gives you the schema without consideration for when an attribute is read or write, etc.
If you check the schema for User, you will notice that a user returned by SCIM will have group memberships via the groups complex object, but that they are read only. Instead, if you check the Group schema, you can see that the members complex object is read and write. So, long story short, group membership is controlled on the group with SCIM. If you try to send groups on a write call for a user, they will be ignored.
I hope this helps. If you have questions, let me know.
, but I will aim to get this over to you when I return to work on Monday.
