[Beaker-devel] Clarification request for Enhanced User Groups

Jan Stancek jstancek at redhat.com
Tue Apr 30 07:01:40 UTC 2013





----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: "Dan Callaghan" <dcallagh at redhat.com>
> Cc: "beaker-devel" <beaker-devel at lists.fedorahosted.org>
> Sent: Tuesday, 30 April, 2013 7:53:38 AM
> Subject: Re: [Beaker-devel] Clarification request for Enhanced User Groups
> 
> 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.

Could this also be a group option? I'd like to avoid running from one maintainer
to other asking them to update their settings. Something like:
- Admin of Bob's team adds "SubmitBot" to list of users that are authorised to submit
jobs on behalf of members in Bob's team.

Regards,
Jan

> 
> 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)
> _______________________________________________
> Beaker-devel mailing list
> Beaker-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
> 


More information about the Beaker-devel mailing list