----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: "Raymond Mancy" <rmancy(a)redhat.com>
Cc: "beaker-devel" <beaker-devel(a)lists.fedorahosted.org>
Sent: Tuesday, April 30, 2013 10:25:57 AM
Subject: Clarification request for Enhanced User Groups
<moving to the public dev list, no reason for this to be in private email>
On 04/29/2013 08:01 PM, Raymond Mancy wrote:
> Just a couple of questions regarding this following sentence:
>
> All members of the group with job modification permissions will be able
> to ack/nack, change priority,
> edit whiteboard, and change retention tag.
>
> 'All members of the group with job modification permissions', does this
> actually translate to 'All members
> of the job's group owner'. I'm assuming it is, I was just momentarily
> confused by it.
No, it's not enough to be a member of the owning group, your membership
in that group also has to be flagged as "can modify jobs".
Ok, do we have a BZ open for that functionality, or is it just implied
in 908183 ?
See the first part of the proposal (before the "Group
ownership" section):
==========
All members of a group are able to submit jobs on behalf of that group.
Group members may also be granted the following additional permissions
on a group:
* group ownership
* group job modification
==========
This means there are two independent permissions on groups, above and
beyond the "can submit jobs on behalf of the group" capability:
1. Group ownership
- can add/remove members
- can change owner status of members
- can change job modification permissions of members
2. Job modification
- can modify jobs owned by the group after they are submitted
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.
The intent of this separation is to allow an automated process to be
given the ability to submit jobs on behalf of the group, *without*
granting the automated tool's account the ability to modify those jobs
after creation.
While technically a group owner may not necessarily have job
modification permissions, they can grant themselves those permissions at
any time, so it's not a real restriction (from the code's point of view,
it means we can ignore the group ownership flag when checking for job
modification permissions).
The default settings when adding a new member to a group are:
- Group Owner?: False
- Can Modify Jobs?: True
> Also, is there a reason why we can't afford the group owner the exact same
> permissions as the
> job submitter (specifically Delete, which is not mentioned)? This would
> probably make the docs a bit
> more maintainable (as in '...with job modification permissions equal to
> that of the job submitter' rather than
> having to update it every time a new job action is created). This would
> also make the code simpler.
It's meant to be full access - if I missed any current capabilities,
it's just a mistake in the design.
Ok.
However, note that part of the redesign is that the job submitter
may
*not* have permissions to make changes after submission, if they're
submitting the job on behalf of a group and they don't have the job
modification flag for that group.
Oh ok, yep, I see that here
http://beaker-project.org/dev/proposals/enhanced-user-groups.html#job-mod....
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)