On 04/30/2013 11:07 PM, Bill Peck wrote:
On 04/30/2013 05:00 AM, Nick Coghlan wrote:
> Rather than updating the design proposal directly on the site, I
> decided I wanted some feedback on the current draft first:
> Key changes:
> 1. The "job modification" flag on group members is gone, replaced with
> the separate concept of a "submission delegate", who can submit jobs
> on behalf of the group, but cannot modify other group jobs
How does this actually work?
The doc you mention above says that all members of the group can
ack/nack, change priority, delete job, etc..
Does this mean that the submit bot user should not be added as a member
of the group? Because if it were a member then it could modify any jobs
submitted under the group.
Right, the submit bot will be added to a separate "submission delegates"
list. The bot account would then have access to modify jobs submitted
through the bot, but no general access to other jobs submitted for that
group. While I like the user level delegation idea, where the bot
wouldn't have access to modify the job at all, it's a complex enough
enhancement that I'd like to tackle it later.
But if the delegate user is not in the group then what systems will
For the initial iteration, we would need to expand the candidate system
filter to include systems that are associated with the job's group, in
addition to those that the delegate user has access to directly. Once we
add system pools, that logic will all need adjusting anyway.
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/
PulpDist Development Lead (http://pulpdist.readthedocs.org