Solution for deletion via tracker

[jjeising]

At 33C3 we talked about the following solution for rerelease and deletion:

• Support deletion of talks via ready to remove. This is an explicit command.

• Always delete recordings and replace on rerelease. Update metadata when master ticket is rereleased.

[saerdnaer]

I suggest to discuss re-releasing in #8 and use this ticket for discussion of a 'deletion via tracker' feature.

[derpeter]

@jjeising as ready to remove is a different state than the one the publishing usually listens to, would you prefer:

1. the script to as on every run for ticket in both states
2. we run two systemd units with differents configs for the script
3. we run the delete script only when we know we need it to delete things

i would prefer that last option as a delete script running all the time maybe a bad idea, on the other hand this would allow e.g. erfas who have only access to their tracker project to delete there own talks.

[a-tze]

I'd prefer 3. for the same reason, but this could be circumvented by giving the delete script distinct credentials, so that it has to be explicitly enabled as a project worker to do something harmful. In such an environment, 2. is also fine.

[jjeising]

I think all processes here should be fully automated, the only management interface should be the Tracker. Therefore I would prefer option 2 (or even 1 … if it's just a different config and not a different base script, why not put it in one worker, that asks for both types).

[derpeter]

it will be the same script in all 3 cases.
option 2 would have the advantage that we can disable the services independently.
@jjeising what is your opinion on @a-tze suggestion to use a different worker token for the delete job?

[jjeising]

what is your opinion on atzes suggestion to use a different worker token for the delete job?

Until the new worker API with finer control is available this could a good idea.