On 04/30/2013 10:48 AM, Raymond Mancy wrote:
> 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 ?
If I recall correctly, we estimated the grant/revoke job modification
permissions BZ (
https://bugzilla.redhat.com/show_bug.cgi?id=952979) on
the basis that it included actually making that setting mean something.
So 908183 wouldn't make the distinction, then we would revise the
affected operations when the extra permission was added.
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.
So, I think the clarifications needed in the design proposal are:
- the "Delete" permission is also part of the new "Job modification"
flag (are there any others I missed?).
- the idea is that when a job is owned by a group, then members of that
group with job modification permissions will have the same level of
access as a user does for their individually owned jobs
- for individually owned jobs, fellow group members with job
modification permissions will be granted the same level of access that
group members are granted now
Could you enumerate for me what that last one covers? ack/nak,
obviously, but is there anything else group members can do currently?
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)