[Beaker-devel] Clarification request for Enhanced User Groups

Nick Coghlan ncoghlan at redhat.com
Tue Apr 30 05:53:38 UTC 2013


On 04/30/2013 01:14 PM, Dan Callaghan wrote:
> Excerpts from Nick Coghlan's message of 2013-04-30 11:51:32 +1000:
>>> Also, how does the existing group/job permission model fit into
>>> this?
>>> i.e if you're in the same group as the submitter you can ack/nak.
>>
>> I'm open to alternative suggestions, but my initial reaction is that,
>> for individually owned jobs, the permissions granted to group members in
>> the current model should be granted to "group members with job
>> modification permissions" in the revised model.
>
> On the contrary, I think all that stuff should just go away entirely for
> "individually owned jobs" (which I assume to mean, a job submitted *not*
> on behalf of a group, that is <job group=""/>). For individually owned
> jobs, only the owner can modify them.

OK, that makes sense.

Getting back to the original Q in the thread, Dan and I think we've come 
up with a superior model that both simplifies the group model *and* 
simplifies the "automated account submitting jobs on behalf of users" 
use case.

Specifically, here's what I'm thinking:

1. The "job modification" privilege goes away. All group members can 
modify jobs submitted on behalf of that group.
2. Each user account gains the ability to specify other accounts that 
can submit jobs on their behalf
3. When submitting a job, you can nominate a different user that will 
appear as the job submitter. All other permissions (including future 
modifications to the job, and whether or not you can submit the job on 
behalf of a group) will be based on that user, rather than the automated 
account.

This may be clearer with an example:

We have a user "Bob", who is a member of the group "Bob's Team"
Bob has an automated account "SubmitBot" that he wants to use to submit jobs
On his user profile page, Bob adds "SubmitBot" to a list of user's that 
are authorised to submit jobs on Bob's behalf.

Once this is set up, Bob can submit jobs through the bot such that:
- "Bob" (rather than "SubmitBot") is recorded as the submitting user, 
thus Bob can modify/cancel/delete the job, but SubmitBot cannot
- SubmitBot can also submit group jobs on behalf of Bob's Team (by 
setting the submitting user to "Bob")
- the fact a job was originally submitted by SubmitBot is captured 
somewhere, but solely for information purposes

Does that sound better than what is currently in the design doc?

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane

Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)


More information about the Beaker-devel mailing list