Return types for `Role` and `Member` in some API requests could be improved

[veekeys]

We started to use the client package and its great! Thank you for that.

We have noticed some of the types could be improved, though. Mostly it is about interfaces of Member and Role.

Role:

• Currently it has id as optional parameter. All the requests which return the role will always have the id, though. This also adds additional checks, whenever you want to have some inner app logic based on role id. Furthermore, the documentation has id defined in response, so would be good that client is on the same page. https://developer.bentley.com/apis/access-control/operations/get-itwin-role/#response-ref https://developer.bentley.com/apis/access-control/operations/create-itwin-role/#response-ref (pay attention here, that returned instance has no permissions. So would be good to have type defined accordingly) We are using these methods (issue might be applicable to more in the package itself, though) getITwinRolesAsync createITwinRoleAsync updateITwinRoleAsync

Member

• This interface is more complex as it has all fields as optional. That means, that implementation in the app needs to be based by your own logical assumption (or some additional custom mapping). Pretty much same applicable as Role, just would need to review prop by prop and adjust accordingly https://developer.bentley.com/apis/access-control/operations/update-itwin-member/#response-ref https://developer.bentley.com/apis/access-control/operations/get-itwin-member/#response-ref

My suggestion would be to review every api call and update the types returned. We could have single Member and Role interfaces declaration and then just use typescript utility types to adjust the interface depending on the request. I think it would improve the quality of the package and we could fully trust the types to ensure better code in an application too.

I would consider contribution if you agree, just not sure about timeline.

[davidhjones]

Great suggestion. I'm happy to accept contribution, or if we get to it first, we can try to knock it out. Will also depend on timeline :) -- lets keep the dialog open, and as someone jumps on this issue we'll assign accordingly.