I might be mistaken but this isn't something easy to do -
Currently the API is the place where the user identity is known but we don't pass that along to porter. In order to do this we'll need to add the requestor identity as a property in all messages to the resource processor as we don't know which bundle will require it.
@marrobi Have I missed anything? Is this something we'd like to do?

I think we need to pass the requester user object ID (not sure if we can deduce email or that would be needed too) through to porter. For some services, such as AML compute instances we also need to provide the AAD user object ID (manually at present).

I think we need to pass the requester user object ID (not sure if we can deduce email or that would be needed too) through to porter. For some services, such as AML compute instances we also need to provide the AAD user object ID (manually at present).

I guess this is now a different requirement / usecase as the object id isn't much different than a random vm user name as for the person they both are meaningless.
Maybe a better way to phrase this would be: we want the API to extract details from the token and be able to inject them into the action request. username for create vm, aad id for aml compute...
wydt?

The email is part of the User object once logged in. Where we call:

        user_resource, resource_template = user_resource_repo.create_user_resource_item(user_resource_create, workspace.id, workspace_service.id, workspace_service.templateName, user.id)

we could pass the complete user, and then include the email as part of the parameters.

Bringing this old issue up as this would be something we need.

We would like for the user information to automatically be sent to porter instead of having to specify it manually. Our use case is enabling SSH access using Azure AD for VMs in an unrestricted workspace.

Is it something that is planned to be implemented, or is there a way to somehow pre-fill the template with this information? I have looked into it but couldn't find a working approach.

Not planned, don't think it would be too hard.

The user id, and maybe username could be passed in the service bus message from the API to the resource processor, then it would be available in porter.

If passed the user into get_resource_request_message_payload here -

So bits want will need adding as a property to the payload here -

"user" : {
"id": user.id
"name": user.name
"email": user.email
}

Or similar - probably want username... which isn't any of these.

The resource processor should then pick it up here -

Think you could do a PR? Happy to help iterate with you.

I will unfortunately not have time to work on a PR for the next two weeks. It is not an urgency on our side however, so I can have a look after that.

@jlabhard-sg I had 30 mins or so free at the end of the day:

Created a draft PR - #3770 Welcome your input - is this what you need?

Hi @marrobi,
This seems perfect. The username doesn't necessarily need to be set to the base VM user, as long as they can be added in a custom template, which seems to be the case here.