Bug #25805

Adding a new task with additional fields saves the wrong values in the additional fields

Added by Michael Franzkowiak over 6 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Should have
Category:
scheduler
Target version:
Start date:
2011-04-06
Due date:
% Done:

100%

TYPO3 Version:
4.5
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

If you have some task in the sheduler and you add a new task which has some additional fields which are name in the same wording as a field in an already existing task, this field is part of the form section but not visible.
If this existing additional field comes in the form part after the visible field, the value of the unvisible field will be take instead of the value of the visibile field.
It's the same if the field is an input field or a select box.
The problem is, if you don't edit the task again, you have no info about the wrong field setting. Only if you re-edit the task, correct the values and save again, the correct values will be stored.
You can check this, if you place 2 different tasks with the same naming of the additional fields. The first task will be saved correct. The 2nd task has in the Post-vars the values of the 1st task.
You can fix this if you change the section
display additional fields in typo3/sysext/scheduler/mod1/index.php

from


// Add each field to the display, if there are indeed any
if (isset($fields) && is_array($fields)) {
    foreach ($fields as $fieldID => $fieldInfo) {
        $table[$tr][] = t3lib_BEfunc::cshItem($fieldInfo['cshKey'], $fieldInfo['cshLabel'], $this->backPath, '|', false, 'margin-bottom:0px;');
        $table[$tr][] = '<label for="' . $fieldID . '">' . $GLOBALS['LANG']->sL($fieldInfo['label']) . '</label>';
        $table[$tr][] = $fieldInfo['code'];
        $tableLayout[$tr] = array (
            'tr'     => array('<tr id="' . $fieldID . '_row"' . $additionalFieldsStyle .' class="extraFields extra_fields_' . $class . '">', '</tr>'),
            'defCol' => $defaultCell
        );
        $tr++;
    }
}

to


// Add each field to the display, if there are indeed any
if (isset($fields) && is_array($fields)) {
    foreach ($fields as $fieldID => $fieldInfo) {
        if ($class == $taskInfo['class']) {
            $table[$tr][] = t3lib_BEfunc::cshItem($fieldInfo['cshKey'], $fieldInfo['cshLabel'], $this->backPath, '|', false, 'margin-bottom:0px;');
            $table[$tr][] = '<label for="' . $fieldID . '">' . $GLOBALS['LANG']->sL($fieldInfo['label']) . '</label>';
            $table[$tr][] = $fieldInfo['code'];
            $tableLayout[$tr] = array (
                'tr'     => array('<tr id="' . $fieldID . '_row"' . $additionalFieldsStyle .' class="extraFields extra_fields_' . $class . '">', '</tr>'),
                'defCol' => $defaultCell
            );
            $tr++;
        }
    }
}


Related issues

Blocks TYPO3 Core - Bug #67241: FAL: Update storgae index doesn't save "Storage to index" on first save Resolved 2015-06-02

Associated revisions

Revision 69de2efd (diff)
Added by Michael Oehlhof 8 months ago

[BUGFIX] EXT:Scheduler: Post only fields of selected class on save

When saving a new task, now only the extra fields of the selected class
where submitted via post and no longer all extra fields of all possible
classes.
This prevents saving the wrong value if extra fields of different classes
have the same id.

Resolves: #25805
Releases: master
Change-Id: I4f0ae67694fbc3b284e763e3edd123804d078350
Reviewed-on: https://review.typo3.org/51027
Tested-by: TYPO3com <>
Reviewed-by: Thomas Hohn <>
Reviewed-by: Frank Nägler <>
Tested-by: Frank Nägler <>
Reviewed-by: Wouter Wolters <>
Tested-by: Wouter Wolters <>

History

#1 Updated by Markus Klein over 6 years ago

Can you please provide a patch or even better, submit a changeset to gerrit?

#2 Updated by Michael Franzkowiak over 6 years ago

Hi Markus,
it's my first bug report, so i'm no so experienced in your proceeding.

What do you mean with a changeset and how should i submit this?

#3 Updated by Francois Suter over 6 years ago

Hi,

it's my first bug report, so i'm no so experienced in your proceeding.

What do you mean with a changeset and how should i submit this?

The best way to get started is to read this section of typo3.org: http://typo3.org/development/bug-fixing/

However in this case the solution you propose is not correct. It will help in the case of editing a task, but it will fail when adding a new task, because we need all the additional fields in this case (they get shown/hidden via JavaScript).

This problem is known and there's no simple solution. Because it's up to each extension developer to name its own fields, unique name fields cannot be enforced. The Scheduler's manual clearly states that developers should pay attention to this. The problem is that it's very hard to enforce this unicity unless the whole Scheduler API for additional fields is changed. Even TCEforms does not do this: it provides developers with a proper name for their form fields, but developers can choose to ignore it.

#4 Updated by Michael Franzkowiak over 6 years ago

Hi Francois,

Thanks for your reply and your manual tip.

Concerning you answer i made another experience and it works.
In the case of add a new task:
If i ignore the additional fields from the other task, marked with display hidden, the typed in values will be stored exactly in the way the value is filled in the form.

In the case of editing an existing task:
If i edit the task, all defined values are available again as aspected.
And i did this with 10 different tasks and every task works fine and without any problems.

Even if the other additional fields have the style display:hidden, they are available, but not visible, in the form.
And the last field, hidden and possibly from another task, with the same formfield name as the formfield from the displayed task, overwrites my value.
You can reedit the task immediatly after saving the first time, retype the correct value and save again.
Only after saving it twice the correct value will be stored.
But that's not usable if you have a couple of people from the customer who should manage the tasks and you should explain them to save a new task twice until it has the correct value stored.

So i did the workaround in this core extension, well knowing that my correcting will be overwritten by a next update of a newer typo3 release, and that i have to make a backup before.

But as i said, it works very well.

#5 Updated by Christian Kuhn over 5 years ago

It is still as misconception in the scheduler backend that additional fields need to have unique field names across all registered task.

Imho the most simple solution is to not load all add. fields at once if a task is added / changed, but to reload the view if the task-selector drop-down is changed.

#6 Updated by Michael Stucki almost 4 years ago

  • Category set to scheduler

#7 Updated by Michael Stucki almost 4 years ago

  • Project changed from Scheduler to TYPO3 Core
  • Category changed from scheduler to scheduler

#8 Updated by Mathias Schreiber almost 3 years ago

  • Target version set to 7.5
  • TYPO3 Version set to 4.5
  • Is Regression set to No

#9 Updated by Benni Mack about 2 years ago

  • Target version changed from 7.5 to 7 LTS

#10 Updated by Mathias Schreiber about 2 years ago

  • Description updated (diff)

#11 Updated by Mathias Schreiber about 2 years ago

  • Description updated (diff)

#12 Updated by Gerrit Code Review 11 months ago

  • Status changed from New 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 https://review.typo3.org/51027

#13 Updated by Gerrit Code Review 11 months ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51027

#14 Updated by Michael Oehlhof 11 months ago

  • Assignee set to Michael Oehlhof

#15 Updated by Michael Oehlhof 8 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#16 Updated by Riccardo De Contardi about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF