It would be nice to allow REST API users to get their user ID. It can come handy for example when managing own ssh public keys (http://ovirt.github.io/ovirt-engine-api-model/master/#types/user). It may be represented for example like a link GET /api ... <link href="/api/users/{currentUserId}" rel="currentUser" /> ... or magic user id GET /api/users/me
This makes sense to me, as it has been requested already more than once. I'd suggest to implement it as an attribute inside the 'Api' type: GET /ovirt-engine/api <api> <authenticated_user href="/ovirt-engine/api/users/123"/> ... </api> Note that we will probably want to support user impersonation in the future. This should be clearly documented as the user that was authenticated. If/when we implement impersonation, then we can add another link: <api> <authenticated_user href="/ovirt-engine/api/users/123"/> <effective_user href="/ovirt-engine/api/users/456"/> ... </api> In this potential future scenario the actual permissions in effect will be those of user 456, not of user 123, so it may be better to add both attributes from the very beginning, even if they will initially have the same value.
Jakub, can you elaborate a bit on what is the use case for this? I mean, why it is needed or convenient. That would help when deciding if/when this should be implemented.
Sure. We come across the issue of (not) having a user ID while trying to implement public ssh keys management in web-ui project (a userportal replacement, https://github.com/oVirt/ovirt-web-ui/). The id is necessary to manage any resources linked from user entity: sshpublickeys, permissions, tags, roles. According to documentation (http://ovirt.github.io/ovirt-engine-api-model/master/#types/user) it's also domain and groups.
Verified in ovirt version 4.2.0-0.5.master.el7. Tested with: GET /ovirt-engine/api/ Result: <api> ... <authenticated_user href="/ovirt-engine/api/users/..." id="..."/> <effective_user href="/ovirt-engine/api/users/..." id="..."/> </api>
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.