Task #49375
closed
Scheduler: Extbase-tasks should appear on "toplevel", not as subitems below extbase
Added by Stefan Neufeind almost 11 years ago. Updated over 7 years ago.
0%
Description
In the scheduler currently all extbase-based scheduler-controllers appear "grouped" below Extbase. They should however be "on top-level" as other tasks appear and show the relation to the plugin they originate from.
From user-perspective those are just regular tasks. It doesn't matter which underlying framework is used.
Updated by Philipp Gampe almost 11 years ago
- Status changed from New to Accepted
- Complexity set to easy
I don't have time tonight, but can surely work on this before 6.2.
Updated by Ernesto Baschny over 10 years ago
- Category changed from Backend User Interface to scheduler
Updated by Philipp Gampe over 10 years ago
- Status changed from Accepted to On Hold
- Target version deleted (
6.2.0) - Complexity changed from easy to hard
I had a look into this. This is not possible with the current implementation.
The scheduler registers classes with their class name and only uses the class name to keep track of registered classes. However in case of extbase command controller tasks, the class name always has to be TYPO3\\CMS\\Extbase\\Scheduler\\Task.
In the current implementation, all additional fields of all tasks are rendered while the list of available tasks is executed. That means that even if you display a task, you cannot see its additional fields, which drives this mostly useless.
The TYPO3\\CMS\\Extbase\\Scheduler\\FieldProvider will need to be changed to provide list of available command controllers. Then you need to fake a already saved tasks to get the additional fields for this task.
Once the task save the task, you have to reverse the fakes, put back the extbase class names, etc.
The is doomed to break, because there are too many hacks involved.
The scheduler extension needs to be refactored before this can be done.
Updated by Wouter Wolters over 10 years ago
I have a working concept, just need to find the time to finish it.
Updated by Philipp Gampe over 10 years ago
I did not say it is impossible, but I wanted to highlight, that this is much more difficult than one would expect ;)
Updated by Ernesto Baschny over 10 years ago
- Status changed from On Hold to Accepted
Would be great if we could find a solution for this for 6.2, as it is confusing for users to see so many tasks "hidden" behind the misterious "Extbase CommandController Task" - as we have more and more sysext in Extbase providing important core functionality (Lang Update, Extension manager, ..).
It seems that some tasks are registered as regular scheduler tasks, i.e.:
- $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['scheduler']['tasks']['TYPO3\\CMS\\Extensionmanager\\Task\\UpdateExtensionListTask']
which then show just fine in the Scheduler. While others are registered as "CommandControllers" in extbase:
- $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['extbase']['commandControllers'][] = 'TYPO3\\CMS\\Extensionmanager\\Command\\ExtensionCommandController';
which then show under the "CommandController" of Extbase and just appear as soon as you choose (and save) it.
Maybe instead of extensions directly registring to an "extbase" SC_OPTIONS global array (which the schedulers has no way of knowning), there could be an Extbase-API (i.e.: \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerCommandController) which would then take care of adding the corresponding task to the scheduler global array.
Updated by Philipp Gampe over 10 years ago
Ernesto Baschny wrote:
Maybe instead of extensions directly registring to an "extbase" SC_OPTIONS global array (which the schedulers has no way of knowning), there could be an Extbase-API (i.e.: \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerCommandController) which would then take care of adding the corresponding task to the scheduler global array.
The problem is, that extbase task have a different way to render the additional fields and all extbase tasks are saved under the same task key, thus making it impossible to show them with the current select list.
You would need to give all extbase task unique keys such that the scheduler can tell them apart. Currently the distinction happens inside the extbase task, as the actual task name is just a property of it.
Updated by Mathias Schreiber over 9 years ago
- Assignee set to Wouter Wolters
- Target version set to 7.4 (Backend)
Wouter, you stay on this one?
Updated by Wouter Wolters over 9 years ago
- Assignee deleted (
Wouter Wolters)
I gave it once a shot but that failed and I lost the code:(
Updated by Susanne Moog almost 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack over 8 years ago
- Target version changed from 7.5 to 8 LTS
Updated by Gerrit Code Review over 8 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/43583
Updated by Gerrit Code Review over 8 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/43583
Updated by Anja Leichsenring over 7 years ago
- Status changed from Under Review to Rejected