API Doc Clarification
Description
Problem/Justification
Impact
Activity

Bug Clerk September 9, 2024 at 12:55 PM
This issue has now been closed. Comments made after this point may not be viewed by the TrueNAS Teams. Please open a new issue if you have found a problem or need to re-engage with the TrueNAS Engineering Teams.

Bug Clerk September 9, 2024 at 12:55 PM
We appreciate the report but suggestions are done through our forums. We cannot simply change API without breaking backward compatibility.

mrr958 September 6, 2024 at 5:58 PM
Didn’t have appropriate user permissions to make this a suggestion :(

Bug Clerk September 6, 2024 at 5:57 PM
Thank you for submitting this TrueNAS Bug Report! So that we can quickly investigate your issue, please attach a Debug file and any other information related to this issue through our secure and private upload service below. Debug files can be generated in the UI by navigating to System -> Advanced -> Save Debug.
https://ixsystems.atlassian.net/servicedesk/customer/portal/15/group/37/create/153
Details
Details
Assignee

Reporter

Impact
Components
Fix versions
Affects versions
Priority

The Swagger doc for /user endpoint shows users can be created with specific group membership. It is unclear that the POST request must supply the internal group database ID, not the GID.
Currently the group membership parameter is effectively unusable unless the dev knows to use internal group ID. A quick google search of "truenas api user group" reveals a few unanswered forum posts of users with the same problem.
Either API back-end logic should be changed to take a group name or GID, or documentation should reflect the need for internal database ID of the group. The former solution uses more readily available data; using internal database group ID requires hitting /groups and manually finding internal group ID, or using browser dev tools' websocket inspector to intercept GUI interactions and find group ID manually.
However, since groups can share the same GID, it does make sense to use internal ID when assigning membership for a user. Perhaps also displaying this data alongside GID would make sense?