Hi,
We want to limit users that are only in the “Everyone” group slightly. We want them to only be able to submit jobs to pool=none, simply because we use pools for job priority and users with no affiliation just have to get at the back of the line 
I had a look at the Deadline.Users.UserInfo class (and Deadline.Scripting.ClientUtils.GetDeadlineUser()), but it doesn’t look like it would contain what we need. The standalone API seems to have exactly what I’m after - Users.Users.GetUserGroupsForUser(), but it seems like it would be way easier for me to run this within the Deadline context.
Any tips?
Edit: just to clarify, I’m currently working on the monitor submission script for Maya. Ideally we’d mirror any changes across to the Maya integrated script too, but that’s for later.
Cheers,
Daniel
Hi Daniel,
Unfortunately the functions haven’t been exposed yet to the API/DeadlineCommand and the standalone API function: “Users.GetUserGroupsForUser()” does indeed return a list of all the groups that a user might be a member of. However, there needs to be another function which returns which group is delivering the ‘effective’ end-user permission. As a user can be a member of more than one User Group, then we need to identify consolidate the Access Level controls of what is the effective end user permissions for that particular user. I agree that these functions would be ideally run within the Deadline context. I’ll write this all up in a feature request ticket now for you. I can’t think of a work-around at the moment, but I’ll ask the other guys if they have any ideas for you. Sorry.
Mike
Hi Mike,
No worries, thanks for your reply.
Our userbase is pretty small though, I’m mainly trying to differentiate between students and staff. All relevant staff have access to super user mode in the Monitor… can we use that somehow?
Also, all the student lab machines will have a very structured hostname. If we can access the name of the machine/slave where the request is coming from, I could probably filter on that too…
Edit: For the time being we ended up just making a list of known admin usernames and checking against that. It wouldn’t scale very well, but it’s good enough for the time being.
Cheers,
Daniel
Hey Daniel,
I’m glad you have something sorted for the time being. I have it logged in our system as I can see how super useful it will be to query user groups, etc.
Thanks!
Mike