The implementation of bug 970501 completely removed the old implicit job sharing model from Beaker 0.15.
While explicit job sharing has been available since Beaker 0.13 (and implicit job sharing deprecated in the documentation), I'm concerned that there's been no *programmatic* indication to users that they're relying on a deprecated feature.
Since we don't provide the job activity logs needed for installation admins to tell if anyone is still relying on this behaviour (see bug 995012), that means I believe we need to be more conservative with how we remove it.
Specifically, I believe we need to add the feature back for 0.15, but behind a configuration flag that turns it on. The "_can_administer_old" method would check the flag and always return False if the feature was disabled.
That way, new installations will have it turned off by default, but existing installations will easily be able to turn it back on if the removal of the feature causes problems for their users.
Actually, lets be even more conservative:
- on by default in 0.15, but can be switched off
- off by default in 0.16, but can be switched back on
- removed entirely in 0.17
Steps to verify:
- Create two users (e.g user1, user2), put them in the same group. Make sure these users do not have admin privileges.
- Login as user1, submit JobA (not a group job!)
- Login as user2.
- You should be able to 'administer' the job (i.e ack/nak, delete, cancel etc)
Now add the following to the config file
beaker.deprecated_job_group_permissions.on = False
- Restart apache
- user2 should not be able to 'administer' JobA
Create group "BZ1000861“ , add shajiang and tfeng in this group.
By default: beaker.deprecated_job_group_permissions.on = True
J:1276 tfeng create this job, and cancel this job. shajiang can be able to update the whiteboard and nack/ack , and
Set beaker.deprecated_job_group_permissions.on = False, and restart http service.
J:1277 tfeng create this job, and cancle it. shajiang can't update the whiteboard, and nack/ack and delete.
So verify this bug.
Beaker 0.15 has been released.
Apologies, just to clarify, the 'administer' actions are limited to changing:
(In reply to Raymond Mancy from comment #7)
> Apologies, just to clarify, the 'administer' actions are limited to changing:
> -retention tag
why only not apply to permission 'cancel' even administer User2 can delete the job. I think both cancel and delete should be included in administer permissions which should be a suite of administer functions.
then it feels much more clearly, right?
The legacy permissions *didn't* really make sense when considered as a whole (they'd just accumulated over the years in response to specific feature requests).
The right way to share job access now is to submit a group job instead, which *does* grant full access to other group members (including the ability to cancel the job, as well as adding all group member's ssh keys to the provisioned systems).
I just noticed we never followed through with this. I filed bug 1280178 for flipping the default to off, so that we can eventually remove it entirely.