[Beaker-devel] 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".
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
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.
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.
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)