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.
I'm fairly sure all the requests over the years for those extra
permissions (ack/nack other group members' jobs, delete other group
members' jobs) were necessary because we never had an idea of jobs
submitted on behalf of an explicit group before.
One other thing occurs to me: IIRC the main reason for wanting to
ack/nack and delete others' jobs in the past was for the job matrix
report, which is effectively global (the whiteboard filter includes all
matching jobs, regardless of who submitted them). So in order to fully
satisfy the original use case, it might be necessary to add an extra
filter in the job matrix to limit to jobs for a given group. Then users
would construct their job matrix by saying "give me jobs matching
'Colonel Tier #1 Blah Blah' submitted for group 'colonel-qe'". If
anyone
happened to submit an individual job which also matches the whiteboard
it would not affect the matrix results.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.