AWS Thinkbox Discussion Forums

ability to 'protect' jobs

A lot of times we have jobs in the queue that we need to keep around for a couple of weeks. Would be great if there was some mechanism to ‘protect’ jobs from being deleted, cleaned out

This would just be a checkbox, right? As long as it’s checked, then the job can’t be deleted?

In the next beta, there will now be an option to override the number of days before a job is cleaned up on a per-job basis. I’m assuming you guys still want the “protect” option in addition to this?

Thanks!
Ryan

Yes, the protect option would let users simply right click / protect, and not worry about it any longer.

The rest would be ‘free to go’ according to job type (nuke jobs typically can go within 1-2 days of submission, scripted jobs within a couple hours, maya jobs after 3-4 days, max jobs after a week or so, etc)

Maybe a ‘protect for X days’ option would be best… Then they could set it to infinity but also 2-3 weeks if they are reasonable folk.

With the next beta, you could already achieve this by enabling the option to override the cleanup days, and then set it to 2-3 weeks. That’s why I was wondering if you still need the separate “protect” option.

Hmm, true. Maybe we can just provide the users with a “protect for X days” script in the right click menu that adjusts this setting.

You are right, with this option nothing further is necessary.

Cool, thanks for confirming!

Hey Ryan,

We have run into this again, and i wonder if there might be a better way of doing this. There are multiple people cleaning out jobs etc., as the automated cleanup is not always the most efficient way of doing it. This means that jobs that are being troubleshot by some TDs can get removed by accident by a wrangler, or the artist who submitted it etc.
So, to revise my original comment, i think it would still be nice if we could flag a job as protected. Maybe it could simply pop a warning when someone tries to delete it, that “person X flagged this job as protected”. And only people with special permissions, and through a double confirmation could actually remove them.

Just throwing around ideas here though…

cheers
laszlo

Could you guys possibly use the job’s comment field to indicate if the job shouldn’t be deleted? Then the wranglers could simply avoid deleting jobs with a comment like “DO NOT DELETE - troubleshooting”?

Its very error prone. When cleanups are done, we mass select upwars to 5-8000 jobs at a time. Having to look at individual comments (especially when they might be in job groups) is simply not practical :\

If we were to add a protection flag, how would you expect the confirmation to work? I could see us still having the current one (Are you sure you want to delete…?), and when you select OK, we would then look for any protected jobs. If there are any, we then display another popup saying (“There are X protected jobs”).

For that second popup, if the user has permissions to delete protected jobs, they can choose Yes or No to determine if the protected jobs are deleted. If they don’t have permission, they just have an OK button and the protected jobs simply are not deleted.

Finally, only owners of protected jobs and users that have permission to delete them can ultimately delete a protected job.

I guess the protection would need to apply to the the auto-cleanup of jobs as well. For example, a protected that also has “Delete On Complete” enabled would simply not be deleted.

All this make sense? Anything I’m potentially overlooking?

Cheers,
Ryan

No, this sounds perfect Ryan!

Cool. We’ll add this to the wishlist. It’s probably something we could squeeze into 7.1.

Cheers,
Ryan

Love this idea. How about instead of just another warning to click “ok” on, it asks you to re-enter super user password as a confirmation? I know personally I tend to just keep clicking “ok” with full confidence, but then realize a second later that I had my own “protected” jobs selected among a few thousand others. I’m also often already signed in as super user so even a box to click “ok” on won’t necessarily save me from myself.

I would rather just default the Protected Job confirmation to No. Also, re-entering the super user password wouldn’t work because the user’s permission group could allow them to delete protected jobs without having to be super user.

I actually like Jon’s idea, its like UAC in windows. While annoying, it serves a purpose

We imagine that we’ll be adding a property to the user group permission settings that indicates if users in that group can delete protected jobs or not. If they are allowed to, they won’t necessarily know what the super user password is, so we can’t rely on a system like that.

By defaulting the confirmation for protected jobs to No, you have to stop and think about it, and then click Yes. If you’re just mashing on the Enter key, you won’t do any damage. Note that we will always display the confirmation message for protected jobs. If you have permission to delete them, you are given the Yes option to proceed and the No option to cancel. If you don’t have permission, you will simply get a popup saying “X jobs will not be deleted because they are protected” and you can click OK to close the dialog.

Cheers,
Ryan

Privacy | Site terms | Cookie preferences