Project

General

Profile

Actions

Bug #90815

closed

Can't edit a scheduler task, when extbase command does not exist anymore

Added by B. Kausch over 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
scheduler
Target version:
Start date:
2020-03-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
easy
Is Regression:
Sprint Focus:
Needs Decision

Description

It is all in the subject.

Create a scheduler task, select an extbase command controller task. Remove this task (by removing the method, removing the command controller config or deactivating the extension). When you try to edit the task, this task list is loaded again, but the buttons in module doc header are changed like the in any edit form.

For migrating purposes this is bad behavior...

Actions #1

Updated by Georg Ringer over 4 years ago

  • Status changed from New to Rejected

Thanks for creating this issue!

With #85977 the extbase command controllers have been deprecated in favor of symfony commands. Those are already available in 9 as well, checkout the links and infos at https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.4/Deprecation-85977-ExtbaseCommandControllersAndCliAnnotation.html

therefore I am closing this issue.

Actions #2

Updated by B. Kausch over 4 years ago

Your reasoning is wrong. This is clearly a bug.

I know the new Symfony commands. And I did migrate my commands. Then I wanted to edit the scheduler tasks to change them to the new commands. Guess what? I can't do that... People just want to keep complex timing functions for example. I don't want to create new scheduler tasks.

Actions #3

Updated by Georg Ringer over 4 years ago

  • Status changed from Rejected to New
  • Sprint Focus set to PRC
Actions #4

Updated by Benni Mack over 4 years ago

  • Sprint Focus changed from PRC to Needs Decision
Actions #5

Updated by Georg Ringer over 4 years ago

unless it is already a symfony command, you can't change the type anymore and you need to recreate those commands anyway.

Actions #6

Updated by B. Kausch over 4 years ago

Georg Ringer wrote:

unless it is already a symfony command, you can't change the type anymore and you need to recreate those commands anyway.

Let me clarify why I think this needs fixing:

- first of all: yeah, extbase commands are deprecated. But they are still working in v9.
- but even so: When people must migrate their command to symfony, thzan they want to change the according scheduler task and select the new command. Clearly that should be possible.
- at least: show some kind of error. Because the current v9 backend will break when trying to edit a extbase command which does not exist anymore.

Actions #7

Updated by S P over 4 years ago

  • PHP Version deleted (7.4)

I agree here. This is really annyoing.

This mess is because all the tasks are serialized php objects (no way to cleanly alter them) and when deserialising them there's no real error handling when something went wrong (messsing up the UI).

The upgrade path from Extbase -> Symfony should also provide ways to upgrade existing scheduler rows. At least they should be easily viewable somehow. In one of my cases it was a nightmare to recreate the tasks because you can't even easily look up the configuration anymore after the class is gone.

Actions #8

Updated by Benni Mack about 3 years ago

  • Status changed from New to Needs Feedback

How should we proceed here? Since we don't support v9 anymore (at least not the TYPO3 core team, but only ELTS), should this rather be handled in an upgrade extension such as https://extensions.typo3.org/extension/core_upgrader or something like that to have an upgrade wizard?

Actions #9

Updated by Christian Kuhn almost 3 years ago

  • Status changed from Needs Feedback to Closed

Hey. I hope it's ok to close here for the time being: this issue is mostly upgrade-to-v9 specific and a one-time thing. it doesn't seem as if we will still improve this area anymore. note the 'task class gone' issue has recently been mitigated in v11 again, the interface should behave a bit better. the conceptual flaw of 'serialized tasks' still exists, though.

Actions

Also available in: Atom PDF