On 04/30/2013 05:00 AM, Nick Coghlan wrote:
Rather than updating the design proposal directly on the site, I
decided I wanted some feedback on the current draft first:
http://gerrit.beaker-project.org/#/c/1908/1/dev/proposals/enhanced-user-g...
Key changes:
1. The "job modification" flag on group members is gone, replaced with
the separate concept of a "submission delegate", who can submit jobs
on behalf of the group, but cannot modify other group jobs
How does this actually work?
The doc you mention above says that all members of the group can
ack/nack, change priority, delete job, etc..
Does this mean that the submit bot user should not be added as a member
of the group? Because if it were a member then it could modify any jobs
submitted under the group.
But if the delegate user is not in the group then what systems will be
used?
I do think this is going in the right direction, just need to make sure
I understand it all. :-)
2. Unlike the previous design, submission delegates retain the
ability
to modify the jobs they submit. The design we discussed in the other
thread (where you could change the actual submitting *user*) has been
listed as a deferred feature (because it would require quite a bit
more additional UI design work)
Another couple of points came up while I was writing it:
- should we allow *completed* single-user jobs to be converted to
group jobs? We originally didn't allow this due to the problem with
getting SSH keys installed, but that doesn't apply if the job is
already completed, and it may be necessary if we want to eventually
remove the existing not-quite-group-jobs behaviour (I don't think we
can remove that in 1.0 - we need to allow at least a release for
people to migrate to the new tools before we take the old mechanism
away).
- LDAP derived groups can't be self-administered in the current
design, but should we at least allow Beaker administrators to nominate
submission delegates for them?
Cheers,
Nick.