I’m implementing a users list from which operators can select who is working on that station. This uses Tulip’s native Users Table, in the native Table widget, to display the options. Ideally, I’d be able to sort the “table” from A to Z, however, the User ID field is not an option to sort by.
I’d like to focus on using this table such that I don’t need to manage upkeep across several locations. For example, I could use the following workarounds, but they’d each require their own set of upkeep:
Create separate Tulip table that contains a User property
Create additional custom field to Users table, with sorting in mind (email, initials, name, etc.)
Utilising the Users table allows me to not worry about removing deactivated users, trust that info such as email is up to date, and not need to add new users in another table.
This likely requires a technical fix that converts the User property to Text.
Just to clarify, when you mention sorting by the “User ID” field, you are referring to sorting by the users’ names, right?
We are aware that sorting by the User ID field is not currently possible. While this functionality is on our radar, we cannot provide a specific timeline for when it will be available given other priorities. Rest assured, we understand the importance of this feature and are considering it for future updates.
Could you elaborate a bit more on why the selection has to be manual? Each user has badge ID, so in most cases you should be able to create a simple “badge” (e.g. a QR code) that you can scan to set the current operator. (The base case would be using the “currently logged in user” but given your problem description I assume that you are not currently logging in each user individually.)
The reason for manually adding users is because (as far as I’m aware, and understandably) you can only have one user logged-in at a time. Sometimes our processes utilise more than one person, so we’d like to track all operators involved, rather than solely the logged-in user. Hence, we think utilising a User List can help with traceability.
Eventually this will evolve to some form of inputting a badge ID (although I haven’t looked too far into loading a User by badge ID) when we scale up.
