It would be good to have users and user group blacklist/whitelist for pools.
We have the situation that artists are submitting jobs to pools that they shouldn’t be. There’s no way to easily prevent this on the client side AFAIK but it would be good to have the option on the repository side.
The submission scripts would have to hide all pools which the artist hasn’t been given auth to use.
Every pool would have a blacklist/whitelist for users and/or user groups.
Example: we have a 911 pool but every artist thinks his job is 911. That decision should be forbidden from everyone but a lead artist or admin. Currently we can forbid pool change after submission but not before.
We’ve lost a lot of optimization to this problem.
Mike.
Good plan Mike. It’s a bit tricky for submission because DeadlineCommand runs outside of the Monitor’s concept of users.
I was chatting with Ryan (Deadline lead), and he mentioned a pretty good solution. In version 6.2 beta, we’ve changed the OnJobSubmitted() event to fire before we write the job information to the database.
Either way (6.1 or 6.2), you should be able to create an event script to re-write the pool on submission away from “911”, then lock users out of changing the submitted pool from the Monitor.
Does this sound like a reasonable work-around for the time being? I should be able to start digging into the specifics and get you a sample event plugin sometime next week.
The submit dialog still contains information gathered from the repo, else the submit dialog wouldn’t know what pools and users to attach to the job.
If Deadline command is gathering pools, and user names for which to submit, then DeadlineCommand could be structured to gather any user blacklist/whitelist filtered pools as well. The desired result is that those filtered pools would not appear in the submit dialog.
The average user won’t know how to submit a manual job and usurp this mechanism.
As long as you filtered the pools that appeared in the submission scripts, users would only be able to submit to the proper pools.
I think it would be a good feature for any medium to large studio.
Currently, it’s the biggest drain on time and resources that we have with Deadline because every artist in the building thinks that their project is the most important. I eventually had to get into arguments with artists when they kept submitting to our 911 pool and starving other jobs.
Some artists are quite resilient at refusing to do the right thing 
The issue here is that it’s not gathering user names. It just pulls the user name for whoever is logged into the machine and stamps it in the submission info. If you were logged into a windows account named “potato_pete”, it would put that in the job info regardless of whether there was a user in the database with that name.
We need to give serious thought for handling user credentials session-wide. I’m not sure what’d do it yet, but we’ll spend some time thinking about it. And Pete.