to be able to automatise user creation and user audit.
we are looking how to expose the data of user. There is user creation but not the part on user custom field.
Currently as individual table cannot have access restriction, we cannot expose personnal id of employee in table.
Hey Mathieu.
A few clarifying questions-
-
There is currently an API endpoint that can be used to create operators. The API documentation around this is available at https://[your-instance].tulip.co/apidocs. I created a feature request to build a code free way to do this within the platform. Right now the API will only let you create operators, not any other permission types. Is this functionality you would like?
-
There is an open feature request to add an API endpoint to return user data. A conversation around that need is here. I will update both threads as that feature progresses. When you say the data of the user, are you referring to stuff like the user shift and role, or are you talking about a data historian about what that user has done (creating tables, editing apps, etc)?
-
Right now all permissions to get to a table are based on the user permission level. Is there any reason you couldnt make the users you want to restrict Viewers or Operators and then expose the table data to them through a shared analytic or app? What is the use where they would need to be accessing a table directly?
Thanks for the feedback!
Pete
hello @Pete_Hartnett
there the answer of your questions :
- The operator is most critical user and the most complicated in our case. Of coursem to be able to automatise the whole creation every role can be good to provided but they are not critical. Because it is on the operator role that we have more turnover and change.
2&3. Firstly, as you provided there is the user creation. After that there is the user permission independently from the user. It is this part when you mention data. Currently we managed “extra” persmission through the custom field table. There fields help us to save some personnal data such as (email, employee id, SAP user) and access (application user mostly)