Closed (fixed)
Project:
Translation Management Tool
Version:
8.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
2 Mar 2016 at 15:27 UTC
Updated:
1 Apr 2016 at 10:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
miro_dietikerYeah, the uninstallation should clean up open jobs and set them to aborted. :-)
Dunno about the uninstall message... Can we add a statement there such as "All pending jobs are aborted"?
Comment #3
berdirNote that #2678332: Merge normal and continuous job overviews now adds the config dependency, so uninstalling a module *will* delete those translators.
Comment #4
mbovan commented#2678332: Merge normal and continuous job overviews fixes the Exception problem. We still need to update the status to "Aborted".
Comment #5
mbovan commentedImplemented hook_modules_uninstalled() where I check if uninstalled modules are in the list of possible translators.
In that case, all active (active, continuous or unprocessed) jobs will be aborted. I don't check jobs in the state of review, finished, rejected or continuous inactive.
Comment #6
berdirWhy don't we just rely on translators that are being deleted? We prevent that in the UI, but it can still happen.
E.g. you could delete a translator through config deployment, then this should also happen. So translator post/pre delete, not module based.
Comment #7
mbovan commentedI thought we are preventing it using API as well... There is a check for busy translators in Translator::preDelete().
I added my code to "else" and to support "unprocessed" jobs. I'm not sure that Translator::preDelete() works like it's documented?
Comment #8
berdirYes, that's in presave, which is an array that's not passed by reference. that's definitely broken.
What we should do is move that logic to TranslatorAccessControlHandler and prevent delete access for busy translators.
That won't prevent them from being deleted, which we have to allow as an API call and in that case, we do want to abort the jobs.
Comment #9
mbovan commentedMoved the logic to TranslatorAccessControlHandler::checkAccess(). We don't need TranslatorDeleteForm anymore I guess, so removed.
Comment #10
berdirah, that's how we did it. Not showing delete without explanation is always a bit tricky but yes, I think this makes sense, it's also annoying when it tells you you can but then not really ;)
A test that deleting through the API does this would be nice.
Comment #11
mbovan commentedUpdated tests.
Comment #13
berdirNice, committed.