Community

Post

Get current user in control task?

Is there a way in a control task to get the user that is currently executing it?

The QBQ (question behind the question) is really that we want a way to define control tasks against a type, but limit who can run which ones. So if I have CT1 and CT2, both written against an overthere.Host, I may want certain users to be able to run CT1 and CT2, but other users to only be able to run CT1, and even other users only to be able to run CT2.

Is there a way to do that currently?

One way we thought of is within the script that gets executed by a control task, if we could get the current user, then we could see if they belong to some group or something using XLDs API. But if there were a more native way to do this, that would be great.

11 comments

0

Hi Josh

> we want a way to define control tasks against a type, but limit who can run which ones.

Have you considered creating an overthere.Host subtype, defining the "restricted" control tasks on that, and putting the hosts in question into a directory on which only the relevant roles have the "execute control task" permission?

That's not the way we would want to address this "properly", I think, but is something that could work for now?

1) They do not have to be of different type. You still write them against overthere.Host as you used to do. If CT1 and CT2 were residing on the same overthere.Host, then you replicate the overthere.Host and also put it in the subdirectory where CT2 should reside. The type is the same but its unique Id is different.

If I have controltask1 and controltask2 written against the type overthere.Host, I don't understand how duplicating my host and putting them into different subdirectories with different permissions would solve this problem? I still can't say RoleX can run controltask1 only and RoleY can run controltask2 only, can I? Won't both control tasks be exposed to both Roles because the control task is written against the same type of overthere.Host?

I think that's why I'd need a different (sub) type, like Andrew suggested?

That's what I had in mind, yes. So you'd e.g. have overthere.Host with control task A, and overthere.MySpecialHost with control tasks A (inherited from overthere.Host) and B. Then you would put all the overthere.MySpecialHosts into a folder "Special Hosts" and assign control task execute permissions on that folder to your special users only.

Yes, it does make sense. But it creates different concerns for me. For example, which set of hosts do I add to an environment to receive actual deployments? Since they are effectively the same host when executed against, I'd want to designate on of those groups as the one to receive deployments, and the other(s) to not. I think it creates additional maintenance work, too.

But I'm thinking that is why you likely mentioned _That's not the way we would want to address this "properly", I think, but is something that could work for now? _And yes, we could probably use this for now. Or something like it. Are there any plans to implement a cleaner feature for this? It seems like other have also requested something similar?

And finally, is not exposing the user executing a control task from within the control task itself a decision made intentionally or something else? I've needed this for 2 separate things now, so I'm curious if it is worth submitting a feature request?

If in your images 'Infrastructure/CT1/AHost' and 'Infrastructure/CT2/AHost' are the same type, then all control tasks written against that type will be available to 'AllowedToRunCT1' when operating on 'Infrastructure/CT1/AHost'. Similarly, all control tasks written against that same type will be available to 'AllowedToRunCT2' when operating on 'Infrastructure/CT2/AHost'.

My use case is that I need 'AllowedToRunCT1' to only be able to run a subset of the control tasks defined for that type.

If I'm understanding you correctly, then I don't think the solutions you've provided satisfies that use case because 'AllowedToRunCT1' can run ANY control task defined for that type of 'Infrastructure/CT1/AHost'